Os provedores de nuvem sabem que estão em um mercado altamente competitivo e que, para terem sucesso, precisam adquirir e reter clientes de longo prazo. Assim, para se manterem diferenciados, correm para adicionar novas funcionalidades, e os vemos atingindo uma paridade de recursos, o que se reflete no fato de colocarmos AWS, Google Cloud Platform e Azure no anel Experimente nesta edição. No entanto, uma vez que conquistam os clientes, esses provedores tendem a criar uma relação o mais "grudenta" possível com seus clientes para desencorajar a migração para outro provedor. Frequentemente isso se manifesta em uma forte dependência da sua suíte específica de serviços e ferramentas, oferecendo uma melhor experiência de desenvolvimento, desde que os clientes permaneçam com eles. Algumas empresas são surpreendidas quando esse grude se torna aparente, geralmente ao optar por mover partes ou todas as suas cargas de trabalho para outra nuvem, ou ao descobrir que o uso da nuvem e seu custo estão fora de controle. Encorajamos nossos clientes a usar a técnica de custo de execução como função de aptidão arquitetural para monitorar o custo de operação, que é um indicador de dependência de determinado provedor ou Kubernetes e contêineres para aumentar a portabilidade da carga de trabalho e reduzir o custo de mudança para outra nuvem por meio de infraestrutura como código. Nesta edição do Radar, também apresentamos duas novas ferramentas de automação de infraestrutura em nuvem, Terragrunt e Pulumi. Apesar de apoiarmos que se considere dependência ao avaliar novas ofertas do seu provedor de nuvem, advertimos contra o uso genérico da nuvem. Na nossa experiência, o custo de criar e manter camadas de abstração agnósticas de um provedor específico de nuvem supera o custo de saída de um provedor específico.
Não importa a velocidade de mudança da tecnologia, as empresas ainda encontram maneiras de reimplementar antipadrões do passado. Muitos de nossos registros no anel Evite denunciam um lobo velho disfarçado de ovelha nova: comportamento de Enterprise Service Bus (ESB) implementado em plataformas de fluxo de eventos—Recriando antipadrões ESB com Kafka, Arquitetura de microsserviços em camadas, Pacotes com fome de dados, Gateways de API excessivamente ambiciosos, Plataformas de baixo código e outras práticas antigas nocivas. O problema fundamental, como sempre, é o equilíbrio entre isolamento e acoplamento: isolamos as coisas para torná-las gerenciáveis a partir de uma perspectiva técnica, mas posteriormente precisamos adicionar coordenação para torná-las úteis na resolução de problemas de negócios, resultando em alguma forma de acoplamento. Dessa forma, esses velhos padrões continuam reemergindo. Novas arquiteturas e ferramentas fornecem meios apropriados para resolver esses problemas, mas isso requer um esforço deliberado para entender como usá-las apropriadamente, e não apenas voltar a reimplementar padrões antigos com novas tecnologias.
Um efeito colateral do ritmo acelerado da inovação tecnológica é um padrão repetitivo de expansão e contração. Quando surge uma nova inovação que muda fundamentalmente a maneira como pensamos sobre algum aspecto do desenvolvimento de software, a indústria corre para adotar: conteinerização, front-ends reativos, aprendizagem de máquina e assim por diante. Essa é a fase de expansão. No entanto, para tornar esse elemento novo realmente eficaz, é necessário descobrir como aplicar práticas de engenharia perenes: entrega contínua, testes, colaboração e assim por diante. A fase de contração ocorre quando determinamos como usar esse novo recurso de forma eficaz, criando uma base firme para permitir a próxima expansão explosiva. Durante essa fase, aprendemos a aplicar práticas como testes automatizados abrangentes e automatização de sequências de etapas recorrentes dentro do contexto da nova tecnologia. Freqüentemente, isso caminha de mãos dadas com a criação de novas ferramentas de desenvolvimento. Embora possa parecer que a introdução de uma nova inovação tecnológica por si só avança nossa indústria, é a combinação dessa inovação com práticas de engenharia perenes que sustenta nosso progresso contínuo.
Nossos temas geralmente destacam um padrão que observamos em várias entradas no Radar atual, mas este se refere a todas as entradas durante a vida útil do Radar. Percebemos (e fizemos algumas pesquisas para comprovar) que o tempo que nossos blips permanecem no Radar está caindo. Quando começamos o Radar uma década atrás, o padrão para as entradas era permanecer por duas edições do Radar (aproximadamente um ano) sem nenhum movimento antes que elas desaparecessem automaticamente. No entanto, como indicado pela fórmula no título deste tema, ritmo = distância sobre tempo: a mudança no ecossistema de desenvolvimento de software continua a acelerar. O tempo permanece constante (ainda criamos o Radar duas vezes por ano), mas a distância percorrida em termos de inovação tecnológica aumentou consideravelmente, fornecendo mais evidências ao que é óbvio para qualquer pessoa observadora: o ritmo da mudança tecnológica continua a aumentar. Vemos o aumento do ritmo em todos os nossos quadrantes do Radar e também no apetite de nossos clientes para adotar novas e diversas opções tecnológicas. Consequentemente, modificamos nosso padrão tradicional para este Radar: agora, cada entrada deve aparecer no Radar com base em seu mérito atual—não permitimos mais que elas permaneçam por padrão. Fizemos essa mudança após uma análise cuidadosa, sentindo que isso nos permite capturar melhor o ritmo frenético de mudança sempre presente no ecossistema de tecnologia.
Publicamos artigos relacionados ao Technology Radar ao longo do ano. Inscreva-se para continuar se informando.
Vol.19
O Technology Radar é preparado pelo Conselho Consultivo de Tecnologia da ThoughtWorks, composto por:
Baixe edições anteriores
Somos uma empresa de software e uma comunidade de pessoas apaixonadas, movidas por inúmeras causas. Pensamos de maneira disruptiva para entregar tecnologia que resolve os maiores desafios de nossos clientes, tudo isso enquanto procuramos revolucionar a indústria de TI e criar uma mudança social positiva.
