Eu queria escrever um artigo sobre arquitetura de microsserviços há muito tempo, mas sempre fui interrompido por duas razões — quanto mais eu me aprofundava no tema, mais parecia que o que eu sabia era óbvio e o que não sabia exigia muito mais estudo. Por outro lado, acredito que já há bastante assunto para refletir e discutir com um público mais amplo. Portanto, opiniões alternativas são bem-vindas.
A Lei de Conway e a relação entre negócios, organização e sistema de informação
Mais uma vez, permitirei-me citar:
«Qualquer organização que projete um sistema (no sentido amplo) obterá um design cuja estrutura reflete a estrutura das equipes nessa organização»
— Melvyn Conway, 1967
Na minha opinião, essa lei está mais relacionada à adequação da organização dos negócios do que diretamente ao sistema de informação. Vou explicar com um exemplo. Suponha que temos uma oportunidade de negócio estável com um ciclo de vida suficientemente longo para justificar a organização do empreendimento (não é um erro de digitação, mas gosto muito desse termo que eu peguei emprestado). É claro que o sistema que apoia esse negócio será organizacional e processualmente adequado a esse negócio.
Orientação para o negócio dos sistemas de informação
Vou explicar com um exemplo. Suponha que existe uma oportunidade de negócio para organizar a venda de pizzas. Na versão V1 (vamos chamá-la de versão pré-informacional), a empresa era uma pizzaria, um caixa e um serviço de entrega. Essa versão teve uma longa duração em um ambiente de baixo dinamismo. Então, surgiu a versão 2 — mais avançada e capaz de utilizar um sistema de informação como base para um negócio com uma arquitetura monolítica. E aqui, na minha opinião, surge uma injustiça terrível em relação aos monolíticos — supostamente a arquitetura monolítica não corresponde ao modelo de domínio do negócio. Se assim fosse, o sistema não conseguiria funcionar de forma alguma - em contrariedade à mesma lei de Conway e ao bom senso. Não, a arquitetura monolítica está completamente alinhada ao modelo de negócios nesta fase de desenvolvimento empresarial — quero dizer, na fase em que o sistema já foi criado e colocado em operação. É um fato notável que, independentemente da abordagem arquitetônica, a arquitetura orientada a serviços da versão 3 e a arquitetura de microsserviços da versão N funcionam igualmente bem. Qual é o truque?
Tudo flui, tudo muda ou os microsserviços são uma forma de combater a complexidade?
Antes de continuar, vamos considerar algumas ideias errôneas sobre a arquitetura de microsserviços.
Os defensores do uso da abordagem de microsserviços frequentemente afirmam que dividir um monólito em microsserviços simplifica a abordagem de desenvolvimento ao reduzir a base de código de serviços individuais. Na minha opinião, essa afirmação é totalmente absurda. Sério, a interação óbvia dentro de um monólito e um código homogêneo parece complexa? Se fosse realmente assim, todos os projetos seriam originalmente construídos como microsserviços, enquanto a prática mostra que a migração de monólitos para microsserviços é muito mais comum. A complexidade não desaparece, apenas se transfere de módulos individuais para interfaces (sejam barramentos de dados, RPC, API e outros protocolos) e sistemas orquestradores. E isso é complicado!
A vantagem de usar uma pilha heterogênea também é duvidosa. Não vou discutir que isso é possível, mas na realidade é raro (Aproveitando, isso deve acontecer — mas mais como consequência do que como vantagem).
Ciclo de vida do produto e ciclo de vida do serviço
Dê uma olhada novamente no diagrama acima. Não marquei por acaso o ciclo de vida reduzido de uma versão de negócios — nas condições modernas, acelerar a transição entre versões é o que determina o sucesso do negócio. O sucesso do produto é definido pela velocidade em que as hipóteses de negócios são testadas nele.. E é aqui que, na minha opinião, está a chave da principal vantagem da arquitetura de microsserviços. Mas vamos por partes.
Vamos avançar para o próximo nível da evolução dos sistemas de informação — para a arquitetura orientada a serviços SOA. Assim, em algum momento específico, destacamos em nosso produto serviços duradouros — duradouros no sentido de que, ao migrar entre versões do produto, há chances de que o ciclo de vida do serviço seja mais longo do que o ciclo de vida da próxima versão do produto. Seria lógico não alterá-los de forma alguma — o que nos importa é a velocidade de transição para a próxima versão. Mas, infelizmente, somos forçados a fazer mudanças constantes nos serviços — e aqui tudo serve, desde práticas DevOps, containerização, e outras coisas que vierem à mente. Mas isso ainda não são microserviços!
Microserviços como uma ferramenta para combater a complexidade… gestão da configuração
E é aqui que podemos finalmente abordar o papel definidor dos microserviços — é uma abordagem que simplifica a gestão da configuração do produto. Em termos mais detalhados, a função de cada microserviço descreve exatamente uma função de negócios dentro do produto de acordo com o modelo de domínio — e essas já são coisas que não vivem numa versão de curta duração, mas sim numa oportunidade de negócios de longa duração. E a transição para a próxima versão do produto ocorre de forma literal e imperceptível — você altera/adiciona um microserviço, ou talvez apenas o esquema de sua interação, e de repente se vê no futuro, deixando para trás concorrentes que continuam a pular entre as versões de seus monólitos. Agora, imagine que você tem um volume suficientemente grande de microserviços com interfaces e oportunidades de negócios previamente definidas. Você chega e constrói a estrutura de seu produto a partir de microserviços prontos — simplesmente desenhando um diagrama, por exemplo. Parabéns — você tem uma plataforma — e agora pode clicar para construir o seu negócio. Sonhos, sonhos.
Como resultado, obtemos um serviço de "monitoramento como serviço", automatizado na linha de produção de integração contínua. O desenvolvedor ou testador precisa apenas definir a lista de métricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lançamentos: todas as notificações sobre desempenho, consumo de recursos ou regressões arquitetônicas.
- A arquitetura do sistema deve ser definida pelo ciclo de vida dos componentes que a compõem. Se um componente vive dentro da versão do produto — não faz sentido aumentar a complexidade do sistema, aplicando uma abordagem de microserviços.
- A arquitetura microserviço deve se basear no modelo de domínio — pela razão de que a oportunidade de negócios é a área mais duradoura.
- As práticas de entrega (práticas de DevOps) e orquestração têm um dos papéis mais importantes para a arquitetura de microsserviços — porque o aumento da velocidade de alteração dos componentes impõe maiores exigências à rapidez e qualidade de entrega.
Fonte: habr.com
