Executando verificação de segurança...
4

Microsserviços não precisam seguir o princípio da responsabilidade única, até porque isso é um pouco vago, só é famoso por causa do Uncle Bob e outros que se destacaram na área, e se for responsabilidade única no mesmo sentido S de SOLID, é tão pouco que teria que chamar de picosserviços, porque seria equivalente a uma função simples.

Tem-se a ideia que microsserviços precisa fazer poucas coisas, mas não há uma definição clara do que é pouco. A ideia principal é o desacoplamento, não da responsabilidade.

E é bom entender que um microsserviço não tem nada de mais. Ou que queria chamar de macrosserviço porque faz muitas coisas, mas é um serviço isolado e independente. Se você fizer um software que se comunica como o Facebook ele poderia ser um serviço (micro, midi, macro, não importa) da plataforma do Facebook. E isso é uma utilização que faz todo sentido.

O mesmo se aplica para serviços independentes e isolado dentro de uma empresa, cada unidade atua no desenvolvimento dos seus softwares do que jeito que bem entendem sem se preocupar muito com o que outras unidades estão fazendo. O que ela tem de compromisso é que se alguém precisa de uma informação que é propriedade daquela unidade será disponibilizada uma API para informar mudanças e outras unidades pegarem o que precisam ou foi mudado na sua unidade. Em tese essa API precisa ser estável, mas pode ter regras para quebrar a compatibilidade, desde que bem documentado com antecedência (geralmente).

A arquitetura de microsserviços que é mais do que apenas criar um ou mais microsserviços, é pensar que toda infraestrutura de software da empresa seja desacoplada e as se garanta que as unidades sejam livres para fazer o que quiserem dentro do seu domínio. A arquitetura é toda pensada assim. Do ponto de vista externo uma unidade só precisa garantir que todas as unidades possam ser servidas no que precisam, até mesmo envolvendo seu microsserviço em uma transação completa e talvez complexa.

Quero reforçar que nem sempre é assíncrona, embora o texto já tenha dito isso, pode não ficar claro para todos, existem situação que não pode ser assim, até porque pode não suportar consistência eventual, então ele ganha isso er abre mão da disponibilidade (a partição está lá sempre por definição no caso de microsserviços). Veja sobre Teorema CAP.

É possível ter ganho real com monólitos distribuídos pu só quebrados, só não são microsserviços.

Fazer microsserviços realmente resilientes tem uma complexidade que poucos conseguem executar, por isso é comum deixarem isso um pouco de lado, e vemos "frequentemente" quem adotou microsserviços saindo do ar.

De fato fazer a comunicação via banco de dados é um erro e acopla, o que deixa de ser microsserviços. Fazer tudo desacoplado de verdade, e pior, mantendo a coesão é um enorme desafio e o normal é encontrar arquiteturas cheias de falhas que podem aparecer com mais ou menos frequência (tem lugar que eu acesso e já sei que é microsserviços pelas falhas, geralmente momentâneas, que vejo ou pela lentidão de resposta (que pode ser outros fatores), ou não é arquitetura real de microsserviços.

Curiosamente é que a maioria dos microsserviços, se forem assim mesmo, podem rodar SQLite como banco de dados, de tão simples que fica o microsserviço em si (o problema é a integração entre eles). E por isso que muita gente usa MongoDB, ele pode não ser a melhor solução, mas é mais uma modinha a seguir, e de tão simples que fica que até ele serve muito bem, mesmo quando não for o mais adequado (tem casos que ele pode ser a melhor opção).

Não sei se o encadeamento grande faz a arquitetura deixar de ser de microsserviços, mas que é ruim eu não tenho dúvida.

No caso da observabilidade não tem relação com microsserviços, embora com eles se torna fundamental ter algo bem implementando nesse sentido.

Quase ninguém precisa de uma arquitetura de microsserviços, do ponto de vista de escala, sempre dá para escalar com arquiteturas mais simples, e do ponto de vista organizacional pode ser útil ou não. Microsserviços é complexo demais, quase ninguém faz direito, custa muito mais caro em termos financeiros seja na implementação, seja na execução e traz algumas desvantagens relevantes em muitos cenários.

Aí cabe a imagem famosa, que apesar de ser jocosa é muito real, e talvez por ser engraçada as pessoas não levam tanto a sério. Faça seu monólito bem-feito, se realmente puder provar que ainda precisa de microsserviços depois disso, então comece fazer alguns experimentos para ver se dará o resultado que espera.

um monte de bosta grande representando o monólito e um monte de montinhos pequenos representando microsserviços

Arquitetura de microsserviços é uma das maiores modinhas que já apareceu.

S2


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

Carregando publicação patrocinada...
3

Você trouxe pontos muito válidos e provocativos, mas gostaria de oferecer uma perspectiva adicional sobre o que é, de fato, um microsserviço e como ele se encaixa no que chamamos de "responsabilidade única".

Primeiramente, eu concordo que o tamanho do microsserviço não deve ser a principal preocupação. A ideia de que ele precisa ser pequeno é uma concepção errada que se popularizou sem muita análise. O mais importante é que o microsserviço seja independente e isolado, sem dependências diretas e sem ser acoplado a outros serviços. Então, a grande questão aqui não é "quantas coisas o serviço faz", mas sim o nível de desacoplamento que ele oferece.

Quando você fala sobre o uso do SQLite, por exemplo, achei um ponto interessante. Se um microsserviço for realmente autossuficiente e isolado, é possível usar um banco de dados simples e até local, sem a necessidade de algo complexo como MongoDB ou bancos distribuídos. A questão aqui não é a tecnologia, mas como os serviços se comunicam entre si e como garantimos a resiliência sem perder a independência.

Agora, concordo com a crítica de que muitos microsserviços acabam falhando na prática. Quando os serviços dependem de encadeamentos pesados e de um único banco de dados compartilhado, você está essencialmente voltando ao modelo de monólito, só que de forma distribuída. Essa integração mal feita é o que gera problemas de latência, falhas momentâneas e até mesmo aumento da complexidade.

E quanto à questão da observabilidade e monitoramento, acredito que o maior erro que vejo no mercado é achar que dividir o sistema em microsserviços resolve todos os problemas de escalabilidade e manutenção. O custo real dos microsserviços vai muito além de implementar a arquitetura, envolve uma série de ferramentas, processos e integração contínua que muitas empresas não estão preparadas para manter. Então, sim, fazer microsserviços é mais caro e mais complexo. Muitas vezes, um bom monólito bem estruturado e desacoplado pode oferecer tudo o que um microsserviço faria, mas com muito menos overhead.

Finalmente, queria reforçar que, ao adotar microsserviços, o ponto central é garantir que cada unidade seja livre para evoluir de forma independente, sem se preocupar com o que outras unidades estão fazendo. E para que isso aconteça, a infraestrutura e os processos de comunicação (principalmente via API) precisam estar bem definidos, para não acabar criando um sistema em que os microsserviços não são realmente independentes, mas sim apenas "endpoints" desacoplados artificialmente.

Microsserviços são uma ótima solução, mas não são uma bala de prata. Como você mesmo mencionou, é preciso avaliar se o benefício real vale o custo e o nível de complexidade.


O que você acha dos 12 fatores pra uma apliacação web ?

1

Manda fonte que eu achop que não conheço esses 12 fatores, ou também posso ter esbarrado nele e de tão irrelevante eu já esqueci.

Depois eu fui ver a fonte primária e já estava nos meus bookmarks.

2

A teoria é bonita, parece até uma fábula bem contada. Mas a realidade é outra história. No mundo real, essa ideia raramente se encaixa — na prática, em 99% dos casos, as coisas não funcionam desse jeito. É fácil falar quando tudo está no papel, mas quando colocamos a mão na massa, a situação muda completamente.

o que mais vi nessa jornada foram devs seguindo esse caminho, enche o produto que era simples de complexidade e vai embora da empresa. quem fica precisa depois trabalhar em algo complexo em um sistema que algo simples resolveria, e com isso aumenta o custo da empresa, pois para coisas simples precisa de no minimo um pleno por complexidade desnecessaria.

4

Eu já dei uma consultoria que estavm reclamando da performance do sistema feito em microsserviços. Perguntei porque eles adotaram essa tecnologia e me disseram que era pra performance. Mandei refazer monoliticamente, a performance veio. O nível do deslumbramento é impressionante.

2

Eu recentemente fui implementar isso em um trabalho, nossa que dor organizar o projeto da forma como se pede nos 12 fatores, muito rigido.
Mas é claro que tem contextos que esses 12 fatores são essenciais.

1

Monoliticamente falando, como que funciona a questão de atualização?
Por exemplo, tenho um sistema que partes dele são críticas, necessário executar 24 horas por dia e com um fluxo intenso de informações transacionandos e que conversam com outras API's.
E em uma parte do sistema não tão critica precisa subir uma atualização, pois necessitam de realizar um cadastro, por exemplo que esta com bug. Qual um meio de não impactar a parte critica do sistema?

1

Depende de uma série de coisa, desde a tecnologia usada, a necessidade específica. Pode ser qu tenha executáveis separados ou scripts que por definição são separados, pode usar feature flag, * blue–green deployment* e várias outras técnicas. Engenheiros acham a solução para tudo, que não é segue modinha.