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.
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.
Parece que uma boa prática geral de codificação é saudável, combinada com um pouco de gerenciamento aprimorado da base de código, mas fica aquém do caminho "não é necessário atualizar o monólito inteiro em uma pequena atualização de serviço", que é onde eu espero que os microsserviços brilhar. De qualquer forma, bons conselhos, obrigado.
— Jleach # 22/18
Concordo totalmente com a resposta. Um monólito bem construído e modularizado corretamente fornece a maioria (embora não todos) dos benefícios dos microsserviços. Por outro lado, os microsserviços têm seus próprios problemas bastante grandes.
— Milos Mrdovic 23/04/19
@jleach Uma qualidade de boa modularização é a implantação independente. Se você precisar recompilar e reimplantar todo o seu monólito para fazer uma pequena atualização do módulo, você está fazendo algo errado.
— Milos Mrdovic
Essa é uma boa abordagem. Não construa um microsserviço para o fazer. A arquitetura de microsserviço deve ser usada para resolver problemas, mas eles também vêm com um conjunto de problemas próprios; portanto, se você não estiver pronto / ciente dessas compensações, tenha muito cuidado ao desenvolver o microsserviço desde o início.
@MilosMrdovic, mesmo com a abordagem de módulo, você ainda pode obter alguma eficiência na implantação, pois não precisa testar novamente todo o seu monólito, apenas o módulo que está sendo atualizado. Se o seu módulo passar por todas as portas de qualidade, você poderá construí-lo e enviá-lo. Então seu monólito só precisa atualizar sua versão de dependência e reimplementar. Você não precisará reconstruir nenhum outro módulo.
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.
"E, nesses casos, um microsserviço pode ser mais fácil de desenvolver" - você quis falar sobre monólitos lá?
@amon Obrigado, eu ter corrigido a sentença - o meu filho fez interrupção me 34235 vezes, então eu estava confuso;)
Embora eu concorde com sua primeira frase, acho que você deve considerar que mesmo seu monólito já deve ser "modular" por dentro, caso contrário, você simplesmente não será capaz de separar nada sem que tudo caia.
@ Walfrat Eu costumo concordar, mas a tentação de reutilizar o código existente é muito maior (e menos facilmente esmagada) em um monólito. Por exemplo, "oh olhar, alguém definiu uma widgetid, eu vou apenas reutilização que para o meu FormId": Além disso, você não pode facilmente usar outra língua / db para um projeto, o que realmente promove a "todos devem usar ferramentas comuns" pensamento
Tenho certeza de que houve algumas perguntas sobre este artigo exato da MF.
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.
Obrigado. Se MF tende a ser ligeiramente tendencioso, existe alguém cujo trabalho eu possa estudar do lado oposto para ajudar a ganhar profundidade de perspectiva?
Eu não recomendaria 'celebridades da web' como recurso de aprendizado. Tudo bem para algumas histórias e uma conversa divertida, mas na minha experiência é o detalhe que faz toda a diferença entre sucesso e fracasso.
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.
— Engenheiro de software
Na verdade, os microsserviços resolvem muitos problemas organizacionais. Se cada serviço tiver um proprietário, você saberá como engasgar quando algo não funcionar.
@ jiggy: se o código estiver bem modularizado, você não precisará necessariamente dividi-lo em vários serviços para saber quem deve engasgar.
@ Ryan, se alguém pensa que microsserviços e modularização são sinônimos, eles perderam completamente o objetivo.