Há um sentimento de que os microsserviços são frequentemente comercializados como uma “bala de prata” para substituir um monólito. Mas nem todo mundo gosta dessa abordagem. De fato, às vezes é usado incorretamente ou de forma inadequada. Abaixo estão exemplos de problemas que tive a "sorte" de enfrentar ao usar microsserviços em diferentes empresas e que não quero repetir no futuro.
Escalabilidade fantasma
A vantagem ousada da abordagem de microsserviço é a escalabilidade. Um fluxo infinitamente grande de usuários e uma carga alta são considerados inevitáveis. Por esse motivo, muito tempo é gasto em otimização preliminar, e não em recursos comerciais úteis. De fato, uma carga alta nem sempre está presente.
A primeira vítima da pré-otimização é o processo de negócios linear. Ele se decompõe em muitos microsserviços. Uma espécie de reserva para o futuro, por razões de divisão de responsabilidades ou escala ilusória. Como resultado, torna-se mais difícil para as empresas navegar no cenário de TI e falar o mesmo idioma da TI, sem mencionar os problemas de navegar pelo código-fonte para os próprios desenvolvedores.
Problemas de interação do serviço
Os serviços recebidos são espalhados do monorep em repositórios separados. Os serviços em si estão se tornando mais difíceis de vincular. Nesse caso, a versão da API de microsserviço pode começar a divergir da versão da mesma API nos clientes de microsserviço. Em seguida, o bom e velho JSON é substituído pelo Protobuf e o HTTP pelo gRPC para obter desempenho, digitação e versão conveniente da API.
Infelizmente, soluções como o gRPC + Protobuf não estão isentas de erros. Os serviços podem travar de maneira consistente devido à propagação de um erro e a uma incompatibilidade conhecida de entrada e saída de serviço. A base de código está ficando maior, os serviços de depuração são muito mais difíceis do que os dados de texto sem formatação, trazendo consigo um novo conjunto de problemas.
Esse problema deve ser resolvido por um processo de teste normal. Em particular, testes de integração. Mas os testes de integração precisam ser escritos e executados para cada microsserviço e seu grupo no processo de negócios. Essa é uma tarefa bastante complicada, para a qual eles geralmente não desejam dedicar mais tempo. Ao mesmo tempo, o teste de integração do microsserviço pode ser reduzido à forma de um teste de unidade para um monólito.
Restrições e hábitos antigos
Com tudo isso, as restrições usuais para o monólito entram nos microsserviços. Exemplos vívidos: uma linguagem de programação e um banco de dados para todos os microsserviços. No primeiro caso, essa é a restrição anterior do monólito, no segundo - o legado que se esforça para se tornar o "gargalo" de todo o sistema. Devido à rejeição pelos desenvolvedores e pelo gerenciamento da possibilidade da existência de um sistema heterogêneo construído em diferentes linguagens de programação, perde-se a possibilidade de escolher ferramentas apropriadas para solucionar problemas urgentes.
Além do acima, microsserviços individuais podem não ter desenvolvedores responsáveis por eles. Todo mundo começa a apoiar tudo, ninguém é responsável por nada. Nesse caso, ninguém tem conhecimento sobre a operação de serviços individuais, exceto a última pessoa que alterou seu código. Há uma dessincronização de desenvolvedores, uma perda de entendimento da essência do trabalho dos microsserviços em relação às tarefas resolvidas na área de assunto.
Burocracia de infraestrutura
Os microsserviços são mais difíceis de manter do que um monólito. A infraestrutura, um antigo par de servidores, está se tornando uma pequena nuvem privada. O suporte a essas soluções pelos desenvolvedores leva muito tempo e cria problemas para o gerenciamento no futuro. Uma necessidade absurda de burocracia adicional aparece. Empregados individuais são contratados, processos separados são criados.
Nesses casos, os conjuntos de regras para trabalhar com microsserviços podem ser expostos para manter a integridade do loop de microsserviços. O pior caso é negar até a possibilidade de executar um script ou migração única, impedindo o acesso direto ao caminho. A linha inferior é que o script é denominado como um serviço completo, adicionando mais uma linha à longa lista de microsserviços.
Futuro
O resultado é um sistema que tem muitas vezes mais ruído do que um sinal útil. Em todos os lugares - da infraestrutura ao código de um serviço específico. Da compreensão do esquema de interação entre os serviços por um desenvolvedor e o gerenciamento da empresa. Os programadores, sem querer, se tornam mestres na resolução de quebra-cabeças.
Obviamente, o monólito clássico não é melhor. É lento, mantém seu estado, é difícil de processar, não é coberto por testes de unidade ou de integração, etc. Mas nós podemos fazer melhor! Graças ao mod para microsserviços, entre muitas outras vantagens, vimos o aumento do CI / CD e trabalhamos nos testes. Agora podemos aplicá-las a outras abordagens, e não apenas a microsserviços.
Na próxima vez que você desenvolver um novo sistema ou reciclar um antigo, seja qual for o tamanho, pense duas vezes. A empresa precisa de escalabilidade? Você precisa da capacidade de lidar com altas cargas? Você mesmo está realmente pronto para microsserviços? Ou é melhor começar com arquiteturas mais conservadoras?
Talvez não construa um foguete, mas construa uma scooter simples, porque você só precisa chegar ao fim da rua?