Todo mundo está falando sobre microsserviços agora. Quase todas as reuniões, conferências e reuniões não são concluídas sem uma história sobre o que são os microsserviços e como são bons, como reduzem a complexidade do projeto etc.
A principal mensagem de todos esses relatórios - os microsserviços ajudam a evitar a complexidade e complexidade excessivas do projeto. Mas, quanto a mim, você não consegue se livrar da complexidade, não pode refazer o projeto para que tudo se torne simples ao mesmo tempo. A dificuldade passará de uma área para outra.
Por exemplo: havia um monólito emaranhado muito complicado, nós o dividimos em vários serviços, cada um deles parece ótimo, qualquer um pode descobrir o código, mas o que acontece com o ambiente? A complexidade está aumentando: são transações distribuídas que precisam ser registradas para entender que essa é uma transação única; CI / CD e entrega são adicionados para cada serviço; o esquema de interação se torna não trivial.
As teses ou declarações mais controversas que ouvi nos relatórios e com as quais estou pronto para discutir:
Entrar em um projeto monolítico é mais caro para os novos membros da equipe . Por alguma razão, é habitual avaliar o custo de ingressar em um projeto pela rapidez com que um novo desenvolvedor começa a executar tarefas. Sim, ele descobrirá isso em um pequeno serviço muito rapidamente e executará a tarefa muito rapidamente (especialmente de acordo com a especificação "o que eles escreveram, então eu fiz").
Mas e os outros membros da equipe?
O novo testador irá lidar com o modelo de integração. Testar um serviço é bom, mas, além de testar um contrato de serviço, você precisa verificar um processo de negócios que afeta vários serviços.
A princípio, o novo analista pode até quebrar a cabeça, até entender todos os meandros dos desafios internos.
Os microsserviços permitem que você libere com mais frequência . Os microsserviços são mais rápidos de refinar, porque são divididos em várias tarefas paralelas que são desenvolvidas e testadas em paralelo, e resta apenas verificar a integração (sem levar em consideração o tempo de análise).
Você também pode fazer isso com um monólito, tudo depende da decomposição da tarefa. Na maioria das vezes, no início, haverá uma tarefa - tornar a funcionalidade comum (corrigir o banco de dados geral ou finalizar a interface), e cada um verá suas subtarefas e as testará.
E o tempo de lançamento do recurso pelo qual a empresa paga será o mesmo. O recurso será fechado somente quando todos os componentes forem liberados. Os microsserviços podem resolver 99% das tarefas, mas até o último recurso ser fechado, eles não serão lançados na batalha.
Do que mais eles não estão falando
A dificuldade está crescendo
Ao usar microsserviços, a
infraestrutura é complicada . Isso se deve ao fato de que você precisa dar suporte ao trabalho de não um aplicativo, mas de muitos serviços. É necessário monitorar o desempenho de todos os serviços, entender bem as dependências dos serviços por versão, ter planos de CI / CD para montar serviços e entrega, mecanismos para responder a falhas de serviço, para que todo o resto não ocorra.
Parece coisas simples, e em um monólito devemos fazer o mesmo. Somente no monólito, trabalhamos em um aplicativo e, com o aumento do número de serviços, a complexidade aumenta, o que exige o suporte de habilidades mais altas.
Os microsserviços acrescentam complexidade - novas bibliotecas, novas funcionalidades para oferecer suporte a transações distribuídas, para lidar com erros de outros serviços, enviar solicitações repetidas, reverter transações. Na maioria das vezes, esses mecanismos serão comuns e a maioria dos desenvolvedores não entrará no clima, mas apenas os usará.
Mas pode haver erros neles que precisarão ser corrigidos. Se lidarmos com o reparo sem problemas, para implementar as alterações nos serviços 200-300, levará tempo e desenvolveremos controles. E se você precisar reconstruir os serviços com a biblioteca atualizada ou até refazer as chamadas (elas corrigiram assim, não previam isso), tudo isso não será divertido.
Monólito - não é uma grande bola de lama
Como as histórias sobre o belo mundo dos microsserviços geralmente começam? "Tivemos um monólito, era um sólido pedaço de lama, no qual tudo é confuso e incompreensível", além de mostrar uma imagem terrível. E o monólito já se tornou algo assustador: "você trabalhará mal, seu projeto se tornará um monólito".
Mas não.Um monólito pode ser (e deve) ser claro, estruturado, com código 'bom', com documentação, assim como um projeto de microsserviço pode se transformar em uma bola de sujeira ainda maior se você não se envolver em processos de desenvolvimento e não monitorar a qualidade do desenvolvimento.
Então o que usar?
Boa pergunta, e somente você pode responder. Porque somente você sabe quais problemas de negócios você decide, qual será o projeto. Não há bala de prata, não há arquitetura ideal que possa ser usada e sempre haverá “felicidade”.
E no monólito e nos microsserviços, siga a documentação e mantenha-a atualizada. Com a documentação é melhor do que sem ela.
Crie um processo de desenvolvimento no qual a qualidade do código só cresça (revisões, testes de unidade). Mas, sobre qualidade, você pode escrever um livro inteiro; esse é um tópico para uma grande conversa em separado.
Código simples e compreensível não é sobre microsserviços, o código deve ser assim a priori.
A automação de teste também tem a ver com a qualidade do código.
Automatize tudo o que você pode automatizar - CI / CD. Provavelmente, existe uma pilha de tecnologia muito difícil de obter no CI / CD, mas 99% dos conjuntos / entregas podem ser automatizados.