Technology Radar | Um guia com opiniões firmes sobre as fronteiras da tecnologia

Baixe o Technology Radar Volume 24

Temas dessa edição

Times de plataforma aumentam a velocidade de chegada ao mercado

Cada vez mais, as organizações vêm adotando um conceito de “times de plataforma”: estabelecer um grupo dedicado a criar e fornecer suporte a recursos de plataforma internas e, em seguida, usar esses recursos para acelerar o desenvolvimento de aplicações, reduzir a complexidade operacional e melhorar o tempo de chegada ao mercado.

Conveniência consolidada acima das melhores opções

Temos observado um aumento — principalmente no espaço da nuvem — da integração de ferramentas de desenvolvimento, com a agregação de ferramentas de repositório de artefatos, controle de versão, pipelines de CI/CD, wikis, entre outras. Essas stacks consolidadas de ferramentas prometem maior conveniência e menos rotatividade para as pessoas desenvolvedoras. Mas o conjunto de ferramentas pode não representar a melhor escolha possível.

Permanentemente muito complexo para capturar em um blip

Muitos dos tópicos complexos que discutimos para o Radar acabam sendo classificados como “TCTB — too complex to blip” (muito complexo para capturar em um blip). E muitas vezes, os tópicos são recorrentes permanentemente. Exemplos incluem monorepos, diretrizes de orquestração para arquiteturas distribuídas e modelos de branching. Como muitos tópicos no desenvolvimento de software, existem muitas concessões necessárias para permitir recomendações claras e sem ambiguidade.

Compreendendo o contexto para acoplamento arquitetural

Um tópico que discutimos em quase todas as reuniões é o nível apropriado de acoplamento na arquitetura de software, entre microsserviços, componentes, gateways de API, hubs de integração, front-ends e assim por diante... Praticamente em todos os lugares onde dois pedaços de software podem se conectar. Mas não há uma única resposta certa: essas decisões devem ser tomadas caso a caso, em vez de buscar uma solução genérica, mas inadequada.

Times de plataforma aumentam a velocidade de chegada ao mercado

Cada vez mais, as organizações vêm adotando um conceito de times de plataforma: a ideia é estabelecer um grupo dedicado a criar e fornecer suporte a recursos de plataforma internas — abordagens nativas de nuvem, entrega contínua, observabilidade moderna, padrões AuthZ/N, malha de serviços, entre outros — e, em seguida, usar esses recursos para acelerar o desenvolvimento de aplicações, reduzir a complexidade operacional e melhorar o tempo de chegada ao mercado. Apresentamos esta técnica pela primeira vez no Radar em 2017, e sua maturidade crescente é bem-vinda. Mas com essa maturidade crescente, também começamos a descobrir antipadrões que as organizações devem evitar. Por exemplo, “uma plataforma para reger todas as outras” pode não ser a abordagem ideal. Uma abordagem “big platform up front” pode levar anos para entregar valor, enquanto apostar na abordagem “construa e as pessoas usarão” pode acabar sendo um esforço desperdiçado. Em vez dessas, usar uma abordagem de mentalidade de produto pode ajudar a evidenciar o que suas plataformas internas devem oferecer, dependendo da base de clientes de cada uma delas. As empresas que colocam seus times de plataforma atrás de um sistema de tickets, como um silo de operações à moda antiga, encontram as mesmas desvantagens da priorização sem alinhamento: feedback e resposta lentos, contenção de alocação de recursos e outros problemas já conhecidos provocados pelo silo. Também temos visto várias novas ferramentas e padrões de integração para times e tecnologias surgindo, permitindo uma divisão mais eficaz de ambos.

Conveniência consolidada acima das melhores opções

À medida que as práticas de engenharia que incluem automação, escala, entre outras metas modernas, se tornam mais comuns entre os times de desenvolvimento, vemos a integração de ferramentas de desenvolvimento correspondentes em muitas plataformas, principalmente no espaço da nuvem. Por exemplo, repositórios de artefatos, controle de versão, pipelines de CI/CD, wikis e ferramentas semelhantes geralmente eram escolhidas a dedo pelos times de desenvolvimento e agrupados à la carte. Agora, plataformas de entrega como Azure DevOps e ecossistemas como GitHub englobam muitas dessas categorias de ferramentas. Embora o nível de maturidade varie entre as ofertas de plataforma, o apelo de uma “loja que tem de tudo” para ferramentas de entrega é inegável. De forma geral, parece que os pontos positivos e negativos se concentram entre ter stacks consolidadas de ferramentas, que oferecem maior conveniência às pessoas desenvolvedoras e menos rotatividade, embora o conjunto de ferramentas raramente represente a melhor escolha possível.

Permanentemente muito complexo para capturar em um blip

Na nomenclatura do Radar, o status final após a discussão de muitos tópicos complexos é "TCTB - too complex to blip" (muito complexo para capturar em um blip): são itens que desafiam a classificação, porque oferecem uma série de prós e contras, uma grande quantidade de nuances quanto à aplicabilidade da recomendação ou da ferramenta, ou outros motivos que nos impedem de resumir nossas opiniões em poucas frases. Frequentemente, esses tópicos acabam virando artigos, podcasts e seguindo outros destinos que não o Radar. Algumas de nossas conversas mais ricas concentram-se nesses tópicos: são importantes, mas complexas, impossibilitando um único ponto de vista sucinto. Vários desses tópicos são recorrentes, reunião após reunião — e, criticamente, em vários de nossos engajamentos com clientes —, eventualmente caindo na categoria TCTB, incluindo monorepos, diretrizes de orquestração para arquiteturas distribuídas e modelos de branching, entre outros. Para quem está se perguntando por que esses tópicos importantes não são incluídos no Radar, não é por falta de reconhecimento ou desejo de nossa parte. Como acontece com muitos tópicos no desenvolvimento de software, são muitas as concessões necessárias para permitir recomendações claras e sem ambiguidade. Às vezes, encontramos partes menores dentro dos tópicos maiores, sobre as quais podemos oferecer recomendações que são incluídas no Radar, mas os tópicos mais amplos se mantêm permanentemente repletos de nuances e complexidade para serem resumidos no Radar.

Compreendendo o contexto para acoplamento arquitetural

Um tópico recorrente em praticamente todas as reuniões (veja “Permanentemente muito complexo para capturar em um blip”) é o nível apropriado de acoplamento na arquitetura de software entre microsserviços, componentes, gateways de API, hubs de integração, front-ends e assim por diante... Praticamente em todos os lugares em que dois pedaços de software podem se conectar, pessoas arquitetas e desenvolvedoras lutam para encontrar o nível correto de acoplamento — muitas recomendações comuns encorajam o desacoplamento extremo, mas isso torna a construção de fluxos de trabalho difícil. O acoplamento em arquitetura de software toca em muitas considerações importantes: como as coisas estão conectadas, a compreensão do acoplamento semântico inerente a cada domínio de problema, como as coisas chamam umas às outras ou como funciona a transacionalidade (às vezes em combinação com outras características arquiteturais complicadas como escalabilidade). O software não pode existir sem algum nível de acoplamento fora dos sistemas monolíticos únicos. Chegar ao conjunto certo de compromissos para determinar os tipos e níveis de acoplamento torna-se uma habilidade crítica para lidar com arquiteturas modernas. Observamos práticas inadequadas específicas, como a geração de código para bibliotecas cliente, e boas práticas, como o uso criterioso dos padrões de BFF. No entanto, uma recomendação geral neste domínio é inútil, e balas de prata não existem. Invista tempo e esforço na compreensão dos fatores em jogo ao tomar essas decisões caso a caso, em vez de buscar uma solução que seja genérica, mas inadequada.