Microserviços vs Monolito, o que você acha?

Obrigado por esse relato. Eu vivo falando disso, já fiz até palestras sobre. Tem gente que nem gosta. E uso o exemplo do Stack Overflow. As pessoas adotam pora por no currículo, não adotam porque precisa. Nunca ninguém provou pra mim que a empresa "minúscula" que ela trabalha precisava mesmo de uma arquitetura complexa dessas. Já dei consultoria que foi bem simples, mandei tirar, os problemas acabaram.

Espero ter ajudado.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Acho que uma das coisas que se precisa ter em mente é que a estratégia arquitetural tem muita relação na organização de times e tamanho da empresa também. Uma abordagem de micro-servicos permite times mais descentralizados e uma interação entre times bem diferentes do que o que se tem em arquiteturas monóliticas. Claro que você pode tambem ter times descentralizados em arquiteturas monoliticas mas não é tão natural quanto em um ambiente de micro-servicos.

Voltando ao aspecto tecnologico, é verdade que é possivel escalar recursos com monólitos temos bons casos disso (stackoverflow). Mas microservico não é somente sobre escalabilidade. É tambem sobre processos desenvolvimento, então servicos diferentes podem ter decisões de tecnologia e processos de deploy bem diferentes, que atendam a necessidade do servico especifico. É muito mais some o dinamismo do desenvolvimento do que somente escalabilidade. Ela é um efeito de um bom sistema distribuido.

Sistemas distribuidos são normalmente mais complexos que monólitos e acho que antes de se tomar uma decisão de usar microservicos se deve ter em mente as necessidades de negocio e o momento da empresa. Nunca deve ser uma decisão puramente tecnologica. Há metodos pra se escalar monolitos que podem ser mais custosos, a principio, do que escalar microservicos, mas desenvolver microservicos certamente é mais trabalhoso e potencialmente mais custoso. Lembrando que da pra fazer coisas bem ruins em qualquer umas das duas abordagens. Então é tambem preciso se atentar a qualidade desse desenvolvimento e nao somente na arquitetura.

O que acontece é que microserviços é muito mais uma decisão organizacional do que técnica.
Ele surgiu para dar independência aos times.
Para o time A que cuida de um contexto X do negócio não correr o risco de quebrar funcionalidades do contexto Y mantido pelo time B.
Mas isso por si só não justifica comprar toda a complexidade que vem com microserviços (que listo abaixo).
Se sua empresa tem 3 times, cada um com 3 devs, todos trabalhando num mesmo monolito, os times estão dependentes um do outro? Sim. Mas numa escala bem pequena e fácil de resolver conflitos, orquestrar mudanças e etc.
Adotar microserviços se torna necessário ter:

• Um altíssimo entendimento do negócio para saber separar os contextos em serviços, pois voltar atrás é praticamente inviável depois.
• Um centralizador de logs, do contrário vc tem que pular de um diretório para outro entre o serviços para analisar logs, dificultando a visão do todo.
• Uma ferramenta como Service Mesh para trackear a comunicação entre os serviços para apoiar o troubleshooting
• Um orquestrador ser Serviços
• Uma ferramenta de observability centralizada para os serviços se inscrevem e te darem uma visão centralizada da saúde dos serviços
• Um API gateway para os consumidores do serviço (frontend apps) terem um único ponto de acesso aos serviços
• Entre outras coisas que não me vieram a mente agora

Olha o tanto de infraestrutura e conhecimento que vai ser preciso agregar aos times para adotar microserviços.
Tem que valer muito a pena.

E um erro comum que eu vejo como justificativa para adotar microserviços:
Poder ter linguagens diferentes rodando na empresa.
Ainda que uma linguagem diferente da "main language" adotada pela empresa resolve um problema de forma consideravelmente melhor, basta criar este serviço específico desacoplado do monolito.

Vejo gente se orgulhar de dizer que tem microserviços todando em Java, Go, Node e etc.
Achando que demonstra flexibilidade da empresa.
Pra mim isso é bagunça. A menos que seja tecnicamente justificada a aplicação de diferentes linguagens para diferentes serviços.
E o fato de um grupo de devs ser mais proficiente em uma linguagem específica não justifica.
Eu nem acho que hoje em dia um desenvolvedor Senior deveria se intitular "Dev JS", "Dev Java" ou qualquer outra linguagem. Essa deveria ser apenas a "posição" atual ocupada. Mas essa é outra conversa.

Acho importante antes de fazer uma escolha ter em mente o workflow do seu projeto. Veja se em alguma parte seria mais vantajoso implementar um serviço de fila com apenas um container sem nem um HTTP fazendo os processos necessarios ou se ja existe algum serviço que faça alguma parte do seu projeto e se financeiramente seja agradavel implementar. Alguns projetos pode ser muito bom um monolito, mas alguns podem ser mais produtivos a partir de uma divisão em micro serviços! Na minha opnião tudo depende! Adorei o relato e a duvida ;)

Sendo MUITO honesto o hype de microserviço foi algo completamente desnecessário... Grande parte das aplicações não tem porte suficiente pra se tornar microserviço e isso é algo que só vai quebrando com algumas delas.

Grande parte da integração pode ser dificultada, as vezes malemá tem código pra dividir em mais de um serviço e as vezes o arquiteto só não sabe o que está fazendo mesmo e quer meter o loco pra ter uma experiência.

Monolito tem suas vantagens e Microserviço também, mas sendo MUITO do honesto, a maioria das empresas que passei as aplicações não se encaixavam em nem um nem outro, era só uma aplicação normal e queriam enfiar coisas desnecessárias... Eu sou muito a favor de organização de código seguindo princípios de SOLID e afins, mas nem sempre é necessário uma arquitetura complexa, só organizada.

Acho que a necessidade de escala de um serviço com microserviços é mt rara, acho que na sua grande maioria vejo que o pessoal divide com contexto de negócio mais para questão de organização (quando estamos falando de bastante devs) para ficar mais fácil fazer alguma mudança...
Vejo mais aplicação em questão de organizar os times e não ter 50 devs mexendo no mesmo projeto do que por escalabilidade...

O que eu sinto hoje no mercado é exatamente esse lance de hype. Virou moda utilizar microserviços pra tudo, sem nem pensar direito a primeira decisão já é, cria um microserviço. E não estou dizer que é bom ou ruim utilizar essa abordagem.

Meu ponto é, realmente é necessário?

É muito importante ter senso de momento, vejo muitas startups que estão no começo já indo pra essa abordagem, inflando o time, o custo com infra e acima de tudo a complexidade ciclomática.

Nas minhas 2 ultimas experiências profissionais eu lidei com os 2 cenários. Duas aplicações em teoria simples, na primeira um monólito, onde com um time relativamente pequeno conseguiamos entregar num pace muito rápido e era bem mais tranquilo de repor eventuais saidas.

No meu trabalho atual herdei um sistema construido com microserviços, e estamos tendo muitos problemas com o pace de entregas, pois o time é bem reduzido também e acabamos tendo um mesmo DEV atuando em varios serviços diferentes, com várias stacks diferentes. Sem contar o problema para repor funcionários.
E o principal problema que estamos tendo aqui, e que confesso estar bem dificil para resolver é o que eu chamo de "terceirizar a culpa", sempre que acontece algum problema, pessoa que atua em serviço X já sai atacando pessoa de serviço Y, esse é um problema de time e não da arquitetura em si, mas quis trazer para discussão pois é um problema que começa pela decisão de arquitetura, pois ao meu ver essa escolha foi tomada precocemente, com o time pequeno e pouco maduro.

A gente que trabalhar com tecnologia não pode ver uma casca de banana que logo já quer pisar em cima. Não é porque é possível tecnicamente dividir um problema em trilhões de partes escaláveis, você deve fazer o mesmo com seu projeto. A complexidade de infraestrutura vai te assombrar.
Os grandes fazem isso porque precisam de uma escala que provavelmente a maioria de nós jamais precisará, e porque têm equipes enormes.

Como muito foi falado aqui: Microsserviços são consequência de uma demanda exorbitante e estrutura organizacional. Nada mais que isso.

Ainda complemento também: Se o time não é capaz de desacoplar, padronizar e modularizar um sistema monolitico (muitas vezes legado com regras de negócio espalhadas de uma ponta a outra), como vão ficar os microsserviços desse time? Chega a dar medo, sem brincadeira.

Um monolito, com uma arquitetura limpa e gritante, domínios ricos, padrões de projeto bem aplicados e uma comunicação clara entre as pessoas que o desenvolvem cumpre o papel muito bem com no mínimo 50% a menos de complexidade, curva de aprendizado e carga cognitiva muito menores.

Fora que se seu monolito chegar nesse nível de ser bem desacoplado, padronizado e modularizado, é dois palitos para separar ele em microsserviços. Vai só depender se seu time vai ser dividido para ter responsabilidades diferentes ou se seu monolito já não aguenta mais a quantidade de usuarios que o sistema possui. Mas no caso da ultima situação ainda cabe uma indagação antes da migração de arquitetura: Não existe mais absolutamente nenhuma otimização que possa ser feita para que o monolito continue suportando a quantidade atual de usuarios e requisições?