Enable javascript in your browser for better experience. Need to know to enable it? Go here.

Técnicas

Adote ?

  • Para avaliar o desempenho da entrega de software, cada vez mais organizações estão recorrendo às quatro métricas fundamentais , definidas pelo programa DORA research: lead time, frequência de deployment, tempo médio de restauração (MTTR) e porcentagem de falha de alteração. A pesquisa e sua análise estatística mostram uma ligação nítida entre alta performance de entrega e essas métricas, que fornecem um ótimo indicador de desempenho para um time, ou até mesmo uma organização inteira.

    Ainda defendemos fortemente o uso dessas métricas, mas aprendemos algumas lições desde que começamos a monitorá-las. E temos observado o uso cada vez mais frequente de abordagens de medição equivocadas, com ferramentas que ajudam os times a obter essas métricas baseando-se somente em seus canais de entrega contínua (CD). Particularmente, quando se trata de métricas de estabilidade (MTTR e porcentagem de falha de alteração), os dados do pipeline de CD por si só não fornecem informações suficientes para determinar o que é uma falha de implantação com impacto real para os usuários. As métricas de estabilidade só fazem sentido se incluírem dados sobre incidentes reais que prejudicam a experiência de uso do serviço.

    E como qualquer métrica, recomendamos sempre ter em mente a intenção final por trás, usando-as para refletir e aprender. Por exemplo, antes de passar semanas desenvolvendo ferramentas sofisticadas de dashboard, considere incluir a verificação rápida do DORA regularmente em retrospectivas do time. Isso dá ao time oportunidade de refletir sobre quais recursos podem ser trabalhados para melhorar suas métricas, o que pode ser muito mais efetivo do que usar ferramentas prontas para uso excessivamente detalhadas.

  • Continuamos vendo times de produto de engenharia de plataforma como um padrão sensato. O insight principal é que são times de produto como quaisquer outros, embora tenham foco em clientes da plataforma interna. Portanto, é fundamental ter clientes e produtos claramente definidos, usando as mesmas disciplinas da engenharia e formas de trabalhar de qualquer outra equipe de produto (com foco externo) — os times de plataforma não são especiais nesse aspecto. Desaconselhamos fortemente a prática de apenas renomear equipes internas existentes como “times de plataforma”, mas sem alterar as formas de trabalho e estruturas organizacionais. Ainda somos grandes fãs dos conceitos de topologias de time ao considerar a melhor forma de organizar equipes de plataforma. Consideramos os times de produto de engenharia de plataforma uma abordagem padrão e um elemento facilitador significativo para a TI de alto desempenho.

  • Continuamos ouvindo relatos sobre empresas descobrindo que sua segurança estava seriamente comprometida devido ao excesso de confiança no perímetro de rede "seguro". Uma vez que esse perímetro externo é violado, os sistemas internos provam estar mal protegidos, sendo suscetíveis a ataques capazes de implantar rapidamente e facilidade ferramentas automatizadas de extração de dados e ransomware que muitas vezes permanecem não detectadas por longos períodos. Isso nos leva a recomendar a arquitetura de confiança zero (ZTA) como um padrão agora sensato.

    ZTA é uma mudança de paradigma na arquitetura e estratégia de segurança. É baseada na suposição de que um perímetro de rede não representa mais um limite seguro, e nenhuma confiança implícita deve ser concedida a usuários ou serviços com base apenas em sua localização física ou de rede. O número de recursos, ferramentas e plataformas disponíveis para implementar aspectos da ZTA continua crescendo e inclui a aplicação de políticas como código com base nos princípios de privilégios mínimos e o mais granulares possível, monitoramento contínuo e mitigação automatizada de ameaças, malha de serviço para impor o controle de segurança de aplicação a serviço e serviço a serviço, implementação de atestado binário para verificar a origem dos binários, e enclaves seguros, além da criptografia tradicional para reforçar os três pilares da segurança de dados: em trânsito, em repouso e na memória. Para uma introdução ao tópico, consulte a publicação NIST ZTA e o artigo do Google sobre BeyondProd.

Experimente ?

  • Embora já exista há algum tempo, estamos vendo cada vez mais casos de uso em que a especificação CBOR para intercâmbio de dados faz sentido — especialmente em ambientes contendo vários tipos de aplicações que se comunicam umas com as outras: serviço a serviço, navegador a serviço e assim por diante. Uma coisa que achamos útil com Borer, uma implementação Scala de um codificador/decodificador CBOR, é a capacidade de clientes negociarem conteúdo entre a representação binária e o antigo formato JSON. É muito útil ter uma versão em texto visível em um navegador, bem como um formato binário conciso. Prevemos protocolos bilíngues CBOR/JSON ganhando popularidade com o aumento contínuo da IoT e da computação de borda, além de outras situações em que o ambiente é fortemente restrito.

  • Cada vez mais, observamos uma incompatibilidade entre o que as organizações orientadas por dados desejam alcançar e o que as atuais arquiteturas de dados e estruturas organizacionais permitem. As organizações desejam incorporar tomada de decisão baseada em dados, aprendizado de máquina e análise de dados em muitos aspectos de seus produtos e serviços e operações internas, essencialmente, buscando aumentar cada aspecto de seu cenário operacional com inteligência orientada por dados. No entanto, ainda temos um longo caminho a percorrer antes de incorporar dados analíticos, incluindo definições de acesso e gerenciamento, nos domínios e operações de negócios. Hoje, todos os aspectos do gerenciamento de dados analíticos são mantidos fora dos domínios operacionais de negócio, com a equipe de dados e os monólitos de gerenciamento de dados: data lakes e data warehouses. Data mesh (ou malha de dados) é uma abordagem sociotécnica descentralizada para remover a dicotomia entre dados analíticos e operação de negócio. Seu objetivo é incorporar o compartilhamento e o uso de dados analíticos em cada domínio operacional do negócio e fechar a lacuna entre os planos operacional e analítico. É baseada em quatro princípios: propriedade de dados por domínio, dados como produto, plataforma de dados self-service e governança computacional federada.

    Nossos times têm implementado a arquitetura de malha de dados, criando novas abstrações arquiteturais, como quantum de produto de dados para encapsular código, dados e política como uma unidade autônoma de compartilhamento de dados analíticos incorporado em domínios operacionais. Nossos times também vem criando recursos de plataforma de dados self-service para gerenciar o ciclo de vida dos quanta de produtos de dados de maneira declarativa, conforme descrito no livro Data Mesh. Apesar de nossos avanços técnicos, ainda estamos enfrentando atritos com o uso de tecnologias existentes em uma topologia de malha de dados, sem mencionar a resistência dos domínios de negócio em abraçar o compartilhamento e o uso de dados como uma responsabilidade de primeira classe em algumas organizações.

  • A documentação viva, que vem da comunidade de desenvolvimento orientado por comportamento (BDD), é muitas vezes considerada um privilégio para bases de código mantidas com especificações executáveis. Descobrimos que essa técnica também pode ser aplicada a sistemas legados. A falta de conhecimento do negócio é um obstáculo comum encontrado pelos times que executam a modernização do sistema. O código é geralmente a única fonte confiável da verdade devido à rotatividade de pessoas e à documentação existente desatualizada. Portanto, é muito importante restabelecer a associação entre a documentação e o código, difundindo o conhecimento do negócio entre o time ao assumir um sistema legado. Na prática, primeiro tentaríamos ir para a base de código e aprofundar nossa compreensão do negócio por meio de uma limpeza simples e uma refatoração segura. Durante o processo, será preciso adicionar anotações ao código para que a documentação viva possa ser gerada automaticamente mais tarde. Isso é muito diferente de fazer BDD em projetos green-field, mas é um bom começo em sistemas legados. Com base na documentação gerada, o passo seguinte seria converter algumas das especificações em testes de automação executáveis ​​de alto nível. Fazendo isso iterativamente, eventualmente, você poderá obter documentação viva em sistemas legados intimamente associada ao código e parcialmente executável.

  • Desde que os incluímos no Radar em 2016, vimos uma ampla adoção de micro frontends para interfaces de usuário web. Recentemente, entretanto, observamos projetos expandindo esse estilo arquitetural para também incluir micro frontends para aplicativos móveis. Quando o aplicativo se torna suficientemente grande e complexo, torna-se necessário distribuir o desenvolvimento entre vários times. Isso introduz o desafio de manter a autonomia dos times, ao mesmo tempo integrando seu trabalho em um único aplicativo. Alguns times escrevem seus próprios frameworks para habilitar esse estilo de desenvolvimento e, anteriormente, mencionamos Atlas e Beehive como possíveis formas de simplificar o problema de integração do desenvolvimento de aplicativos por múltiplos times. Mais recentemente, vimos times usando React Native para esse mesmo objetivo. Cada micro frontend React Native é mantido em seu próprio repositório, onde pode ser compilado, testado e implantado separadamente. A equipe responsável pelo aplicativo de forma geral pode, então, agregar esses micro frontends criados por diferentes times em um único release do aplicativo.

  • Continuamos vendo muitos times trabalhando e colaborando remotamente. Para essas equipes, a programação em grupo remota é uma técnica que vale experimentar. A programação em grupo (mob programming) remota permite que os times rapidamente se agrupem em torno de um problema ou de parte do código sem as restrições físicas de poder acomodar apenas um determinado número de pessoas ao redor de uma estação de pareamento. Os times podem colaborar rapidamente em um problema ou código sem ter que se conectar a um grande display, reservar uma sala de reunião física ou usar um quadro branco.

  • Com o crescimento do uso de times remotos distribuídos, uma das coisas de que as pessoas relatam sentir falta é a parede física da equipe. É um único lugar onde todos os vários cartões de histórias, tarefas, status e progresso podem ser exibidos, funcionando como uma espécie de radiador de informações e hub para o time. Frequentemente, a parede era um ponto de integração, com os dados reais sendo armazenados em vários sistemas diferentes. À medida que os times se tornaram remotos, foi necessário voltar a olhar individualmente para os sistemas de fonte, e obter uma visão "rápida" de um projeto se tornou muito difícil. Uma parede remota única para o time é uma técnica simples para reintroduzir a parede de equipes virtualmente. Embora possa haver alguma sobrecarga para mantê-la atualizado, sentimos que os benefícios para os times valem a pena. Para algumas equipes, a atualização da parede física fazia parte das "cerimônias" diárias que o time fazia em conjunto, e o mesmo pode ser feito com uma parede remota.

  • A arquitetura de um sistema imita a estrutura organizacional e sua comunicação. Não é exatamente novidade que devemos ser intencionais em relação a como os times interagem — veja, por exemplo, a Manobra Inversa de Conway. A interação do time é uma das variáveis que determinam a rapidez e a facilidade com as quais os times podem entregar valor a clientes. Ficamos felizes em encontrar uma maneira de medir essas interações. Usamos a avaliação dos autores do livro Topologias de Time, que oferece uma compreensão de como pode ser fácil ou difícil para os times construir, testar e manter seus serviços. Medindo a carga cognitiva do time , fomos capazes de aconselhar melhor nossas clientes sobre como mudar a estrutura de seus times e evoluir suas interações.

Avalie ?

  • Muitas aplicações de realidade aumentada (RA) dependem do conhecimento de localização e orientação do dispositivo do usuário. O padrão é usar soluções baseadas em GPS, mas as âncoras espaciais, uma técnica mais recente para atender a esse requisito, também é uma opção a se considerar. As âncoras espaciais trabalham com a imagem gravada pela câmera do dispositivo, usando recursos de imagem e sua posição relativa no espaço 3D para reconhecer uma localização no mundo real. Para este local, uma âncora correspondente é criada no espaço de RA. Embora as âncoras espaciais não possam substituir todas as âncoras baseadas em marcadores e GPS, elas oferecem mais precisão do que a maioria das soluções baseadas em GPS e são mais resilientes a diferentes ângulos de visão do que as âncoras baseadas em marcadores. Nossa experiência atualmente se limita a Cloud Anchors para Android do Google, que funcionou bem para nós. De forma atípica, o Google também oferece Cloud Anchors para iOS e com Azure Spatial Anchors, a Microsoft oferece suporte a ainda mais plataformas.

  • Depois de lançar com sucesso seu aplicativo de e-mail HEY como um aplicação do lado do servidor, o Basecamp comunicou a migração de seu principal produto, Basecamp 3, para Hotwire no trimestre anterior. À medida que as organizações adotam cada vez mais aplicações de página única (SPAs) para novos desenvolvimentos web, seguimos otimistas com o Hotwire nadando contra a corrente. Ao contrário dos SPAs, os aplicativos Hotwire mantêm a maior parte da lógica e da navegação no servidor, contando com uma quantidade mínima de JavaScript do navegador. O Hotwire modulariza as páginas HTML em um conjunto de componentes (chamados Turbo Frames) que podem ser carregados pelo padrão lazy loading, fornecer contextos independentes e enviar atualizações HTML para esses contextos com base nas ações do usuário. SPAs oferecem responsividade inegável ao usuário, mas a simplicidade da programação web tradicional do lado do servidor combinada com ferramentas de navegador modernas oferece uma visão revigorada do equilíbrio entre a efetividade da pessoa desenvolvedora e a capacidade de resposta do usuário.

  • Temos observado o uso crescente do padrão Operador do Kubernetes para outros fins além do gerenciamento de aplicativos implantados no cluster. O uso do Padrão Operador para recursos não clusterizados se beneficia das vantagens oferecidas pelas definições personalizadas de recursos e o mecanismo de agendamento orientado a eventos implementado no plano de controle do Kubernetes para gerenciar atividades relacionadas ainda fora do cluster. Esta técnica se baseia na ideia de serviços em nuvem gerenciados por Kube e a estende para outras atividades, como implantação contínua ou reação a mudanças em repositórios externos. Uma vantagem dessa técnica em relação a uma ferramenta criada para um fim específico é que ela abre uma ampla gama de ferramentas que vêm com Kubernetes ou fazem parte de um ecossistema mais amplo. Você pode usar comandos como diff, dry-run ou apply para interagir com os recursos personalizados do operador. O mecanismo de agendamento do Kube torna o desenvolvimento mais fácil, eliminando a necessidade de orquestrar as atividades na ordem adequada. Ferramentas de código aberto como Crossplane, Flux e ArgoCD usam essa técnica e esperamos ver outras surgindo com o tempo.

  • Temos observado inovação contínua em ferramentas de colaboração remota. O novo recurso de Huddles no Slack fornece uma experiência semelhante ao Discord de chamadas de áudio persistente, que os usuários podem acessar a qualquer momento. Gather fornece uma maneira criativa de emular um escritório virtual com avatares e vídeo. Os IDEs oferecem recursos de colaboração direta para pareamento e depuração de erros: mencionamos o Visual Studio Live Share anteriormente e nesta edição incluímos Code With Me da JetBrains. À medida que as ferramentas continuam a desenvolver modalidades de colaboração além de videoconferência, vemos cada vez mais equipes participando de momentos de huddle remota espontânea , recriando a espontaneidade de conversas informais em contraste com a intencionalidade de agendar uma reunião no Zoom ou no Microsoft Teams. Não esperamos que a riqueza da comunicação face a face seja recriada por meio de ferramentas digitais, mas vemos uma melhora na efetividade dos times remotos ao proporcionar vários canais de colaboração, em vez de depender de um conjunto de ferramentas para tudo.

  • Em maio de 2021, a Casa Branca dos EUA publicou sua ordem executiva para melhorar a segurança cibernética da nação. O documento apresenta vários mandatos técnicos relacionados a itens que apresentamos em edições anteriores do Radar, como arquitetura de confiança zero e digitalização de conformidade automatizada usando política de segurança como código. Grande parte do documento é dedicado a melhorar a segurança da cadeia de suprimentos de software. Um item em particular que chamou nossa atenção foi o requisito de que o software governamental deveria conter uma lista de materiais de software (Software Bill of Materials ou SBOM) legível por máquina, definida como "um registro formal contendo os detalhes e as relações da cadeia de suprimentos de vários componentes usados no desenvolvimento de software." Em outras palavras, a lista deve detalhar não apenas os componentes enviados, mas também as ferramentas e os frameworks usados para entregar o software. Esse pedido tem o potencial de inaugurar uma nova era de transparência e abertura no desenvolvimento de software. Isso, sem dúvida, terá um impacto sobre quem cria software como profissão. Muitos, senão todos os produtos de software produzidos hoje, contêm componentes de código aberto ou os empregam no processo de desenvolvimento. Frequentemente, o público consumidor não tem como saber qual versão de qual pacote pode ter um impacto na segurança de seu produto. Em vez disso, contam com os alertas de segurança e patches oferecidos pela fornecedora de varejo. Essa ordem executiva garantirá que uma descrição explícita de todos os componentes seja disponibilizada ao público consumidor, habilitando-o a implementar seus próprios controles de segurança. E como a SBOM é legível por máquina, esses controles podem ser automatizados. Notamos que esse movimento também representa uma mudança no sentido de adotar o software de código aberto e abordar de forma prática os riscos e benefícios de segurança oferecidos.

Evite ?

  • Algumas organizações parecem acreditar que a revisão por pares significa pull request. Elas consideram que a única maneira de se obter uma revisão por pares do código é por meio de um pull request. Vimos essa abordagem criar gargalos significativos para o time, além de degradar significativamente a qualidade do feedback, à medida que pessoas revisoras sobrecarregadas passam a simplesmente rejeitar as solicitações. Embora seja possível argumentar que esta é uma maneira de demonstrar a conformidade regulamentar da revisão do código, uma de nossas clientes foi informada de que esse argumento era inválido, pois não havia evidências de que o código foi realmente lido por alguém antes da aceitação. Pull requests são apenas uma maneira de gerenciar o fluxo de trabalho de revisão de código. Encorajamos as pessoas a considerarem outras abordagens, especialmente quando houver necessidade de ensinar e transmitir feedback com cuidado.

  • Continuamos a perceber dados de produção em ambientes de teste como uma área de preocupação. Em primeiro lugar, muitos exemplos dessa prática resultaram em danos à reputação, por exemplo, quando um alerta incorreto foi enviado de um sistema de teste para toda uma base de clientes. Em segundo lugar, o nível de segurança, especificamente em torno da proteção de dados privados, tende a ser menor para sistemas de teste. Não adianta ter controles elaborados sobre o acesso aos dados de produção se esses dados forem copiados para um banco de dados de teste que pode ser acessado por todas as pessoas desenvolvedoras e QAs. Embora seja possível ofuscar os dados, isso tende a ser aplicado apenas a campos específicos, por exemplo, números de cartão de crédito. Por fim, copiar dados de produção para sistemas de teste pode violar as leis de privacidade, por exemplo, quando os sistemas de teste são hospedados em ou acessados ​​de um país ou região diferente. Este último cenário é especialmente problemático com implantações de nuvem complexas. Dados falsos são uma abordagem mais segura e existem ferramentas que ajudam a criá-los. Reconhecemos que existem razões para que elementos específicos dos dados de produção sejam copiados, por exemplo, para reprodução de bugs ou treinamento de modelos de ML específicos. Aqui, nosso conselho é proceder com cautela.

 
novo
Modificado
Sem alteração

Não encontrou algo que você esperava achar?

 

Cada edição do Radar inclui blips que refletem nossas experiências nos seis meses anteriores. Talvez já tenhamos falado sobre o que você procura em um Radar anterior. Às vezes, deixamos coisas de fora simplesmente porque há muitas a serem abordadas. Também pode faltar um tópico específico porque o Radar reflete nossa experiência, não se baseando em uma análise abrangente do mercado.

Não encontrou algo que você esperava achar?

 

Cada edição do Radar inclui blips que refletem nossas experiências nos seis meses anteriores. Talvez já tenhamos falado sobre o que você procura em um Radar anterior. Às vezes, deixamos coisas de fora simplesmente porque há muitas a serem abordadas. Também pode faltar um tópico específico porque o Radar reflete nossa experiência, não se baseando em uma análise abrangente do mercado.

Radar

Baixar o Technology Radar Vol.25

English | Español | Português | 中文

Radar

Mantenha-se por dentro das tendências de tecnologia

 

Seja assinante

Visite nosso arquivo para acessar os volumes anteriores