Microsserviços: MonolithFirst?

Pesquisei arquiteturas de microsserviços tentando obter uma visão geral de alto nível de todos os prós e contras, por que e por que, etc. Muitas das informações que estou lendo / assistindo são provenientes da ThoughtWorks (Martin Fowler, Neal Ford, etc.). al).

A maior parte do trabalho de Martin Fowler sobre o assunto tem alguns anos, quando a Microservices (como um nome familiar em programação, se não na prática geral) ainda era jovem, por isso tomo muito disso com um pouco de sal.

Uma coisa em particular é esta:

Ao ouvir histórias sobre equipes que usam uma arquitetura de microsserviços, notei um padrão comum.

• Quase todas as histórias de microsserviços bem-sucedidas começaram com um monólito muito grande e dividido
• Quase todos os casos em que ouvi falar de um sistema que foi construído como um sistema de microsserviço do zero, acabaram em sérios problemas.

Esse padrão levou muitos de meus colegas a argumentar que você não deve iniciar um novo projeto com microsserviços, mesmo que tenha certeza de que seu aplicativo será grande o suficiente para fazer valer a pena. .

(ref: https://martinfowler.com/bliki/MonolithFirst.html - ênfase deles)

Agora, três anos depois e com microsserviços um termo mais onipresente, é geralmente aceitável que um novo sistema seja tipicamente melhor atendido por ter blocos de serviço maiores (-sem-microsserviço-mas-menor-que-monólito) para começar e fazer eles mais granulares como parte de uma medida evolutiva?

Ou existe uma norma para iniciar um projeto do zero com uma arquitetura granular de microsserviços, em contraste com as declarações acima?

Parece uma abordagem geral sã, mas curiosa dos pensamentos da comunidade.

Se sua empresa já faz microsserviços há algum tempo, algumas peças já podem ser construídas e você simplesmente precisa incorporá-las. Exemplos prováveis ​​podem ser autenticação como serviço ou armazenamento de dados de blob. Nesse caso, você já definiu os limites e está reutilizando o código em um novo aplicativo. Isso é uma coisa boa.

Para um novo código em que você não tem certeza de onde o limite precisa estar, crie-o em um serviço. Se você o mantiver modular, poderá separar os microsserviços, conforme necessário. Especialmente quando você encontra peças do seu serviço que precisam ser dimensionadas de maneira diferente das demais.

O benefício dos microsserviços é que você pode adicionar instâncias para dimensionar o trabalho que está sendo feito sob demanda. Se parte do seu trabalho ocorre em excesso, pode fazer sentido separá-lo em seu próprio microsserviço.

Em geral:

• Se você já possui microsserviços criados, reutilize-os
• Se você estiver criando algo novo, faça a ideia funcionar primeiro
• Enquanto você constrói, tente manter as coisas modulares para que alguns serviços possam ser facilmente quebrados
• Conforme você está construindo, se parte do seu serviço precisar ser dimensionada sob demanda a uma taxa diferente, separe-a no próprio serviço

Com demasiada frequência, ouvimos orientações úteis de pessoas inteligentes com boa reputação como Martin Fowler e depois a transformamos em uma doutrina rígida que não pode ser influenciada de forma alguma.

Você tem que tomar declarações como essa no espírito de como elas são feitas. Martin Fowler está tentando salvar as pessoas da paralisia por análise e diz-lhes para construir algo que funcione primeiro. Você sempre pode separá-lo mais tarde, quando souber mais sobre como seu aplicativo realmente funciona.

Os benefícios mais imediatamente valiosos dos microsserviços podem ser alcançados através da modularização simples do código. Você pode isolar grupos de recursos em módulos usando o sistema de módulos que você possui (maven, npm, nuget, qualquer que seja). Cada módulo pode servir a um único propósito, manter seu próprio repositório, usar seu próprio esquema de banco de dados, gerenciar sua própria configuração, ter seu próprio backlog de recursos e cronograma de lançamento. Eles ainda podem ser implantados juntos em um monólito. Essa é uma quantidade muito gerenciável de sobrecarga e oferece alguns bons benefícios. A sobrecarga maior vem da separação de implantações, que só é realmente valiosa quando você tem escala suficiente para precisar. Se seu código já é modular, será uma migração mais fácil quando chegar a hora.

Na minha opinião, pode ser benéfico desenvolver um monólito primeiro (ou melhor: desenvolver partes de sua aplicação como monólito).

Há casos em que você não tem certeza sobre o domínio e os limites do seu problema (por exemplo, eu construo um site de gerenciamento de navios, preciso de um serviço de navio E um serviço de frota ou um serviço de navio é suficiente?) E, nesses casos, um o monólito pode ser mais fácil de desenvolver.

Você deve parar de fazer isso se precisar incluir tecnologias diferentes (por exemplo, suas partes existentes são escritas em C #, mas seu novo problema requer aprendizado de máquina, o que é melhor fazer com python), tenha um bom entendimento sobre os domínios em seu projeto ou seu monólito trata de galvanizar, por exemplo, todo mundo constrói esse monólito e esmaga a noção de serviços separados.

Tenho certeza de que houve algumas perguntas sobre este artigo exato da MF.

Minha opinião é a seguinte:

Um monólito com problemas de manutenção ou escalabilidade é aprimorado dividindo-o em microsserviços. Um projeto como esse quase sempre será "bem-sucedido", pois mesmo dividir uma seção pequena pode resultar em ganhos mensuráveis ​​e você pode desenhar uma linha embaixo dela quando estiver feliz.

Quer a sua metade monólito + uma fila de mensagens e um par de processos de trabalho conta como 'Microservice Architecture' é um argumento a ter para o bar, mas você definitivamente vai ser chamar -se que quando você fala sobre o projeto.

Por outro lado, qualquer novo projeto, independentemente da arquitetura escolhida, corre o risco de não atender às expectativas; portanto, naturalmente, você esperaria uma menor taxa de sucesso. Além disso, se você começou com o objetivo de criar a coisa toda 'Arquitetura de microsserviço de práticas recomendadas' desde o início, pode estar se aventurando em novas tecnologias e nas partes mais difíceis dos microsserviços.

Também devemos lembrar que MF escreve de uma grande perspectiva de OOP. Ele é naturalmente cético em relação a uma abordagem distribuída mais moderna.

Hoje em dia, eu esperaria que qualquer solução de grandes empresas incorporasse um elemento de microsserviços, e apenas um tolo recomendaria que você fizesse um aplicativo gigante de monólito, a menos que esteja distribuindo um único aplicativo de estilo desktop.

Na minha (vasta) experiência, testemunhei muitos outros projetos falharem por causa de problemas de pessoas do que de tecnologia. Infelizmente, as pessoas não gostam de falhar e, portanto, tendem a relatar mal as razões da falha e culpar a tecnologia.

No meu domínio, finanças, a maioria dos novos projetos segue arquiteturas de microsserviço hoje em dia, e parece ser uma arquitetura vencedora da perspectiva do TCO (custo total de propriedade). Esses projetos não parecem falhar com tanta frequência e, quando o fazem, os motivos apresentados não costumam listar a arquitetura do aplicativo como o problema.