Parece que o pico do hype para microsserviços está atrasado. Já não lemos as postagens “Como eu transferi meu monólito para 150 serviços” várias vezes por semana. Agora, muitas vezes ouço pensamentos razoáveis: "Não odeio o monólito, apenas me preocupo com a eficiência". Até observamos várias migrações dos microsserviços de volta ao monólito . Ao passar de um aplicativo grande para vários serviços menores, você terá que resolver vários novos problemas. Listamos-os o mais brevemente possível.

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

A configuração do banco de dados base e do aplicativo com o processo em segundo plano foi um processo bastante claro. Publico um leia-me no Github - e geralmente depois de uma hora, no máximo, algumas horas, tudo funciona e inicio um novo projeto. A adição e execução de código, pelo menos para o ambiente inicial, é feita no primeiro dia. Mas se nos aventurarmos em microsserviços, o tempo inicial de lançamento decolará para o céu. Sim, agora temos um Docker orquestrado e um cluster de máquinas K8, mas para um programador iniciante, tudo isso é uma ordem de magnitude mais complicada. Para muitos juniores, esse é um fardo que é uma complexidade verdadeiramente desnecessária.

O sistema não é fácil de entender

Vamos parar por um momento no nosso júnior. Com aplicativos monolíticos, em caso de erro, era fácil rastreá-lo e ir direto para a depuração. Agora, temos um serviço que conversa com outro serviço que enfileira algo no barramento de mensagens que processa outro serviço - e ocorre um erro. Temos que reunir todas essas partes para descobrir, eventualmente, que o serviço A está sendo executado na versão 11 e o serviço E já está aguardando a versão 12. Isso é muito diferente do meu log consolidado padrão: você precisa usar um terminal / depurador interativo para passar pelo processo passo a passo. Depuração e compreensão em essência tornaram-se mais difíceis.

Se você não pode depurar, talvez nós os testemos

Integração contínua e desenvolvimento contínuo agora estão se tornando comuns. A maioria dos novos aplicativos que vejo a cada nova versão cria e executa automaticamente testes e exige que os testes passem e sejam revisados ​​antes do registro. Estes são excelentes processos que não podem ser abandonados, pois se tornaram uma grande mudança para muitas empresas. Mas agora, para realmente testar o serviço, tenho que aumentar a versão funcional do meu aplicativo. Lembra do novo engenheiro com um cluster K8 de 150 serviços? Bem, agora vamos ensinar nosso sistema de IC como elevar todos esses sistemas para verificar se tudo realmente funciona. Provavelmente, isso é muito esforço, portanto testamos cada parte isoladamente: tenho certeza de que nossas especificações são boas o suficiente, as APIs estão limpas e a falha do serviço é isolada e não afeta outras.

Todos os compromissos têm uma boa razão. Certo?

Há muitos motivos para atualizar para microsserviços. Vi que eles fazem isso para obter maior flexibilidade, comandos de dimensionamento, desempenho, para proporcionar melhor estabilidade. Mas, na realidade, investimos décadas nas ferramentas e práticas de desenvolvimento de monólitos, que continuam a se desenvolver. Trabalho com profissionais de diferentes tecnologias. Geralmente falamos sobre dimensionamento porque eles são confrontados com os limites de um único nó do banco de dados do Postgres. A maior parte das conversas é sobre dimensionar o banco de dados .

Mas estou sempre interessado em aprender sobre a arquitetura deles. Em que estágio da transição para microsserviços eles estão. É interessante ver como cada vez mais engenheiros se dizem felizes com sua aplicação monolítica. Muitos microsserviços se beneficiarão, e os benefícios superarão os buracos no caminho da migração. Mas pessoalmente, me dê, por favor, minha aplicação monolítica, um lugar na praia - e estou completamente feliz.