Parece que o pico do hype sobre microsserviços ficou para trás. Já não lemos várias vezes por semana postagens do tipo 'Como eu migrei meu monólito para 150 serviços'. Agora, ouço com mais frequência reflexões sensatas: 'Eu não odeio monólitos, apenas me importo com a eficiência'. Até mesmo testemunhamos algumas migrações de microsserviços de volta ao monólito. Ao passar de uma grande aplicação para vários serviços menores, você terá que resolver vários novos problemas. Vamos listar esses problemas de forma concisa.

Instalação: da química básica à mecânica quântica

A configuração do banco de dados e do aplicativo básicos com um processo em segundo plano foi um processo bastante claro. Eu publico o readme no Github — e muitas vezes em uma hora, no máximo, algumas horas, tudo funciona, e eu começo um novo projeto. Adicionar e iniciar o código, pelo menos para o ambiente inicial, é feito no mesmo dia. Mas se nos aventuramos em microsserviços, o tempo de inicialização original dispara. Sim, agora temos Docker com orquestração e um cluster de máquinas K8, mas para um programador iniciante, tudo isso é consideravelmente mais complicado. Para muitos júniores, isso é um fardo que realmente representa uma complexidade desnecessária.

O sistema não é fácil de entender

Vamos parar por um momento no nosso júnior. Com aplicações monolíticas, em caso de erro, era fácil rastrear e ir direto para a depuração. Agora temos um serviço que se comunica com outro serviço, que coloca algo em uma fila na barra de mensagens, que processa outro serviço — e aqui surge o erro. Precisamos juntar todas essas partes para descobrir que o serviço A está na versão 11, enquanto o serviço E já espera pela versão 12. Isso é muito diferente do meu diário consolidado padrão: eu tenho que usar um terminal interativo/debugger para passar pelo processo passo a passo. A depuração e a compreensão, na essência, tornaram-se mais difíceis.

Se não podemos depurar, talvez testemos.

A integração contínua e o desenvolvimento contínuo tornaram-se comuns. A maioria dos novos aplicativos que vejo automaticamente cria e executa testes a cada nova versão, exigindo que esses testes sejam concluídos e revisados antes do registro. Esses são processos excelentes que não devem ser desprezados; eles representam uma grande mudança para muitas empresas. Mas agora, para realmente testar o serviço, preciso levantar uma versão completa do meu aplicativo. Lembra daquele novo engenheiro com um cluster K8 de 150 serviços? Bem, agora vamos ensinar nosso sistema CI a levantar todos esses sistemas para verificar se tudo realmente funciona. Provavelmente, isso demanda muito esforço, então simplesmente testaremos cada parte isoladamente: estou confiante de que nossas especificações são boas o suficiente, a API está limpa e a falha de um serviço é isolada, não afetando os demais.

Todas as concessões têm uma boa razão. Certo?

Existem muitas razões para migrar para microsserviços. Já vi que isso é feito para maior flexibilidade, para escalar equipes, para desempenho e para garantir uma melhor resiliência. Mas, na realidade, investimos décadas em ferramentas e práticas de desenvolvimento de monólitos que continuam a evoluir. Trabalho com profissionais em várias tecnologias. Costumamos falar sobre escalabilidade porque eles enfrentam os limites de um único nó do banco de dados Postgres. A maior parte das conversas se concentra em escalabilidade de banco de dados.

Mas sempre fico curioso sobre a arquitetura deles. Em que etapa da transição para microsserviços eles estão? É interessante ver cada vez mais engenheiros dizendo que estão satisfeitos com seu aplicativo monolítico. Para muitos, os microsserviços trazem benefícios, e as vantagens superam os obstáculos na migração. Mas, pessoalmente, eu prefiro, por favor, meu aplicativo monolítico, um lugar na praia - e estou completamente feliz.

Fonte: habr.com