Parece que o auge do entusiasmo pelos microsserviços ficou para trás. Não lemos mais postagens várias vezes por semana “Como mudei meu monólito para 150 serviços”. Agora ouço mais pensamentos de bom senso: “Não odeio o monólito, só me importo com a eficiência”. Até observamos várias migrações de 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 problemas novos. Vamos listá-los o mais brevemente possível.

Ambiente: da química básica à mecânica quântica

Configurar um banco de dados básico e um aplicativo com um processo em segundo plano foi um processo bastante simples. Publico o leia-me no Github - e muitas vezes depois de uma hora, no máximo algumas horas, tudo funciona e começo um novo projeto. Adicionar e executar código, pelo menos para o ambiente inicial, é feito no primeiro dia. Mas se nos aventurarmos em microsserviços, o tempo de lançamento inicial dispara. Sim, agora temos Docker com orquestração e cluster de máquinas K8, mas para um programador iniciante tudo isso é muito mais complicado. Para muitos juniores, este é um fardo que é realmente uma complicação desnecessária.

O sistema não é fácil de entender

Vamos nos concentrar em nosso júnior por um momento. Com aplicativos monolíticos, se ocorresse um erro, era fácil localizá-lo e passar imediatamente para a depuração. Agora temos um serviço que está conversando com outro serviço que está enfileirando algo em um barramento de mensagens que está processando outro serviço - e então ocorre um erro. Temos que juntar todas essas peças para eventualmente descobrir que o Serviço A está executando a versão 11 e o Serviço E já está aguardando a versão 12. Isso é muito diferente do meu log consolidado padrão: ter que usar um terminal/depurador interativo para caminhar através do processo passo a passo. A depuração e a compreensão tornaram-se inerentemente mais difíceis.

Se não puder ser depurado, talvez possamos testá-los

A integração contínua e o desenvolvimento contínuo estão agora a tornar-se comuns. A maioria dos novos aplicativos que vejo criam e executam testes automaticamente a cada nova versão e exigem que os testes sejam realizados e revisados ​​antes do registro. São processos excelentes que não devem ser abandonados e que representaram uma grande mudança para muitas empresas. Mas agora, para realmente testar o serviço, preciso obter uma versão funcional completa do meu aplicativo. Lembra daquele novo engenheiro com o cluster K8 de 150 serviços? Bem, agora vamos ensinar ao nosso sistema CI como ativar todos esses sistemas para verificar se tudo realmente funciona. Provavelmente isso exige muito esforço, então testaremos cada parte isoladamente: tenho certeza de que nossas especificações são boas o suficiente, as APIs estão limpas e uma falha de serviço é isolada e não afetará outras pessoas.

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

Há muitos motivos para migrar para microsserviços. Já vi isso ser feito para maior flexibilidade, para dimensionar equipes, para desempenho, para proporcionar melhor sustentabilidade. Mas, na realidade, investimos décadas em ferramentas e práticas para desenvolver monólitos que continuam a evoluir. Trabalho com profissionais de diferentes tecnologias. Geralmente falamos sobre escalonamento porque eles atingem os limites de um único nó do banco de dados Postgres. A maioria das conversas é sobre dimensionamento de banco de dados.

Mas estou sempre interessado em aprender sobre sua arquitetura. Em que estágio da transição para microsserviços eles se encontram? É interessante ver mais engenheiros dizendo que estão satisfeitos com sua aplicação monolítica. Muitas pessoas se beneficiarão dos microsserviços, e os benefícios superarão os obstáculos no caminho da migração. Mas pessoalmente, por favor, dê-me meu aplicativo monolítico, um lugar na praia - e estou completamente feliz.

Fonte: habr.com