Executando verificação de segurança...
-2

Monolito vs microserviços em 2026: a narrativa finalmente mudou

Por anos, microserviços foram vendidos como a arquitetura correta para qualquer sistema sério. Quem defendia monolito estava "fazendo errado" ou "não estava pronto para escalar".

Essa narrativa finalmente mudou. E vale entender por quê.

O que aconteceu

Empresas começaram a documentar publicamente os custos de microserviços que ninguém falava:

  • Overhead operacional: cada serviço é um deploy, um log, um ciclo de alerta separado
  • Complexidade de rede: latência, timeouts, retries, circuit breakers: tudo que era uma chamada de função virou uma chamada HTTP com todos os seus problemas
  • Times pequenos afogados em infra: engenheiro de produto gastando 40% do tempo com Kubernetes

DHH (Basecamp), Shopify, Stack Overflow e outros publicaram post-mortems de volta para monolito. Isso normalizou a conversa.

O que a maioria ignorou

Microserviços resolvem problemas de escala organizacional, não de escala técnica. Se você tem 5 times que precisam deployar de forma independente, microserviços fazem sentido. Se você tem 3 devs, você está pagando o custo de coordenação sem ter o benefício.

Monolito bem estruturado escala muito mais do que a maioria dos produtos vai precisar alguma vez.

A decisão certa

Comece com monolito. Quebre quando tiver razão específica, não quando "parecer hora".

O que motivou vocês a ir para microserviços? Foi necessidade real ou seguir tendência?

Carregando publicação patrocinada...
6

Microserviços resolvem problemas de escala organizacional, não de escala técnica.

Esse é justamente o problema do microserviço, não a solução.

Adotar microserviço para resolver organização reflete uma gestão e liderança incapacitada.

Empresas começaram a documentar publicamente os custos de microserviços que ninguém falava

Ninguém falava? Em qual bolha você está?

Todos falavam que microserviços era hype, conversa de vendedor de curso. Desde o boom não teve um ano que eu passei sem ler uma crítica muito bem fundamentada.

No Brasil lembro do Akita falando algo parecido entre 2016 e 2018, pré pandemia, quando desenvolvimento estava praticamente no seu auge.

Lembro de eu estar estudando nessa época pré pandemia sobre SOA e modular monolith. Arquiteturas que levo até hoje

Sim, sou totalmente contra microserviços. O que uso é Monolitos com serviços específicos. Esses serviços devem conter um motivo para estar separados (processamento de imagens ou arquivos grandes, impressão de PDF, gestão de conexões websocket) mas quem manda é o monolito.

E tenho apenas uma certeza: SEMPRE que alguem falava em microserviços do meu lado se encaixava em uma dessas categorias:

  1. Não entendia a tecnologia que estava usando, só "escrevia código"
  2. Nunca gastou seu próprio dinheiro
2

A Lei de Conway é descritiva, não prescritiva. O ponto não é que gestão ruim justifica microserviços, mas que em times muito grandes, com contextos de negócio genuinamente separados, a arquitetura distribuída reflete uma realidade organizacional que já existe. Concordo que adotar microserviços para consertar comunicação disfuncional é gastar dinheiro no lugar errado. O argumento do post é sobre o hype de que monolito era sinal de amadorismo, que existia e prejudicou muita decisão técnica. Sobre o Akita e outros: você está certo que quem acompanhava a discussão séria já sabia disso. O problema é que decisão de arquitetura raramente fica com quem acompanha a discussão séria. Você trabalha com modular monolith hoje ou foi direto para algo distribuído quando o contexto pediu?

5

Por anos, microserviços foram vendidos como a arquitetura correta para qualquer sistema sério. Quem defendia monolito estava "fazendo errado" ou "não estava pronto para escalar". Mas pode me mostrar fontes muito fortes que digam o contrário.

Não me lembro disso. Tinha "uma meia dúzia" que falava isso, mas nunca foi a narrativa vigente. Sempre tem uns malucos ou pessoas tentando ganhar dinheiro com mentiras.

Há uns 10 anos que eu vejo muita crítica aos microsserviços e que adotá-lo é quase certo que está fazendo errado, porque a escala de exceção pode ser obtida com formas mais simples e a escala de desenvolvimento só faz sentido em mega projetos em lugares que já tem a cultura de segmentação. Note que alguns dos sites de maior tráfego e bases de código gigantescas fazem como um monólito.

As pessoas falavam dos custos de microsserviços, algumas pessoas ignoravam, alguma até porque trabalha com a metodologia orientada a currículo, ou seja, ela gasta o dinheiro de seus patrões ou clientes para ter um currículo que a pessoa sabe fazer algo "avançado" mesmo que tenha sido feito tudo errado e custado muito mais caro sem trazer nada útil. Todas as pessoas sérias que eu conheço defendiam o uso de monólitos e só se um idiota qualquer dissesse que tinha que usar a forma mais cara, complexa e difícil de fazer, que microsserviços era adotado. È verdade que tendo a não conhecer as pessoas menos sérias.

Tem muita gente adotando microsserviços por modinha, em geral com resultados trágicos, não mensurados e alguns têm a coragem de admitir que erraram e voltam atrás. Nunca encontrei uma pessoa que provasse que precisava de microsserviços. Conheço muita gente, mas não todo mundo.

Stack Overflow nunca adotou microsserviços.

Microserviços resolvem problemas de escala organizacional, não de escala técnica

Iso é algo que muitas pessoas não percebiam e não falavam. Eu mesmo percebi isso depois de um tempo. No começo eu batia muito na tecla que dava pra escalar bem sem microsserviços. Depois mudei deixando claro que a técnica só fazia algum sentido pela Lei de Conway, o que já era a dica que pouquíssimas corporações se beneficiariam deste aspecto. Mas continuou tendo adoções em ambientes que não fazia sentido, ainda que algumas das pessoas mais respeitadas da nossa área falavam claramente que microsserviços não deveria ser a solução padrão.

Vai continuar muita gente falando "no nosso caso precisava mesmo", ouvi várias vezes quando palestrei sobre o assunto, e ninguém provou que era necessário. E tem um detalhe, quase sempre onde é necessário, só será possível saber qual é melhor implementando ambos, por isso quase todas as adoções são baseadas em suposições, ainda que algumas até tenham alguma sustentação superficial.

Fazer o deploy de forma independente é algo que pode ser feito com monólitos. Ainda tem muita gente que confunde solução monolítica com executável monolítico. Claro que cada tem suas vantagens e desvantagens, e quase sempre as vantagens dos monólitos compensam as desvantagens, com microsserviços isso não costuma acontecer.

Ainda tem muitas pessoas que acham que microsserviços deve ser adotado com um pequeno punhado de pessoas, mas não com meia dúzia. Mas a realidade é quase sempre só vale a pena, e muitos casos assim não valem, quando você tem centenas ou mesmo milhares de desenvolvedores. E tem vários projetos com milhares de pessoas trabalhando em monólito e está tudo bem, ninguém sequer cogita mudar, e claro, esses projetos costumam ter apenas bons programadores. Microsserviços muitas vezes é adotado para lidar melhor com a mediocridade que é ampla.

Monolito bem estruturado escala muito mais do que a maioria dos produtos vai precisar alguma vez.

Sim. O Stack Overflow é um exemplo que eu sempre cito, mas podemos falar da Wikipedia, Instagram, Shopify...

Comece com monolito. Quebre quando tiver razão específica

Esta frase é extremamente repetida há anos. E algumas pessoas, como eu, falam para só adotar algo tão complexo e caro se puder provar que é melhor assim. Desta forma quase ninguém vai adotar isso.

Infelizmente se alguém disser que adotou microsserviços por algum motivo, não conseguirá provar isso.

S2


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

1

Você tem razão na revisão histórica: quem acompanhava a discussão técnica séria sempre soube que microserviços não era bala de prata. O post exagerou na força da narrativa dominante. O que eu estava descrevendo é o que chegava nas decisões de arquitetura de times médios, onde o sênior que lia Fowler e o Akita não era quem batia martelo. O ponto da metodologia orientada a currículo é provavelmente o diagnóstico mais honesto de por que a adoção acontecia mesmo com a crítica existindo. Sobre Stack Overflow: o post deles sobre monolito é um dos mais citados exatamente porque contraria o que o mercado praticava, o que sugere que a prática estava desalinhada da teoria mesmo que a teoria correta existisse. Você citou SOA antes de falar de microsserviços. Ainda usa SOA como referência ou migrou para modular monolith como padrão principal?