A ideia de microsserviços não é nova. As pessoas mais velhas podem ter trabalhado com a
EJB no auge. O que é isso,
Samuel Colt já usou uma abordagem modular para fabricar seus revólveres. As peças padrão e feitas com precisão de suas pistolas eram intercambiáveis, o que simplificou bastante a produção e a manutenção. Então, por que a infraestrutura não deveria ser modular?
Não há objeções fundamentais a isso, e a própria idéia está na superfície. Mas o tópico dos microsserviços tornou-se popular relativamente recentemente. E há uma razão para isso.
Durante muito tempo, a manutenção da infraestrutura permaneceu uma tarefa trabalhosa e bastante especializada. Somente administradores qualificados podem implantar qualquer cache ou fila na infraestrutura. Que cada parte do aplicativo tinha sua própria infraestrutura e não havia dúvida - quem servirá todo esse zoológico ?!
Mas a tecnologia de virtualização, os contêineres e as ferramentas de gerenciamento de configuração da infraestrutura foram um longo caminho. E agora a implantação de uma infraestrutura independente para um serviço de aplicativo separado tornou-se ainda mais fácil e barata do que fornecer todos os serviços em uma infraestrutura comum. Progresso!
O aplicativo é convenientemente dividido em partes independentes, inclusive por razões organizacionais. Nesse caso, a interação entre as partes é realizada por meio de uma ou outra API. A linha inferior é o serviço. A partir daqui, começa o processo de dividir o aplicativo em macro serviços, metroserviços, microsserviços, nanosserviços, picoserviços e funções lambda de linha única na Amazônia.
Parece que o que poderia dar errado aqui?
Infelizmente, dividir o aplicativo em partes não é gratuito. Primeiro, o custo do suporte à API dentro da infraestrutura está aumentando.
Suponha que um aplicativo precise trabalhar com arquivos. Uma tarefa típica. Um microsserviço que implementa a infraestrutura de armazenamento de arquivos é alocado e fornece duas operações: leitura e gravação. E sem alterações significativas na API, esse serviço pode crescer de uma interface para uma pasta em um disco local para uma infraestrutura de data center distribuída geograficamente. O cenário perfeito.
Mas e se o aplicativo for dividido em serviços de forma que as linhas ímpares da lógica de negócios terminem em um serviço e as linhas pares em outro? Essa separação não apenas desacelerará significativamente o aplicativo, já que agora, em vez de chamar diretamente o método, a comunicação de rede ocorrerá, assim a API entre os serviços mudará com tanta frequência que caberá na versão longa para o número da versão da API.
Isso é tudo, é claro, um exagero. No entanto, fornece uma imagem clara das possíveis consequências negativas. Um aplicativo criado dessa maneira é extremamente caro para desenvolver.
Antes de dividir o aplicativo em partes, dois aspectos devem ser considerados.
Primeiro. Com que frequência esses componentes interagem em uma única operação? É possível que, para cada ação, você precise executar centenas, senão milhares de chamadas de rede. Isso pode prejudicar o desempenho do aplicativo.
Segundo. Com que frequência a API muda entre os componentes? Se a história do git mostrar que a API mudará todos os dias, é provável que o custo de seu suporte seja proibitivo. Isso pode matar a produtividade do desenvolvimento.
No entanto, com a divisão correta do aplicativo em serviços, você pode obter benefícios significativos. Só que esses serviços não precisam ser micro.