Há muito tempo eu queria escrever um artigo sobre o tema arquitetura de microsserviços, mas duas coisas me impediam - quanto mais eu mergulhava no assunto, mais me parecia que o que eu sei é óbvio, e o que eu não ' não sei precisa ser estudado e estudado. Por outro lado, acho que já há algo para discutir entre um público amplo. Portanto, opiniões alternativas são bem-vindas.
A Lei de Conway e a relação entre negócio, organização e sistema de informação
Mais uma vez me permitirei citar:
“Qualquer organização que projete um sistema (no sentido amplo) receberá um projeto cuja estrutura replica a estrutura das equipes daquela organização.”
-Melvyn Conway, 1967
Na minha opinião, é mais provável que esta lei esteja relacionada com a viabilidade de organização de uma empresa, e não diretamente com o sistema de informação. Deixe-me explicar com um exemplo. Digamos que temos uma oportunidade de negócio bastante estável com um ciclo de vida de tal duração que faz sentido organizar uma empresa (isto não é um erro de digitação, mas gosto muito deste termo que roubei). Naturalmente, o sistema de suporte deste negócio corresponderá organizacional e processualmente a este negócio.
Orientação empresarial de sistemas de informação
Deixe-me explicar com um exemplo. Digamos que haja uma oportunidade de negócio para organizar um negócio de venda de pizza. Na versão V1 (vamos chamar de pré-informação), a empresa era uma pizzaria, uma caixa registradora e um serviço de delivery. Esta versão teve vida longa em condições de baixa variabilidade ambiental. Então veio para substituí-lo a versão 2 - mais avançada e capaz de usar um sistema de informação em sua essência para negócios com uma arquitetura monolítica. E aqui, na minha opinião, existe simplesmente uma terrível injustiça em relação aos monólitos - arquitetura supostamente monolítica não corresponde ao modelo de negócios do domínio. Sim, se assim fosse, o sistema não conseguiria funcionar de todo - em contradição com a mesma lei de Conway e o bom senso. Não, a arquitetura monolítica é totalmente consistente com o modelo de negócios nesta fase de desenvolvimento de negócios - quero dizer, é claro, a fase em que o sistema já foi criado e colocado em operação. É um fato absolutamente maravilhoso que, independentemente da abordagem arquitetônica, tanto a versão 3 da arquitetura orientada a serviços quanto a versão N da arquitetura orientada a serviços funcionarão igualmente bem. Qual é o problema?
Tudo flui, tudo muda ou os microsserviços são um meio de combater a complexidade?
Antes de continuarmos, vejamos alguns equívocos sobre a arquitetura de microsserviços.
Os proponentes do uso de uma abordagem de microsserviços frequentemente argumentam que dividir um monólito em microsserviços simplifica a abordagem de desenvolvimento, reduzindo a base de código de serviços individuais. Na minha opinião, esta afirmação é um completo absurdo. Sério, a interação óbvia dentro de um código monólito e homogêneo parece complicada? Se este fosse realmente o caso, todos os projetos seriam inicialmente construídos como microsserviços, embora a prática mostre que a migração de um monólito para microsserviços é muito mais comum. A complexidade não desaparece; ela simplesmente passa de módulos individuais para interfaces (sejam barramentos de dados, RPC, APIs ou outros protocolos) e sistemas de orquestração. E isso é difícil!
A vantagem de usar uma pilha heterogênea também é questionável. Não vou argumentar que isso também é possível, mas na realidade raramente ocorre (Olhando para frente - isso deveria acontecer - mas mais como consequência do que como vantagem).
Ciclo de vida do produto e ciclo de vida do serviço
Dê outra olhada no diagrama acima. Não é por acaso que notei a diminuição do ciclo de vida de uma versão separada de um negócio - nas condições modernas, é a aceleração da transição de um negócio entre versões que é decisiva para o seu sucesso. O sucesso de um produto é determinado pela velocidade de teste das hipóteses de negócios nele. E aqui, na minha opinião, reside a principal vantagem da arquitetura de microsserviços. Mas vamos em ordem.
Vamos passar para o próximo estágio na evolução dos sistemas de informação - para a arquitetura SOA orientada a serviços. Então, em algum momento destacamos em nosso produto serviços de longa duração - de longa duração, no sentido de que, ao alternar entre versões de um produto, existe a possibilidade 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 os alterar de todo - nós O que 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 funciona para nós, práticas de DevOps, conteinerização e assim por diante - tudo o que vem à mente. Mas ainda não são microsserviços!
Microsserviços como forma de combater a complexidade... gerenciamento de configuração
E aqui podemos finalmente passar para o papel definidor dos microsserviços - esta é uma abordagem que simplifica o gerenciamento da configuração do produto. Mais detalhadamente, a função de cada microsserviço descreve exatamente a função de negócio dentro do produto de acordo com o modelo de domínio – e essas são coisas que não vivem em uma versão de curta duração, mas em uma oportunidade de negócio de longa duração. E a transição para a próxima versão do produto acontece literalmente despercebida - você altera/adiciona um microsserviço, e talvez apenas o esquema de sua interação, e de repente você se encontra no futuro, deixando para trás concorrentes chorosos que continuam a saltar entre versões de seus monólitos. Agora imagine que existe um volume bastante grande de microsserviços com interfaces e capacidades de negócios predefinidas. E você vem e constrói a estrutura do seu produto a partir de microsserviços prontos – simplesmente desenhando um diagrama, por exemplo. Parabéns - você tem uma plataforma - e agora pode atrair negócios para si mesmo. Sonhos Sonhos.
Descobertas
- A arquitetura do sistema deve ser determinada pelo ciclo de vida dos seus componentes. Se um componente reside em uma versão do produto, não faz sentido aumentar a complexidade do sistema usando uma abordagem de microsserviço.
- A arquitetura de microsserviços deve ser baseada no modelo de domínio – porque a oportunidade de negócio é o domínio de maior duração
- As práticas de entrega (práticas de DevOps) e orquestração são uma das mais importantes para a arquitetura de microsserviços - porque o aumento na taxa de mudança de componentes impõe demandas crescentes na velocidade e qualidade da entrega
Fonte: habr.com