Monoliths: uma odisséia no espaço para uma melhor experiência do desenvolvedor

Este artigo é o primeiro de uma série.

Além de retratar uma IA charmosa, mas homicida, o filme “2001: Uma Odisseia no Espaço” talvez seja mais lembrado por seus monólitos. Aparentemente surgidas do nada, estas lajes perfeitamente lisas e pretas obrigam os macacos pré-históricos – e mais tarde, uma equipa avançada de astronautas – a avançar para tocá-los e compreendê-los, para descobrir quaisquer segredos que possam conter.

O filme permanece propositalmente ambíguo sobre o significado desses monólitos. Em vez de oferecerem uma verdade específica, reflectem a ambição e o crescimento da humanidade a quem os possa observar.

Os desenvolvedores têm uma concepção diferente de monólitos. Igualmente misteriosos e atraentes, mas geralmente carentes de proporções perfeitas e acabamento incomparável, os monólitos de software contam a história de como uma equipe projetou e desenvolveu um aplicativo por meio de refatorações, contratações e saídas importantes e mudanças drásticas nos requisitos de negócios.

Ao contrário da ambiguidade dos monólitos do filme, as histórias dos monólitos no software seguem apenas um de dois caminhos:

1. Seu aplicativo cresce organicamente a ponto de você se preocupar com o forte acoplamento entre os serviços e a área cinzenta entre o(s) cliente(s) de front-end e a lógica de negócios de back-end. Você pode ter um susto operacional, como um bug introduzido recentemente que impede os usuários de salvar seus dados, o que se torna a gota d’água: todos os novos serviços devem ser desenvolvidos em repositórios separados e conectados por meio de uma camada de API.
2. Em segundo lugar, você é forçado a dividir seu monólito legado complexo em dezenas, talvez centenas, de APIs discretas como parte de uma estratégia de “transformação nativa da nuvem” que seu CTO vendeu em uma conferência de uma startup que promete ter reunido todos os principais tecnologia de código aberto em uma “plataforma de entrega de software completa”.

No início, seu monólito não é lamentado com frequência. Os microsserviços simplificam a maneira como você avalia o impacto de mudanças importantes ou significativas em seu aplicativo, e seus colegas adoram poder desenvolver novas APIs em qualquer coisa, menos JavaScript. Mais uma vez, todos começam a se sentir como colaboradores, escrevendo novos recursos e resolvendo quebra-cabeças complexos de otimização, e não sentados em reuniões de horas de duração para negociar cada lançamento importante do antigo monólito.

A morte do seu monólito suaviza alguns problemas em torno da organização de desenvolvedores e engenheiros, mas também introduz novos requisitos técnicos que você não tinha definido inicialmente. Você começa a se perguntar: será que todo esse tempo que passamos refatorando e configurando a infraestrutura, e depois lidando com os desafios dos microsserviços, foi necessário, dada a complexidade dos problemas de engenharia que enfrentamos?

Você escolheu microsserviços porque pensou que eles resolveriam seus problemas técnicos quando fossem mais adequados para resolver problemas organizacionais e colaborativos que sua empresa quase certamente não tem. Ao deixar seu monólito morrer, você injetou muita complexidade desnecessária em seu sistema, como:

• Seus ambientes de desenvolvimento local, que antes você poderia iniciar com um único comando, agora exigem operações muito mais complexas, como configurar um cluster Kubernetes local ou pagar generosamente uma plataforma como serviço para lançar novas instâncias em cada execução do seu pipeline de CI/CD .
• O trabalho de configuração e orquestração — também conhecido como operações — rouba tempo de sua competência principal: criar novos recursos e colocar qualidade, segurança e boas políticas em camadas em seu aplicativo.
• Você entende profundamente o seu sistema, mas sabe muito pouco sobre o que o rodeia, levando a incidentes em que você ou outras pessoas respondem a incidentes sem qualquer compreensão holística de como o aplicativo funciona. Você é forçado a depurar em águas desconhecidas sem ninguém lhe orientar.
• Os testes atingem limites de tempo, custo e complexidade quando você precisa iniciar uma implantação efêmera de todo o aplicativo em cada execução de CI, com custos e complexidade crescentes.
• Bibliotecas compartilhadas criam inadvertidamente fragmentação de versão em vez de simplificar transformações e funções comuns, pois cada mudança requer testes extensivos em cada serviço que depende dela, a menos que você use a última versão que funcionou para você.

Você passou de “escrever código ruim para construir infraestrutura ruim”, como Kelsey Hightower alertou, em busca da disciplina de engenharia que você gostaria de ter desde o primeiro dia. Ou, como argumenta David Heinemeier Hansson, CTO do Basecamp e criador do Ruby on Rails. , você adicionou complicações desnecessárias: “Substituir chamadas de métodos e separações de módulos por invocações de rede e particionamento de serviços dentro de uma equipe e aplicativo únicos e coerentes é uma loucura em quase todos os casos.”

Agora, nesta “loucura”, você começa a desejar não ter matado seu monólito. Talvez, se você for um dos poucos sortudos, como a equipe Segment dentro da Twilio, possa tentar novamente com um novo tipo de monólito: aquele que você constrói com intenção.

Uma história diferente: a maturação de um monólito intencional

Esta história também começa de duas maneiras:

1. Você se compromete com essa arquitetura desde o primeiro dia, não porque os monólitos sejam a maneira padrão de começar a desenvolver um aplicativo, mas porque você conhece os desafios futuros se não precisar da complexidade dos microsserviços.
2. Você experimentou microsserviços e não conseguiu cumprir as promessas de nirvana colaborativo, escalabilidade e simplicidade operacional, considerando o tamanho e os requisitos da sua empresa. Você percebeu dolorosamente que os microsserviços injetaram muita complexidade na equação e estão projetando cuidadosamente um novo serviço consolidado.

À medida que você continua no caminho monolítico, essa arquitetura é dimensionada com sucesso porque você está ciente dos medos e equívocos comuns.

“Os desenvolvedores não gostam de trabalhar em monólitos.” Não há uma pesquisa oficial que os desenvolvedores prefiram, mas enquanto o monólito permanecer com bom desempenho, a experiência do desenvolvedor ao trabalhar em um único repositório erra pelo lado da simplicidade. Com serviços separados por pastas e chamadas — e não IaC e idiomas e repositórios — você pode sincronizar até mesmo alterações importantes em uma única solicitação pull para melhor velocidade e qualidade.

Quando a equipe do Segment fez a transição para um monólito intencional, eles saltaram de 32 melhorias em suas bibliotecas compartilhadas em um ano para 46… apenas nos seis meses seguintes.

“Um monólito é apenas uma caixa preta que ninguém entende.” Muitos dizem o mesmo sobre microsserviços.

“Monólitos são lentos.” Monólitos não são ótimos candidatos para escala vertical, mas podem ser excepcionalmente rápidos. A transferência de dados permanece na memória do processo, é mais barata e rápida do que a comunicação máquina a máquina e não precisa passar pela lógica de orquestração dos serviços distribuídos. Quando chega a hora de escalar horizontalmente, você confia em serviços com desempenho e custo mais previsíveis, como AWS EC2, em vez de apostar em opções sem servidor — e há muitas ferramentas de monitoramento de desempenho de aplicativos, como Scout APM, projetadas especificamente para ajudá-lo a identificar oportunidades de otimização até linhas específicas de código.

“Monólitos exigem muito mais testes.” Este parece ser um bom problema. Como sugeriu Hightower, escrever infraestrutura não é a solução para escrever código ruim, o que muitas vezes se resume a escrever testes ruins. Ou não o suficiente.

“Você não pode brincar com novas tecnologias (nativas da nuvem)!” Sim, um monólito não funcionará na última moda de orquestração sem servidor ou de contêiner, mas você ainda tem opções. Por exemplo, você pode implantar uma malha de serviço como Linkerd ou Istio para conectar seu monólito a serviços externos via mTLS. Você pode melhorar a escalabilidade com um balanceador de carga e uma implantação multicloud ou conectar seu aplicativo a um OpenTelemetry Collector para enviar logs, métricas e rastreamentos para uma das inúmeras soluções de observabilidade disponíveis atualmente.

Ciente desses equívocos e de suas realidades, você também pode implementar estratégias para superar os desafios genuínos da construção de um monólito:

• Você garante que todos os serviços usem uma única versão de uma determinada dependência para evitar a fragmentação.
• Você encontra ou constrói uma camada entre sua infraestrutura e o mundo exterior, como a Segment fez com seu projeto Centrifuge, para enfileirar solicitações/mensagens/eventos e lidar com falhas normalmente, em vez de esperar que seu monólito não trave.
• Você cria suítes de testes robustas com interações HTTP simuladas ou gravadas para testes rápidos e determinísticos que minimizam o risco de qualquer pequeno bug derrubar parte ou todo o seu aplicativo.
• Você elimina abstrações e modelos conceituais desnecessários em favor da simplicidade, reconhecendo que a arquitetura de microsserviços resolve problemas de coordenação humana em escala empresarial — provavelmente não um problema atual onde você trabalha agora.
• Nas palavras de Hansson, você “integra seus sistemas até que seja impossível para uma pessoa manter tudo em mente”. Se o Basecamp não chegou a esse ponto, provavelmente você também não chegará.

A chave é que você não está construindo um monólito porque ele é o padrão. É aí que até os monólitos mais bem-intencionados vão morrer. Você está construindo um monólito intencionalmente porque ele resolve os problemas de engenharia de primeira ordem que sua organização enfrenta no momento. Porque ainda é possível manter seu aplicativo na cabeça. Porque você não quer ter que começar do zero novamente quando os microsserviços caírem em desuso e você perceber que entende tão pouco sobre o que construiu.

Construa um com intenção e veja por si mesmo: os monólitos são a escolha certa quase sempre.

Um dos maiores benefícios dos monólitos depende de quem se beneficia mais com o aumento dos custos devido à arquitetura de microsserviços. Fique ligado na segunda peça da nossa série, mas até lá, uma dica: não é você.

A postagem Monoliths: uma odisséia no espaço para uma melhor experiência do desenvolvedor apareceu pela primeira vez em The New Stack.