Legal, vai ajudar muita gente. Vou complementar uma conclusão que muitos podem não fazer:
Microsserviços são muito complexos, muitos pontos para dar errado, especialmente quando a equipe não é coesa E altamente qualificada e experiente, ou seja, algo raro de achar. Também podemos concluir que em muitos casos microsserviços criam mais problemas do que soluções, o que torna ainda mais raro ele ser uma opção boa, e principalmente melhor que um bom monólito.
Vamos lembrar que algumas das maiores plataformas existentes no mundo não precisam de microsserviços para escala a demanda. E em boas equipes é possível manter um desenvolvimento organizado sem microsserviços em uma solução pensada para ser um bom monólito distribuído, o que pode ser o melhor dos dois mundos (pode ser o pior dos dois quando feito errado ou sem querer).
Em microsserviços precisamos saber sobre o CAP theorem, que afirma que você pode ter duas dessas propriedades, mas não as três. Em sistemas distribuídos, verdadeiramente, a partição (Partition) é obrigatória, portanto temos que escolher entre consistência (Consistency) ou disponibilidade (Availability).
Como bem demonstrado, casos como o cliente estar apto a fazer um pedido ou ter estoque para completar o pedido exigem consistência, o que torna os serviços dependentes e diminui a vantagem de modularizar por completo o sistema. A solução de garantia de disponibilidade de todas as informações necessárias cria um problema de consistência que pode ou não ser aceitável, ter sua própria visão de dados impede consistência ou disponibilidade. Algumas das soluções propostas podem inviabilizar uma ou outra propriedade. Quando se perde a paciência, acaba-se abrindo mão da partição, o que deixa de ser microsserviços.
Existem técnicas para melhorar a performance e parecer melhor disponível, ajudando na UX w existem maneiras extremamente complexas para rotear o fluxo de informações de forma diferente quando um serviço que centraliza a verdade, cai.
Problemas que não precisam de consistência tendem a ser mais praticáveis como microsserviços, mesmo assim vemos exemplos no mercado que não é fácil de organizar, ou a falta de consistência, apesar de não ser crítica, é ruim pelo menos para a UX.
Quando precisa de consistência, uma solução para dar disponibilidade, não total, é ter um serviço replicado alguma vezes, o mesmo que se faz em um monólito para melhorar a disponibilidade. O problema é que as réplicas, todas ou por consenso, precisam confirmar entre si que a verdade está disponível de forma consistente entre elas, o que atrasa ou impede a continuidade, o que não deixa de ser uma indisponibilidade, ainda que momentânea.
Você, leitor, consegue provar que microsserviços vão trazer uma vantagem que pode compensar toda a complicação vista acima? Não pode fazer apenas alguns pontos serem microsserviços?
A equipe não vai se perder nessa complicação toda?
Não terá brigas políticas internas porque uma equipe depende de outra fornecer algo que ela precisa e pode haver negação?
Não farão coisas horríveis para compensar essa falta?
Não ter que usar e/ou criar ferramentas complexas para gerenciar tudo isso, como mensageria, orquestrações ou até em alguns casos grandes, como sabemos que acontece em certas plataformas, onde se cria praticamente um banco de dados para funcionar tudo de forma mais simples, e até existem casos que praticamente um sistema operacional para deixa tudo mais transparente?
Já parou para pensar que tem motivos para muitas empresas terem voltado atrás em microsserviços? Que diminuíram só onde realmente tem vantagem? Que estão operando hoje com mais dificuldades de desenvolvimento do que antes e tornando tudo lento? Que criaram muitas dívidas técnicas? Que está tudo mais caro e lento de fazer? Que ninguém mais entende o que acontece com o sistema? Preste atenção nas entrelinhas de equipes famosas que usam microsserviços, algumas que fizeram a arquitetura se popularizar. E entende que alguns casos só não são trágicos porque, apesar de chamar de microsserviços, estão usando um monólito distribuído, e ele funciona?
Minha regra de ouro seria: microsserviço bom é aquele que traz mais vantagens que desvantagens. Releia o texto com a ideia que o que está aí são desvantagens e não vantagens. E aí podemos pensar em outra regra de ouro: microsserviço bom é aquele que não é necessário. Isto é uma alusão a muitas coisas em desenvolvimento de softwares ou criação de quaisquer tipos de sistemas (mesmo não softwares), o melhor sempre é o que não existe, porque gera menos complicação.
Só citando um exemplo, os primeiros carros eram elétricos, porque são muito mais simples que a movimentação a combustão. No passado as desvantagens eram grandes demais e a combustão venceu. Agora está mudando, já é vantajoso na maioria dos casos e será em quase todos no futuro. Se for possível, o mais simples sempre é melhor. Microsserviços só são simples se for apenas uma peça de marketing, em engenharia isso não acontece.
Para o autor, em textos simples e despretensiosos não precisa mais que isso, mas um texto bem trabalhado, cheio de informação útil, se torna muito mais útil com fontes explícitas, até para a pessoa se aprofundar mais, tentar enxergar melhor o próprio caso. Também deveria ser uma "boa prática" hoje em dia um disclaimer em textos interessantes, informando como a IA foi usada.
Também seria útil explicar alguns dos conceitos e técnicas apresentadas em uma futura publicação, se possível avaliando as vantagens e desvantagens de cada.
Este é um assunto que provavelmente ocorre um dos maiores índices de insanidade na adoção. E isto é bem humano. Faça uma reflexão em todas as atitudes na humanidade. Também é humano negar a própria insanidade ou de outros. Temos alguns vieses que explicam isso, o principal, provavelmente o de confirmação. EU nego que eu seja insano :D
S2
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).