🍂 🗒️ 📎 Microsserviços: o que é, por que é e quando é necessário implementá-los 🤴🏻 🛏️ 😦

Eu queria escrever um artigo sobre o tópico da arquitetura de microsserviço por um longo tempo, mas dois pontos pararam o tempo todo - quanto mais eu entrava no tópico, mais me parecia que o que eu sabia era óbvio e que eu não sabia, ainda tinha que estudar e estudar. Por outro lado, acredito que já exista algo para especular em uma ampla audiência. Portanto, opiniões alternativas são bem-vindas.

Direito de Conway e a relação entre negócios, organização e sistema de informação

Mais uma vez, permito-me citar:

“Qualquer organização que projeta um sistema (no sentido amplo) receberá um design cuja estrutura copia a estrutura das equipes nesta organização”
- Melvyn Conway, 1967

Na minha opinião, é mais provável que essa lei esteja relacionada à conveniência de organizar um negócio, e não diretamente ao sistema de informação. Vou explicar com um exemplo. Suponha que tenhamos uma oportunidade de negócios suficientemente estável com um ciclo de vida de tal duração que faça sentido organizar uma empresa (isso não é um erro de digitação, mas eu realmente gosto do termo que tirei). Naturalmente, o sistema de suporte dessa empresa será organizacional e processará de acordo com essa empresa. .

Sistemas de Informação para Orientação Empresarial

Vou explicar com um exemplo. Suponha que haja uma oportunidade de negócio para organizar um negócio de pizza. Na versão V1 (vamos chamar de pré-informativo), a empresa era uma pizzaria, caixa eletrônico, serviço de entrega. Esta versão durou muito tempo em condições de baixa variabilidade do mundo circundante. Em seguida, veio a versão 2, que era mais avançada e capaz de usar o sistema de informações como base para um negócio com arquitetura monolítica. E aqui, na minha opinião, há simplesmente uma injustiça terrível em relação aos monólitos - a arquitetura supostamente monolítica não corresponde ao modelo de negócios do domínio. Sim, se assim fosse, o sistema não teria sido capaz de funcionar, ao contrário da mesma lei de Conway e bom senso. Não, a arquitetura monolítica é totalmente consistente com o modelo de negócios neste estágio de desenvolvimento de negócios - é claro, quero dizer o estágio em que o sistema já foi criado e colocado em operação. É um fato absolutamente notável que, independentemente da abordagem arquitetural, a arquitetura orientada a serviços da versão 3 e a arquitetura de microsserviços da versão N funcionarão igualmente bem. Qual é o problema?

Tudo flui, tudo muda ou os microsserviços são uma maneira de lidar com a complexidade?

Antes de continuar, consideraremos alguns conceitos errados sobre a arquitetura de microsserviço.

Os defensores da abordagem de microsserviço costumam dizer 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 é totalmente sem sentido. Sério, a interação óbvia dentro de um monólito e um código homogêneo parece complicada? Se isso fosse verdade, todos os projetos seriam inicialmente construídos como microsserviços, enquanto a prática mostra que a migração de um monólito para microsserviços é muito mais comum. A complexidade não desaparece em lugar algum, simplesmente passa de módulos individuais para interfaces (sejam barramentos de dados, RPC, APIs e outros protocolos) e sistemas de orquestração. E é difícil!

A vantagem de usar uma pilha heterogênea também é duvidosa. Não vou argumentar que isso também é possível, mas raramente ocorre na realidade (olhando para o futuro - este deve ser o lugar para estar - mas mais como uma conseqüência do que como uma vantagem).

Ciclo de Vida do Produto e Ciclo de Vida do Serviço

Dê uma outra olhada no gráfico acima. Não foi 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 é crucial para seu sucesso. O sucesso do produto é determinado pela velocidade de testar hipóteses de negócios nele . E aqui, na minha opinião, a principal vantagem da arquitetura de microsserviços está enterrada. Mas vamos em ordem.

Vamos para o próximo passo na evolução dos sistemas de informação - para uma arquitetura SOA orientada a serviços. Então, em algum momento específico, destacamos serviços de longa duração em nosso produto- vida longa no sentido de que, ao alternar entre versões do produto, há uma chance de que o ciclo de vida do serviço seja mais longo que o ciclo de vida da próxima versão do produto. Seria lógico não alterá-los - a velocidade da transição para a próxima versão é importante para nós . Mas, infelizmente, somos forçados a fazer alterações constantes nos serviços - e aqui tudo nos convém, às práticas de DevOps, à conteinerização etc. - tudo o que vem à mente. Mas esses ainda não são microsserviços!

Microsserviços como ferramenta para combater a complexidade ... gerenciamento de configurações

E aqui podemos finalmente passar para a função definidora dos microsserviços - essa é uma abordagem que simplifica o gerenciamento da configuração do produto. Mais especificamente, a função de cada microsserviço descreve exatamente a função de negócios no produto de acordo com o modelo de domínio - e essas são coisas que vivem não em uma versão de curta duração, mas em uma oportunidade de negócios de longa duração. E a transição para a próxima versão do produto é literalmente imperceptível - você altera / adiciona um microsserviço, e talvez apenas o esquema da interação deles, e de repente se encontra no futuro, deixando concorrentes chorosos que continuam saltando entre as versões de seus monólitos. Agora imagine que exista um volume bastante grande de microsserviços com interfaces e oportunidades de negócios predefinidas.E você vem e constrói a estrutura do seu produto a partir de microsserviços prontos - apenas desenhando um diagrama, por exemplo. Parabéns - você tem uma plataforma - e agora pode ter seu próprio negócio. Sonhos Sonhos.

achados

A arquitetura do sistema deve ser determinada pelo ciclo de vida de seus componentes constituintes. Se um componente estiver dentro da versão do produto, não há sentido em aumentar a complexidade do sistema usando uma abordagem de microsserviço.
A arquitetura de microsserviço deve se basear em um modelo de domínio - pelo motivo de que a oportunidade de negócios é a área de maior duração
Práticas de entrega (práticas de DevOps) e orquestração têm um dos valores mais importantes para a arquitetura de microsserviço - pelo motivo de que o aumento da taxa de troca de componentes impõe demandas crescentes à velocidade e qualidade da entrega