Dois bandos, um WhatsApp e nenhum vencedor claro
Não é preciso inventar uma anedota: qualquer um que dirija uma equipe de engenharia em 2026 já viveu essa cena. Um grupo jura que quebrar o monolito foi a melhor decisão de sua carreira. O outro grupo, no mesmo chat, manda capturas de tela de contas de Kubernetes que não baixam de cinco cifras ao mês. Nenhum deles mente. Esse é justamente o problema: a arquitetura de software deixou de ser uma discussão técnica e se tornou uma discussão de identidade tribal, com dados reais de ambos os lados sustentando posturas opostas.
Antes de me juntar a um bando, decidi fazer o que não havia feito em um ano e meio de estar nesse debate no Slack: perseguir cada cifra até sua origem. O que encontrei não é um vencedor. É um mapa de quem está fazendo o quê, por quê, e — isso é o interessante — quanto distinto é o discurso público do comportamento real por trás das portas.
O dado que todos citam e que ninguém pode apontar com o dedo
Começo pela descoberta mais incômoda desta investigação, porque é a que melhor explica como se fabrica o consenso na indústria do software.
Busquei a cifra "42% de organizações que adotaram microserviços estão consolidando serviços de volta a unidades maiores" em dezenas de artigos de 2025 e 2026. Todos a atribuem a "uma pesquisa da CNCF de 2025". Um desses artigos — que, além disso, cita o dado — confessa em suas próprias notas de produção que foi redigido por um pipeline automatizado com IA "verificado contra o relatório CNCF x SlashData 2026" (ManoIT / DEV Community, 2026). Fui direto ao cncf.io, revisei o relatório da pesquisa anual de 2024 (CNCF, 2025), o anúncio de novembro de 2025 sobre o estudo com SlashData (CNCF, 2025) e o relatório de pesquisas mais recente publicado pela fundação, e em nenhum dos documentos que pude abrir aparece esse 42% com esse enunciado exato. O que sí aparece, consistentemente, é que 46% de desenvolvedores backend trabalham com microserviços e que o uso de contêineres e Kubernetes segue crescendo (CNCF/SlashData, 2025) — esse dado específico sí o confirmei de forma direta contra o comunicado original da fundação.
Significa que o 42% é falso? Não necessariamente — é exatamente o tipo de cifra que uma fundação relata em um webinar ou um painel lateral que nem sempre é indexado da mesma forma que o PDF principal, e aparece citada de forma quase idêntica em pelo menos oito fontes independentes com nível de detalhe consistente (queda de adoção de service mesh de 18% para 8% incluída) (SoftwareSeni, 2026; ThirdEyeData, 2026; ByteIota, 2026). Mas para um artigo que se orgulha de verificar cada dado, a honestidade obriga a dizer isso: o 42% é a cifra mais citada de todo o debate arquitetônico de 2026, e não consegui confirmá-la contra um documento primário legível. Trate-a como "amplamente repetida, não verificada de forma independente", e não como fato consumado. É um exemplo perfeito de como o "consenso" em tecnologia às vezes é simplesmente conteúdo gerado por IA citando a si mesmo em círculo.
O que é sólido, com fonte primária confirmada — e que no rascunho original deste artigo faltava na bibliografia, então fui procurar o post real — é a migração do Amazon Prime Video. Sua equipe de engenharia documentou em seu próprio blog como consolidou um serviço de monitoramento de qualidade de vídeo de uma arquitetura distribuída para um monolito, com uma redução de custos de infraestrutura de 90% (Amazon Prime Video Engineering, 2023).
O caso mais citado contra os microserviços
Redução de custos de infraestrutura do Amazon Prime Video após consolidar seu serviço de monitoramento de vídeo em um monolito.
90%
Redução de custos de infraestrutura (2023)
Ver los datos
| Indicador | Valor |
|---|---|
| Redução de custos de infraestrutura (2023) | 90% |
Esse caso — já com três anos — ainda é a citação obrigatória de todos que argumentam contra os microserviços, e com razão: vem da mesma empresa que ensinou microserviços ao mundo.
Shopify: a prova de que "monolito" não é sinônimo de "pequeno".
Se o argumento a favor do microserviço sempre foi "você não vai escalar sem eles", o Shopify o desmente com números concretos e verificáveis em seu próprio blog de engenharia. A plataforma opera o que eles mesmos chamam de "monolito majestoso": uma única aplicação Ruby on Rails, organizada internamente em componentes com fronteiras estritas impostas por uma ferramenta que desenvolveram para esse fim, Packwerk (Shopify Engineering, s.f.). Durante os picos de tráfego do Black Friday, a infraestrutura suporta dezenas de terabytes de dados por minuto, com a camada de bancos de dados particionada por loja (shop_id) em vez de fragmentar o código de aplicação em serviços independentes (Kovyrin, en TechWorld with Milan, 2025).
A distinção importa: o Shopify não evitou a modularidade, evitou a <em>distribuição</em>. Seus componentes estão separados por fronteiras de código (bounded contexts, no linguajar de Domain-Driven Design), mas executam no mesmo processo, sem chamadas de rede entre eles. Essa é exatamente a definição de "monolito modular" que quase toda a literatura de 2025-2026 identifica como a terceira via real, não binária, entre monolito clássico e microserviços (Al-Qora'n & Al-Said Ahmad, 2025) — o primeiro <em>systematic literature review</em> acadêmico sobre o tema, publicado na revista <em>Future Internet</em>, encontrou apenas 15 estudos primários revisados por pares entre 2020 e maio de 2025, o que diz algo importante: a prática da indústria vai anos à frente da pesquisa formal que a sustenta.
Radar 1 — O que fazem (de verdade) as grandes casas de software.
Radar 1 — O que as grandes empresas de software realmente fazem
Pontuações editoriais de 0 a 10 atribuídas com base nas afirmações citadas no corpo do texto para cada empresa, não uma pesquisa formal. Cada eixo está orientado para que um valor mais alto sempre seja "melhor" nesse eixo.
- SAP (ERP herdado em transição)
- Shopify (monolito modular nativo)
- Oracle (SOA híbrida)
- Anthropic / OpenAI (IA nativa)
Ver los datos
| Eje | SAP (ERP herdado em transição) | Shopify (monolito modular nativo) | Oracle (SOA híbrida) | Anthropic / OpenAI (IA nativa) |
|---|---|---|---|---|
| Independência do legado | 2 | 8 | 4 | 9 |
| Velocidade de implantação | 3 | 7 | 4 | 9 |
| Simplicidade operacional | 4 | 7 | 3 | 8 |
| Integração nativa de IA/agentes | 3 | 5 | 3 | 10 |
| Eficiência de custo por recurso | 3 | 8 | 4 | 7 |
| Maturidade de governança de fronteiras | 6 | 9 | 5 | 8 |
Com isso na mesa, vamos olhar para as seis empresas que originaram essa pergunta — SAP, Oracle, Microsoft, Apple, Anthropic e OpenAI — e uma dúzia mais que aparecem citadas de forma recorrente na literatura técnica de 2025-2026.
A <strong>SAP</strong> é talvez o caso mais honesto do lote: sua própria comunidade técnica descreve o núcleo do S/4HANA como "um monolito modular massivo" que atravessa uma descomposição gradual em direção a arquiteturas nativas de nuvem, sem data de finalização prometida (SAP Community, 2025). Não é marketing de transformação digital: é uma empresa de 50 anos admitindo que quebrar um monolito de ERP leva mais de uma década.
A <strong>Oracle</strong> executa em paralelo dois discursos. As Fusion Applications nasceram em 2011 sobre uma arquitetura orientada a serviços (SOA) clássica (Oracle, Wikipedia, s.f.), e desde então o "Projeto Spectra" move funcionalidade em direção a microserviços em contêineres sobre Kubernetes gerenciado (OKE), usando o framework Helidon (Oracle Cloud Blog, 2023) — mas o próprio blog da Oracle descreve o processo como algo que ocorre "atrás de bastidores", sem que o cliente o perceba, precisamente porque uma reescrita total é inviável para software que executa folhas de pagamento e balanços contábeis de milhares de empresas.
A <strong>Microsoft</strong> não tem um comunicado único sobre o tema, mas seu comportamento pode ser lido na literatura técnica de terceiros: o padrão dominante em 2025-2026 para .NET empresarial é exatamente o mesmo que no resto da indústria — começar com monolito modular, extrair microserviços apenas com evidência real de necessidade — (Murmu Software, 2026), e sua própria prática interna de IA (o "orquestador com subagentes isolados" que descrevo mais abaixo) confirma a mesma filosofia.
A <strong>Apple</strong> não publica arquitetura de backend, mas dentro de seu próprio ecossistema de desenvolvedores, o padrão dominante para aplicativos iOS grandes é o "monolito modular" via Swift Package Manager, e não microserviços: separar em frameworks internos sem fragmentar o processo de compilação e implantação (Tariq, 2025). É o mesmo padrão que a Shopify usa no backend, aplicado ao cliente.
A <strong>Anthropic e OpenAI</strong> são o caso mais interessante deste radar, porque não competem em ERP ou e-commerce: competem em como os agentes de IA são orquestrados, e aí sua arquitetura <em>é</em> o produto. A Anthropic documenta em seu próprio blog de engenharia que seus agentes são executados como um loop único com ferramentas e subagentes limitados sob um orquestrador central, e não como uma malha de microserviços peer-to-peer (Anthropic Engineering). A OpenAI abandonou seu framework experimental Swarm (2024) pelo SDK de Agentes (2025), mas manteve o mesmo princípio de design minimalista: um agente que decide quando transferir o controle para outro, sem coordenador central complexo ou comunicação em malha (OpenAI Swarm repo; Tao An, 2026). Voltarei a isso na seção de IA porque é, para mim, a descoberta mais reveladora de toda a investigação.
Para este radar, escolhi seis eixos que a própria investigação identificou como os mais reveladores: <strong>independência arquitetônica do legado</strong>, <strong>velocidade de implantação</strong>, <strong>complexidade operativa assumida</strong>, <strong>integração nativa de IA/agentes</strong>, <strong>custo de manutenção por recurso</strong> e <strong>maturidade de governança de fronteiras</strong> (quão sério se leva a Lei de Conway). Comparei quatro perfis representativos — SAP (ERP herdado em transição), Shopify (monolito modular nativo), Oracle (SOA híbrida) e Anthropic/OpenAI (IA nativa, orquestrador + subagentes) — porque tentar graficar 24 empresas em um único radar teria sido ilegível; o resto do panorama corporativo — Microsoft, Apple, Amazon, Google, Meta, Netflix, IBM, Salesforce, Stripe e outros que aparecem na literatura de 2025-2026 — é discutido no corpo do texto e na metodologia, e não nos eixos do gráfico.
Radar 2 — O outro lado: quem mantém o open source
Radar 2 — O outro lado: quem mantém o open source
Pontuações editoriais de 0 a 10 derivadas das afirmações citadas sobre cada projeto, não uma pesquisa formal.
- Linux (kernel)
- PostgreSQL
- Kubernetes
- Proxmox
Ver los datos
| Eje | Linux (kernel) | PostgreSQL | Kubernetes | Proxmox |
|---|---|---|---|---|
| Filosofia monolítica declarada | 10 | 8 | 1 | 9 |
| Equipe de manutenção reduzida | 3 | 5 | 1 | 9 |
| Modularidade interna sem rede | 8 | 7 | 2 | 7 |
| Escala de adoção | 10 | 8 | 9 | 5 |
| Independência de uma fundação | 6 | 7 | 2 | 9 |
Aqui, a pergunta do usuário que originou esta peça era exata: o que fazem os que mantêm a Linux Foundation, MySQL, MariaDB, PostgreSQL, Proxmox e outros 30 projetos de alto impacto? A resposta curta: o mundo do open source leva <em>décadas</em> tendo esta discussão, muito antes de "microserviços" se tornar uma palavra de moda corporativa.
O caso fundacional é o <strong>núcleo do Linux</strong>. Em 1992, Andrew Tanenbaum escreveu publicamente a Linus Torvalds que escrever um núcleo monolítico naquela data era "um passo gigante de volta aos anos 70" e que os microkernels já haviam ganhado o debate acadêmico (Tanenbaum-Torvalds debate, Wikipedia, 1992). Torvalds respondeu, com o tom que o caracteriza, que os microkernels "empurram o problema para o espaço de comunicação, que é um problema maior do que o que dizem resolver" (Torvalds, sobre el debate micro vs. monolítico). Trinta e quatro anos depois, o Linux — monolítico — roda na imensa maioria dos servidores do planeta, e o GNU Hurd — microkernel — ainda é um projeto acadêmico. A ironia é evidente: a infraestrutura que torna possível executar microserviços (contêineres, Kubernetes, a nuvem inteira) é construída sobre um núcleo que ganhou sua própria guerra sendo monolítico.
O <strong>PostgreSQL, MySQL e MariaDB</strong> vivem a mesma lógica na camada de dados: são processos monolíticos (ou quase) por design, e a própria comunidade discute ativamente se "descompor" um banco de dados em microserviços de dados faz sentido ou é simplesmente reintroduzir a complexidade de rede onde antes havia uma chamada de função (Reintech, 2026). A resposta dominante em 2025-2026: manter o banco de dados monolítico e colocar microserviços de aplicação ao redor, e não dentro.
<strong>Proxmox</strong> é o exemplo mais nítido do "outro estilo" de open source: uma empresa austríaca pequena, sem apoio de uma fundação como a CNCF nem governo multi-vendor, que mantém uma plataforma tudo-em-um (hipervisor + contêineres LXC + armazenamento + rede) deliberadamente simples frente à alternativa nativa de Kubernetes, KubeVirt (Kubermatic, 2026). É, em software de infraestrutura, o mesmo padrão que André Staltz descreveu há anos como a "escola monolítica" do open source: projetos como WordPress, Django ou o próprio Linux que resolvem um problema grande como um bloco coeso, contra a "escola modular" que publica uma utilidade por pacote (Staltz, 2018). Onze anos depois, ainda é o quadro mental mais útil que encontrei para explicar por que Gogs (um único binário, um único mantenedor) e Kubernetes (centenas de peças coordenadas) representam filosofias opostas do mesmo movimento open source (Laoutaris, 2025).
Para este radar, usei cinco eixos: <strong>filosofia monolítica declarada</strong>, <strong>tamanho da equipe mantenedora</strong>, <strong>modularidade interna sem rede</strong>, <strong>escala de adoção</strong> e <strong>dependência de governança de fundação</strong>. Comparei Linux (kernel), PostgreSQL, Kubernetes e Proxmox — os quatro pontos de referência mais citados na literatura técnica que revisei, dentro do panorama mais amplo de 20+ projetos (inclui MySQL, MariaDB, Caddy, SigNoz, Gogs, Nginx, Envoy, Terraform, Ansible, Jenkins, Prometheus, Grafana, Elasticsearch, Redis, Kafka, Django, WordPress, GitLab, Nextcloud e Home Assistant, entre outros) que se documentam na metodologia.
Radar 3 — Os governos: quatro filosofias, um mesmo problema de escala
Radar 3 — Os governos: quatro filosofias, um mesmo problema de escala
Pontuações editoriais de 0 a 10 derivadas das afirmações citadas sobre cada bloco de governo, não uma pesquisa formal.
- Estados Unidos
- União Europeia
- China
- Índia
Ver los datos
| Eje | Estados Unidos | União Europeia | China | Índia |
|---|---|---|---|---|
| Maturidade de infraestrutura em nuvem | 5 | 7 | 8 | 7 |
| Modularidade/interoperabilidade declarada | 3 | 10 | 4 | 8 |
| Escala de transações comprovada | 6 | 5 | 7 | 10 |
| Soberania sobre provedores privados | 4 | 8 | 10 | 6 |
| Maturidade de sistemas internos | 3 | 6 | 7 | 8 |
Aqui é onde a pergunta original se torna mais interessante, porque os governos não competem por velocidade de mercado: competem por soberania, interoperabilidade e não colapsar sob sua própria escala.
<strong>Estados Unidos</strong> vivem o pior dos dois mundos: de acordo com cifras da Oficina de Prestação de Contas do Governo (GAO), o governo federal gasta mais de $100 bilhões de dólares anuais em tecnologia, e aproximadamente 80% desse montante se destina a manter sistemas herdados funcionando, não a construir nada novo (GAO, 2025). É a versão estatal, em escala descomunal, do mesmo problema que qualquer CTO enfrenta com seu monolito de dez anos: a dívida técnica se paga em orçamento, não em elegância arquitetônica.
<strong>A União Europeia</strong> tomou a postura contrária de forma explícita e documentada: GovStack — a iniciativa fundada pela ITU, Estônia, Alemanha e DIAL, com financiamento do Global Gateway da UE — tem uma sessão de treinamento oficial literalmente intitulada <em>"Evitando o Monolito: Integrando Microserviços para uma Transformação Digital sem Atrito"</em> (ITU Academy / GovStack, 2025). Sua especificação técnica define "building blocks" (identidade digital, intercâmbio de dados, orquestração de fluxos) como módulos interoperáveis que podem estar compostos de microserviços de domínio (GovStack Specification, s.f.). É, no vocabulário deste mesmo artigo, uma aposta institucional explícita pelo lado microserviços do debate, com o argumento de soberania digital europeia (EuroStack) empurrando na mesma direção (Bertelsmann Stiftung, 2026).
<strong>Índia</strong> construiu, sem usar nunca a palavra "microserviços" em seu discurso público, o exemplo de arquitetura por camadas mais grande do planeta: India Stack. Aadhaar (identidade biométrica, 1,4 bilhão de pessoas inscritas), UPI (pagamentos instantâneos, 22,35 bilhões de transações em um único mês de abril de 2026 — mais do que o Visa processa globalmente em um dia —) e DigiLocker operam como camadas independentes conectadas por APIs abertas, não como um sistema monolítico único de governo (Policy Circle, 2026; corroborado de forma independente por um comunicado del gobierno de India). Pesquisa acadêmica sobre infraestrutura pública digital confirma que essas arquiteturas usam explicitamente microserviços com APIs padronizadas como padrão técnico dominante (arXiv 2503.08725, 2025). É o caso de maior escala provado do planeta para o lado "microserviços" do debate — com o matiz de que a Corte Suprema da Índia, em 2018, limitou o uso privado de Aadhaar por razões de privacidade, o que mostra que a arquitetura modular também foi, em parte, uma resposta a um problema legal, não apenas técnico.
<strong>China</strong> aposta em uma infraestrutura de "nuvem governamental" (政务云) centralizada com cobertura de 100% em administrações de nível de condado ou superior, dentro da estratégia de "China Digital" (National Data Administration / Digital China Wins the Future, 2026). Diferentemente do modelo europeu de blocos de construção interoperáveis entre países soberanos, aqui a centralização é explicitamente o objetivo estratégico — o mercado de governo digital chinês se projeta em mais de 200 bilhões de yuanes para 2026, com 73% destinado à infraestrutura de nuvem governamental (IDC, vía Huawei Cloud, 2026). É, arquitetonicamente, o polo oposto ao modelo europeu, embora compartilhe com ele o uso de microsserviços como padrão de implementação técnica interna.
Quanto do orçamento tecnológico é gasto para manter o que já existe
Percentagem do gasto tecnológico dedicado a manter sistemas/infraestrutura existente em vez de construir algo novo.
Ver los datos
| Concepto | Valor (%) |
|---|---|
| Estados Unidos — % de $100.000M+ anuais em manter sistemas herdados | 80% |
| China — % de ~200.000M de yuanes projetados em infraestrutura de nuvem governamental | 73% |
Quatro governos, quatro posturas arquiteturais
Resumo da postura e da métrica-chave citada para cada bloco de governo.
| Governo | Postura arquitetural | Métrica-chave citada |
|---|---|---|
| Estados Unidos | Fragmentada / herdada | ~80% de $100.000M+ anuais em manter sistemas herdados |
| União Europeia | Microserviços / blocos de construção explícitos | GovStack + EuroStack, soberania digital |
| Índia | Arquitetura em camadas (India Stack) | 22.350M transações UPI em abril de 2026 |
| China | Nuvem governamental centralizada | 100% de cobertura em condados+, ~200.000M yuanes projetados |
Ver los datos
| Governo | Postura arquitetural | Métrica-chave citada |
|---|---|---|
| Estados Unidos | Fragmentada / herdada | ~80% de $100.000M+ anuais em manter sistemas herdados |
| União Europeia | Microserviços / blocos de construção explícitos | GovStack + EuroStack, soberania digital |
| Índia | Arquitetura em camadas (India Stack) | 22.350M transações UPI em abril de 2026 |
| China | Nuvem governamental centralizada | 100% de cobertura em condados+, ~200.000M yuanes projetados |
Japão e Coreia do Sul não têm, na literatura que revisei, uma postura arquitetônica tão documentada ou distintiva como esses quatro blocos — ambos seguem, em geral, o padrão de modernização gradual para a nuvem que domina o resto das economias desenvolvidas da OCDE, sem um manifesto próprio equivalente ao de GovStack ou India Stack.
Os cinco eixos deste radar: <strong>madurez da infraestrutura na nuvem</strong>, <strong>modularidade/interoperabilidade declarada</strong>, <strong>escala de transações comprovada</strong>, <strong>soberania e controle estatal sobre fornecedores privados</strong>, e <strong>complexidade e madurez dos sistemas internos</strong> (o eixo que especificamente pedi priorizar). Comparei Estados Unidos, União Europeia, China e Índia com peso igual, tal como definimos no escopo.
O que dizem as universidades (e o que ainda não sabem)
Busquei pesquisa acadêmica recente em universidades dos Estados Unidos, da União Europeia, China, Índia, Japão e Coreia, e a descoberta mais honesta é esta: a academia vai atrás da indústria, não à frente. O primeiro <em>systematic literature review</em> formal sobre monolitos modulares na nuvem — publicado em outubro de 2025 na revista <em>Future Internet</em> — encontrou apenas 15 estudos primários revisados por pares entre 2020 e maio de 2025, e sua conclusão principal é que nem mesmo existe consenso sobre uma definição clara do termo (Al-Qora'n & Al-Said Ahmad, 2025). Um segundo estudo de 2026, com revisão de literatura multivocal de 67 fontes entre 2022 e 2026, chega a uma conclusão similar sobre a falta de bases empíricas sólidas para decisões que a indústria já toma por milhões de dólares (ResearchGate, 2026).
A revista <em>Tsinghua Science and Technology</em> publicou em 2026 pesquisa sobre arquiteturas de microsserviços para automação industrial com requisitos de tempo real (Martínez et al., 2026) — um ângulo técnico específico (indústria 4.0), não uma postura institucional chinesa sobre o debate geral. Na literatura de instituições indianas, europeias e estadunidenses, o padrão se repete: dezenas de papers sobre <em>como</em> migrar de monolito para microsserviços (identificação automática de fronteiras com IA, grafos de dependência, aprendizado automático), mas muito pouca pesquisa que responda <em>quando</em> convém fazer isso, e quase nenhuma comparação rigorosa e reprodutível de custos reais em escala empresarial. Um paper de 2025 no arXiv diretamente intitulado <em>"Microservices Are Dying"</em> propõe abandonar a unidade de "microsserviço" em favor de interfaces universais de módulo — um sinal de que mesmo dentro da comunidade técnica mais entusiasta com a distribuição, o vocabulário mesmo começa a se sentir insuficiente (arXiv 2511.04548, 2025).
O giro que ninguém viu chegar: a IA que orquestra IA escolheu o monolito modular
Este é, para mim, o achado mais interessante de toda a pesquisa, e responde diretamente à pergunta que me fiz ao começar: a IA generativa empurra para mais distribuição ou para mais consolidação?
Em 2025, a indústria de agentes de IA teve seu próprio debate binário: arquiteturas de malha (múltiplos agentes conversando entre si sem coordenador central) contra um único agente com ferramentas. Cognition — a empresa por trás de Devin — publicou em junho de 2025 uma postura forte: "Não construam sistemas multi-agente" (Cognition, 2025, vía FlowHunt, 2026). Para 2026, esse debate polarizado colapsou em um padrão único que Anthropic, OpenAI e a própria Cognition adotaram de forma independente: um agente orquestrador que possui o contexto completo e despacha subagentes efêmeros para tarefas isoladas, cada um com sua própria janela de contexto fresca, sem canal ponto a ponto entre eles e sem estado mutável compartilhado (FlowHunt, 2026).
Leia novamente: **sem um canal ponto a ponto entre eles**. Isso não é uma arquitetura de microsserviços em malha — é, quase ao pé da letra, a definição de um monolito modular: um processo central com autoridade total, módulos que são invocados sob demanda, fronteiras claras, e comunicação que nunca sai do controle do orquestrador. A própria Anthropic documenta que seus agentes de código são executados exatamente assim: um loop de agente único com um catálogo amplo de ferramentas, não uma malha de serviços independentes (Anthropic Engineering). OpenAI percorreu o mesmo caminho desde o Swarm (descontinuado) até seu SDK atual de *handoffs* explícitos, sem coordenador de malha.
Em dezembro de 2025, o protocolo Agent2Agent (A2A) se juntou ao MCP sob uma nova fundação do Linux Foundation dedicada à IA e agentes (AAIF) (Linux Foundation, dic. 2025) — a infraestrutura de coordenação está sendo padronizada, mas o padrão que está sendo padronizado é hierárquico, não de malha plana. Se a pergunta é "a IA empurra para o monolito ou para microsserviços?", a resposta que o comportamento real daqueles que constroem a IA — não seu discurso de marketing — é: para uma forma de monolito modular com subagentes descartáveis, não para uma malha distribuída de microsserviços autônomos.
Como chegamos ao monolito modular com subagentes
Cronologia dos marcos citados nesta pesquisa sobre arquitetura de agentes de IA.
- 1992Tanenbaum diz a Torvalds que um kernel monolítico é um passo atrás — Torvalds responde que os microkernels apenas movem o problema para a comunicação.
- 2023Amazon Prime Video consolida seu serviço de monitoramento em um monolito e reduz custos de infraestrutura 90%.
- 2025Cognition (Devin) publica "Não construam sistemas multi-agente".
- 2025A AAIF é fundada sob a Linux Foundation, com MCP e Agent2Agent como projetos âncora.
- 2026CNCF e SlashData relatam 46% de desenvolvedores backend usando microserviços, em meio ao debate de consolidação.
Ver los datos
| Año | Hecho |
|---|---|
| 1992 | Tanenbaum diz a Torvalds que um kernel monolítico é um passo atrás — Torvalds responde que os microkernels apenas movem o problema para a comunicação. |
| 2023 | Amazon Prime Video consolida seu serviço de monitoramento em um monolito e reduz custos de infraestrutura 90%. |
| 2025 | Cognition (Devin) publica "Não construam sistemas multi-agente". |
| 2025 | A AAIF é fundada sob a Linux Foundation, com MCP e Agent2Agent como projetos âncora. |
| 2026 | CNCF e SlashData relatam 46% de desenvolvedores backend usando microserviços, em meio ao debate de consolidação. |
Se você vai iniciar um projeto em 2026, é isso que eu faria
Não há uma resposta universal, mas há um padrão consistente em cada fonte séria que revisei, desde o caso do Amazon Prime Video até a *systematic literature review* acadêmica:
1. **Comece com monolito modular, não com monolito plano nem com microsserviços**. Defina fronteiras de domínio claras (Domain-Driven Design) desde o primeiro commit, mesmo que tudo execute em um único processo. Extrair um módulo bem delimitado para um serviço independente depois é barato; desfazer uma malha de microsserviços mal delimitada é caríssimo.
2. **Extraia um serviço apenas quando tiver evidência real**, não intuição: necessidade de escalonamento verdadeiramente independente, requisitos regulatórios de isolamento físico (como PCI em pagamentos), ou um stack tecnológico genuinamente incompatível (Python para ML, Go para o core).
3. **O tamanho da equipe importa mais do que o tamanho do produto**. O limiar que se repete na literatura de 2025-2026 — equipes de 50 ou mais engenheiros com fronteiras organizacionais claras — é o ponto onde os microsserviços começam a justificar seu custo de coordenação (Lei de Conway aplicada em sentido inverso).
4. **Se você vai integrar agentes de IA em sua arquitetura**, o padrão que Anthropic e OpenAI validaram em produção — orquestrador central com subagentes efêmeros e isolados — é hoje a opção com mais evidência real por trás, não a malha de agentes peer-to-peer que se discutia em 2024.
O semáforo final desta pesquisa
Distribuição de confiança das 39 citações pontuais do corpo do texto.
- Verde — primária ou corroborada — 56%
- Amarelo — uma única fonte secundária — 41%
- Vermelho — não verificável, visível por transparência — 3%
Ver los datos
| Segmento | Valor |
|---|---|
| Verde — primária ou corroborada | 22 |
| Amarelo — uma única fonte secundária | 16 |
| Vermelho — não verificável, visível por transparência | 1 |
A resposta muda se a decisão não for mais tomada por um humano?
Aqui está minha pergunta real, a que me levou a esta investigação completa: dentro de dois ou três anos, quando um agente de IA propor a arquitetura inicial do seu próximo projeto — e já está fazendo isso, com ferramentas que sugerem estruturas de pastas e fronteiras de módulo — seguirá recomendando "comece simples, distribua apenas com evidência"? Ou a facilidade com que a IA gera e mantém código distribuído (mais serviços, mais YAML, mais configuração) vai inclinar a balança de volta para a complexidade, simplesmente porque já não é um humano cansado quem tem que mantê-la?
Vocês viram: seus copilotos de código os empurram para mais simplicidade ou para mais peças móveis?
Esteban Rey
X: @Kilowatto
LinkedIn: https://www.linkedin.com/in/kilowatto
Wikidata: https://www.wikidata.org/wiki/Q140672978
Metodología de esta investigación
Esta investigação foi desenvolvida sob a variante **"investigação profunda + contraparte/réplica"**: existe uma postura dominante (microsserviços como destino inevitável da arquitetura moderna, consolidada entre 2015 e 2022) que em 2024-2026 enfrenta uma réplica documentada com casos reais (Amazon Prime Video, Shopify, a consolidação reportada pela CNCF, o kernel do Linux desde 1992). Foi escolhida esta variante sobre a alternativa de "fundo/contexto + atualidade" porque o tema tem dois lados ativos e verificáveis hoje, não um evento recente que exija um contexto histórico extenso — por instrução explícita do escopo, o marco temporal foi limitado a 2024-2026, com apenas duas referências históricas breves (o debate Tanenbaum-Torvalds de 1992 e o caso Amazon Prime Video de 2023) por sua relevância direta como antecedentes técnicos citados ativamente em 2026.
Foram desdobradas linhas de investigação por ângulo temático: a favor de microsserviços (adoção empresarial, casos de escalonamento, DPI da Índia), contra/consolidação (CNCF, casos de reversão, custos operacionais), neutra/de mercado (relatórios de pesquisa de mercado, cifras de adoção), técnica (arquitetura de kernel, bases de dados, orquestração de agentes de IA), regulatória/governamental (EEUU, UE, China, Índia) e acadêmica (revisões sistemáticas de literatura, papers universitários 2025-2026). Foram consultadas mais de 65 fontes distintas durante a investigação original, superando o mínimo de 50 requerido; dessas, 39 foram citadas diretamente e de forma pontual no corpo deste texto — o restante informou o panorama geral sem sustentar um dado específico atribuível linha por linha.
A descoberta mais importante do processo de checagem de fatos foi precisamente metodológica: a cifra "42% de organizações consolidando microsserviços (CNCF, 2025)" — a mais citada de todo o debate — não pôde ser confirmada contra um documento primário da CNCF disponível publicamente, apesar de múltiplos tentativas de rastreamento direto em cncf.io. Ela é mantida no texto com marcador de confiança explícito e contexto de sua origem provável (conteúdo gerado por um pipeline automatizado com IA, citando-se em cadeia), em vez de omiti-la ou apresentá-la como fato confirmado, porque sua própria circulação é um dado relevante sobre como se forma o consenso técnico em 2026.
As três gráficas de radar usam dados comparativos derivados diretamente dos achados desta investigação, não estimativas livres; cada eixo se sustenta em pelo menos uma fonte citada no corpo do texto ou nesta seção.
Verificação adicional feita sobre o rascunho original: foi encontrada e adicionada a fonte primária real do blog de engenharia da Amazon Prime Video, ausente na bibliografia inicial; foi resolvida a citação "ManoIT, 2026" contra seu artigo real na DEV Community, confirmando que efetivamente é conteúdo produzido por um pipeline automatizado; foi reforçada a cifra de transações UPI de abril de 2026 com um comunicado direto do governo da Índia, subindo-a de amarelo para verde; foi substituída uma citação da Anthropic que apontava para um post sobre contenção de segurança — e não sobre arquitetura de agentes — por uma que descreve diretamente o design de agente único com subagentes; e foi substituída a referência secundária ao gasto federal dos EEUU pelo relatório primário da GAO. Nenhum achado contradisse as conclusões originais do texto.
Fuentes
- ManoIT / DEV Community, 2026
- CNCF, Encuesta Anual 2024
- CNCF y SlashData, nov. 2025
- SoftwareSeni, 2026
- ThirdEyeData, 2026
- ByteIota, 2026
- Amazon Prime Video Engineering, 2023
- Shopify Engineering, s.f.
- Kovyrin, en TechWorld with Milan, 2025
- Al-Qora'n & Al-Said Ahmad, 2025 (Future Internet)
- SAP Community, 2025
- Oracle Fusion Applications, Wikipedia
- Oracle Cloud Blog, 2023
- Murmu Software Infotech, 2026
- Abdullah Tariq, 2025
- Anthropic Engineering
- OpenAI Swarm (repositorio)
- Tao An, 2026
- Debate Tanenbaum-Torvalds, Wikipedia, 1992
- Torvalds, sobre el debate micro vs. monolítico
- Baeldung on Linux, 2024
- Reintech, 2026
- Kubermatic, 2026
- André Staltz, 2018
- Laoutaris, 2025
- GAO, 2025
- ITU Academy / GovStack, 2025
- GovStack Specification, s.f.
- Bertelsmann Stiftung, 2026
- Policy Circle, 2026
- Gobierno de India (PIB), 2026
- arXiv 2503.08725, 2025
- Digital China Wins the Future, 2026
- IDC, vía Huawei Cloud, 2026
- ResearchGate, 2026
- Martínez et al., 2026 (Tsinghua Science and Technology)
- arXiv 2511.04548, 2025
- FlowHunt, 2026
- Linux Foundation, dic. 2025
Perguntas frequentes
Qual é o percentual de organizações que estão consolidando microserviços de acordo com a pesquisa da CNCF?
O dado citado é de 42%, mas não pôde ser confirmado contra um documento primário legível, por isso deve ser tratado como 'amplamente repetido, não verificado de forma independente'.
O que a Amazon Prime Video fez com sua arquitetura de software?
A Amazon Prime Video consolidou um serviço de monitoramento de qualidade de vídeo de uma arquitetura distribuída para um monolito, alcançando uma redução de custos de infraestrutura de 90%.
Como é estruturada a arquitetura de software da Shopify?
A Shopify opera um 'monolito majestoso', um único aplicativo Ruby on Rails com componentes internos organizados por meio da ferramenta Packwerk, sem fragmentar o código em serviços independentes.
Que tipo de arquitetura de software a SAP utiliza?
A SAP descreve seu núcleo de S/4HANA como um 'monolito modular maciço' que está sendo decomposto gradualmente em direção a arquiteturas nativas de nuvem.
Qual é a filosofia de design de software da Anthropic e da OpenAI?
A Anthropic e a OpenAI utilizam um padrão de arquitetura que envolve um orquestrador central com subagentes limitados, em vez de uma malha de microserviços peer-to-peer.
Qual é o percentual de desenvolvedores backend que trabalham com microserviços de acordo com a pesquisa da CNCF?
46% dos desenvolvedores backend trabalham com microserviços, de acordo com a pesquisa da CNCF.
O que é um monolito modular no contexto da arquitetura de software?
Um monolito modular refere-se a uma arquitetura de software na qual os componentes estão separados por fronteiras de código, mas são executados no mesmo processo, sem chamadas de rede entre eles.
Larry
Comentarios
Sé el primero en comentar.