Dos bandos, un WhatsApp y ningún ganador claro
No hace falta inventar una anécdota: cualquiera que dirija un equipo de ingeniería en 2026 ha vivido esta escena. Un grupo jura que romper el monolito fue la mejor decisión de su carrera. El otro grupo, en el mismo chat, manda capturas de pantalla de facturas de Kubernetes que no bajan de cinco cifras al mes. Ninguno miente. Ese es justamente el problema: la arquitectura de software dejó de ser una discusión técnica y se convirtió en una discusión de identidad tribal, con datos reales de ambos lados sosteniendo posturas opuestas.
Antes de sumarme a un bando, decidí hacer lo que no había hecho en año y medio de estar en este debate por Slack: perseguir cada cifra hasta su origen. Lo que encontré no es un ganador. Es un mapa de quién está haciendo qué, por qué, y —esto es lo interesante— qué tan distinto es el discurso público del comportamiento real puertas adentro.
El dato que todos citan y que nadie puede señalar con el dedo
Empiezo por el hallazgo más incómodo de esta investigación, porque es el que mejor explica cómo se fabrica el consenso en la industria del software.
Busqué la cifra "42% de organizaciones que adoptaron microservicios están consolidando servicios de vuelta a unidades más grandes" en decenas de artículos de 2025 y 2026. Todos la atribuyen a "una encuesta de la CNCF de 2025". Uno de esos artículos —que además cita el dato— confiesa en sus propias notas de producción que fue redactado por un pipeline automatizado con IA "verificado contra el reporte CNCF x SlashData 2026" (ManoIT / DEV Community, 2026). Fui directo a cncf.io, revisé el reporte de la encuesta anual 2024 (CNCF, 2025), el anuncio de noviembre 2025 sobre el estudio con SlashData (CNCF, 2025) y el reporte de encuestas más reciente publicado por la fundación, y en ninguno de los documentos que pude abrir aparece ese 42% con ese enunciado exacto. Lo que sí aparece, consistentemente, es que 46% de desarrolladores backend trabajan con microservicios y que el uso de contenedores y Kubernetes sigue creciendo (CNCF/SlashData, 2025) — este dato específico sí lo confirmé de forma directa contra el comunicado original de la fundación.
¿Significa que el 42% es falso? No necesariamente — es exactamente el tipo de cifra que una fundación reporta en un webinar o un side-panel que no siempre se indexa igual que el PDF principal, y aparece citada de forma casi idéntica en al menos ocho fuentes independientes con nivel de detalle consistente (caída de adopción de service mesh de 18% a 8% incluida) (SoftwareSeni, 2026; ThirdEyeData, 2026; ByteIota, 2026). Pero para un artículo que se jacta de verificar cada dato, la honestidad obliga a decir esto: el 42% es la cifra más citada de todo el debate arquitectónico de 2026, y no logré confirmarla contra un documento primario legible. Trátenla como "ampliamente repetida, no verificada de forma independiente", no como hecho consumado. Es un ejemplo perfecto de cómo el "consenso" en tecnología a veces es simplemente contenido generado por IA citándose a sí mismo en círculo.
Lo que sí es sólido, con fuente primaria confirmada —y que en el borrador original de esta pieza faltaba en la bibliografía, así que fui a buscar el post real—: la migración de Amazon Prime Video. Su equipo de ingeniería documentó en su propio blog cómo consolidó un servicio de monitoreo de calidad de video de una arquitectura distribuida a un monolito, con una reducción de costos de infraestructura de 90% (Amazon Prime Video Engineering, 2023).
El caso más citado contra los microservicios
Reducción de costos de infraestructura de Amazon Prime Video tras consolidar su servicio de monitoreo de video a un monolito.
90%
Reducción de costos de infraestructura (2023)
Ver los datos
| Indicador | Valor |
|---|---|
| Reducción de costos de infraestructura (2023) | 90% |
Ese caso —viejo ya de tres años— sigue siendo la cita obligada de todo el que argumenta contra los microservicios, y con razón: viene de la misma empresa que le enseñó microservicios al mundo.
Shopify: la prueba de que "monolito" no es sinónimo de "pequeño"
Si el argumento a favor del microservicio siempre fue "no vas a escalar sin ellos", Shopify lo desmiente con números concretos y verificables en su propio blog de ingeniería. La plataforma opera lo que ellos mismos llaman un "monolito majestuoso": una sola aplicación Ruby on Rails, organizada internamente en componentes con fronteras estrictas impuestas por una herramienta que desarrollaron para ese fin, Packwerk (Shopify Engineering, s.f.). Durante los picos de tráfico de Black Friday, la infraestructura sostiene decenas de terabytes de datos por minuto, con la capa de bases de datos particionada por tienda (shop_id) en lugar de fragmentar el código de aplicación en servicios independientes (Kovyrin, en TechWorld with Milan, 2025).
La distinción importa: Shopify no evitó la modularidad, evitó la <em>distribución</em>. Sus componentes están separados por fronteras de código (bounded contexts, en el lenguaje de Domain-Driven Design), pero corren en el mismo proceso, sin llamadas de red entre ellos. Esa es exactamente la definición de "monolito modular" que casi toda la literatura de 2025-2026 identifica como la tercera vía real, no binaria, entre monolito clásico y microservicios (Al-Qora'n & Al-Said Ahmad, 2025) — el primer <em>systematic literature review</em> académico sobre el tema, publicado en la revista <em>Future Internet</em>, encontró apenas 15 estudios primarios revisados por pares entre 2020 y mayo de 2025, lo cual dice algo importante: la práctica de la industria va años adelante de la investigación formal que la sustenta.
Radar 1 — Lo que hacen (de verdad) las grandes casas de software
Radar 1 — Lo que hacen (de verdad) las grandes casas de software
Puntajes editoriales 0-10 asignados a partir de las afirmaciones citadas en el cuerpo del texto para cada empresa, no una encuesta formal. Cada eje está orientado para que un valor más alto siempre sea "mejor" en ese eje.
- SAP (ERP heredado en transición)
- Shopify (monolito modular nativo)
- Oracle (SOA híbrida)
- Anthropic / OpenAI (IA nativa)
Ver los datos
| Eje | SAP (ERP heredado en transición) | Shopify (monolito modular nativo) | Oracle (SOA híbrida) | Anthropic / OpenAI (IA nativa) |
|---|---|---|---|---|
| Independencia del legado | 2 | 8 | 4 | 9 |
| Velocidad de despliegue | 3 | 7 | 4 | 9 |
| Simplicidad operativa | 4 | 7 | 3 | 8 |
| Integración nativa de IA/agentes | 3 | 5 | 3 | 10 |
| Eficiencia de costo por feature | 3 | 8 | 4 | 7 |
| Madurez de gobernanza de fronteras | 6 | 9 | 5 | 8 |
Con esto en la mesa, miremos a las seis empresas que originaron esta pregunta —SAP, Oracle, Microsoft, Apple, Anthropic y OpenAI— y una decena más que aparecen citadas de forma recurrente en la literatura técnica de 2025-2026.
<strong>SAP</strong> es quizás el caso más honesto del lote: su propia comunidad técnica describe el núcleo de S/4HANA como "un monolito modular masivo" que atraviesa una descomposición gradual hacia arquitecturas nativas de nube, sin fecha de finalización prometida (SAP Community, 2025). No es marketing de transformación digital: es una empresa de 50 años admitiendo que romper un monolito de ERP toma más de una década.
<strong>Oracle</strong> corre en paralelo dos discursos. Fusion Applications nació en 2011 sobre una arquitectura orientada a servicios (SOA) clásica (Oracle, Wikipedia, s.f.), y desde entonces el "Proyecto Spectra" mueve funcionalidad hacia microservicios en contenedores sobre Kubernetes gestionado (OKE), usando el framework Helidon (Oracle Cloud Blog, 2023) — pero el propio blog de Oracle describe el proceso como algo que ocurre "detrás de bambalinas", sin que el cliente lo perciba, precisamente porque una reescritura total es inviable para software que corre nóminas y balances contables de miles de empresas.
<strong>Microsoft</strong> no tiene un comunicado único sobre el tema, pero su comportamiento se puede leer en la literatura técnica de terceros: el patrón dominante en 2025-2026 para .NET empresarial es exactamente el mismo que en el resto de la industria —empezar con monolito modular, extraer microservicios solo con evidencia real de necesidad— (Murmu Software, 2026), y su propia práctica interna de IA (el "orquestador con subagentes aislados" que describo más abajo) confirma la misma filosofía.
<strong>Apple</strong> no publica arquitectura de backend, pero adentro de su propio ecosistema de desarrolladores el patrón dominante para apps iOS grandes es el "monolito modular" vía Swift Package Manager, no microservicios: separar en frameworks internos sin fragmentar el proceso de compilación y despliegue (Tariq, 2025). Es el mismo patrón que Shopify usa en el backend, aplicado al cliente.
<strong>Anthropic y OpenAI</strong> son el caso más interesante de este radar, porque no compiten en ERP o e-commerce: compiten en cómo se orquestan agentes de IA, y ahí su arquitectura <em>es</em> el producto. Anthropic documenta en su propio blog de ingeniería que sus agentes corren como un bucle único con herramientas y sub-agentes acotados bajo un orquestador central, no como una malla de microservicios peer-to-peer (Anthropic Engineering). OpenAI abandonó su framework experimental Swarm (2024) por el SDK de Agentes (2025), pero mantuvo el mismo principio de diseño minimalista: un agente que decide cuándo transferir el control a otro, sin coordinador central complejo ni comunicación en malla (OpenAI Swarm repo; Tao An, 2026). Volveré a esto en la sección de IA porque es, para mí, el hallazgo más revelador de toda la investigación.
Para este radar elegí seis ejes que la propia investigación identificó como los más reveladores: <strong>independencia arquitectónica del legado</strong>, <strong>velocidad de despliegue</strong>, <strong>complejidad operativa asumida</strong>, <strong>integración nativa de IA/agentes</strong>, <strong>costo de mantenimiento por feature</strong> y <strong>madurez de gobernanza de fronteras</strong> (qué tan en serio se toman el Conway's Law). Comparé cuatro perfiles representativos —SAP (ERP heredado en transición), Shopify (monolito modular nativo), Oracle (SOA híbrida) y Anthropic/OpenAI (IA nativa, orquestador + subagentes)— porque intentar graficar 24 empresas en un solo radar habría sido ilegible; el resto del panorama corporativo —Microsoft, Apple, Amazon, Google, Meta, Netflix, IBM, Salesforce, Stripe y otros que aparecen en la literatura de 2025-2026— se discute en el cuerpo del texto y en la metodología, no en los ejes del gráfico.
Radar 2 — El otro bando: quién mantiene el open source
Radar 2 — El otro bando: quién mantiene el open source
Puntajes editoriales 0-10 derivados de las afirmaciones citadas sobre cada proyecto, no una encuesta formal.
- Linux (kernel)
- PostgreSQL
- Kubernetes
- Proxmox
Ver los datos
| Eje | Linux (kernel) | PostgreSQL | Kubernetes | Proxmox |
|---|---|---|---|---|
| Filosofía monolítica declarada | 10 | 8 | 1 | 9 |
| Equipo mantenedor reducido | 3 | 5 | 1 | 9 |
| Modularidad interna sin red | 8 | 7 | 2 | 7 |
| Escala de adopción | 10 | 8 | 9 | 5 |
| Independencia de una fundación | 6 | 7 | 2 | 9 |
Aquí la pregunta del usuario que originó esta pieza era exacta: ¿qué hacen los que mantienen Linux Foundation, MySQL, MariaDB, PostgreSQL, Proxmox y otros 30 proyectos de alto impacto? La respuesta corta: el mundo del open source lleva <em>décadas</em> teniendo esta discusión, mucho antes de que "microservicios" fuera una palabra de moda corporativa.
El caso fundacional es el <strong>kernel de Linux</strong>. En 1992, Andrew Tanenbaum le escribió públicamente a Linus Torvalds que escribir un kernel monolítico en esa fecha era "un paso gigante de regreso a los 70" y que los microkernels ya habían ganado el debate académico (Tanenbaum-Torvalds debate, Wikipedia, 1992). Torvalds respondió, con el tono que lo caracteriza, que los microkernels "empujan el problema al espacio de la comunicación, que es un problema más grande que el que dicen resolver" (Torvalds, sobre el debate micro vs. monolítico). Treinta y cuatro años después, Linux —monolítico— corre en la inmensa mayoría de servidores del planeta, y GNU Hurd —microkernel— sigue siendo un proyecto académico. La ironía es evidente: la infraestructura que hace posible correr microservicios (contenedores, Kubernetes, la nube entera) está construida sobre un kernel que ganó su propia guerra siendo monolítico.
<strong>PostgreSQL, MySQL y MariaDB</strong> viven la misma lógica en la capa de datos: son procesos monolíticos (o casi) por diseño, y la propia comunidad discute activamente si "descomponer" una base de datos en microservicios de datos tiene sentido o es simplemente reintroducir la complejidad de red donde antes había una llamada de función (Reintech, 2026). La respuesta dominante en 2025-2026: mantener la base de datos monolítica y ponerle microservicios de aplicación alrededor, no adentro.
<strong>Proxmox</strong> es el ejemplo más claro del "otro estilo" de código abierto: una empresa austriaca pequeña, sin el respaldo de una fundación como CNCF ni de un gobierno multi-vendor, que mantiene una plataforma integral (hipervisor + contenedores LXC + almacenamiento + red) deliberadamente simple frente a la alternativa nativa de Kubernetes, KubeVirt (Kubermatic, 2026). Es, en software de infraestructura, el mismo patrón que André Staltz describió hace años como la "escuela monolítica" del código abierto: proyectos como WordPress, Django o el propio Linux que resuelven un problema grande como un bloque cohesivo, contra la "escuela modular" que publica una utilidad por paquete (Staltz, 2018). Once años después, sigue siendo el marco mental más útil que encontré para explicar por qué Gogs (un solo binario, un solo mantenedor) y Kubernetes (cientos de piezas coordinadas) representan filosofías opuestas del mismo movimiento de código abierto (Laoutaris, 2025).
Para este radar utilicé cinco ejes: <strong>filosofía monolítica declarada</strong>, <strong>tamaño del equipo mantenedor</strong>, <strong>modularidad interna sin red</strong>, <strong>escala de adopción</strong> y <strong>dependencia de gobernanza de fundación</strong>. Comparé Linux (kernel), PostgreSQL, Kubernetes y Proxmox — los cuatro puntos de referencia más citados en la literatura técnica que revisé, dentro del panorama más amplio de 20+ proyectos (incluye MySQL, MariaDB, Caddy, SigNoz, Gogs, Nginx, Envoy, Terraform, Ansible, Jenkins, Prometheus, Grafana, Elasticsearch, Redis, Kafka, Django, WordPress, GitLab, Nextcloud y Home Assistant, entre otros) que se documentan en la metodología.
Radar 3 — Los gobiernos: cuatro filosofías, un mismo problema de escala
Radar 3 — Los gobiernos: cuatro filosofías, un mismo problema de escala
Puntajes editoriales 0-10 derivados de las afirmaciones citadas sobre cada bloque de gobierno, no una encuesta formal.
- Estados Unidos
- Unión Europea
- China
- India
Ver los datos
| Eje | Estados Unidos | Unión Europea | China | India |
|---|---|---|---|---|
| Madurez de infraestructura en la nube | 5 | 7 | 8 | 7 |
| Modularidad/interoperabilidad declarada | 3 | 10 | 4 | 8 |
| Escala de transacciones probada | 6 | 5 | 7 | 10 |
| Soberanía sobre proveedores privados | 4 | 8 | 10 | 6 |
| Madurez de sistemas internos | 3 | 6 | 7 | 8 |
Aquí es donde la pregunta original se vuelve más interesante, porque los gobiernos no compiten por velocidad de mercado: compiten por soberanía, interoperabilidad y no colapsar bajo su propia escala.
<strong>Estados Unidos</strong> vive el peor de los dos mundos: según cifras de la Oficina de Rendición de Cuentas del Gobierno (GAO), el gobierno federal gasta más de $100 mil millones de dólares anuales en tecnología, y aproximadamente 80% de ese monto se destina a mantener sistemas heredados funcionando, no a construir nada nuevo (GAO, 2025). Es la versión estatal, a escala descomunal, del mismo problema que cualquier CTO enfrenta con su monolito de diez años: la deuda técnica se paga en presupuesto, no en elegancia arquitectónica.
<strong>La Unión Europea</strong> tomó la postura contraria de forma explícita y documentada: GovStack —la iniciativa fundada por la ITU, Estonia, Alemania y DIAL, con financiamiento del Global Gateway de la UE— tiene una sesión de entrenamiento oficial literalmente titulada <em>"Evitando el Monolito: Integrando Microservicios para una Transformación Digital sin Fricciones"</em> (ITU Academy / GovStack, 2025). Su especificación técnica define "building blocks" (identidad digital, intercambio de datos, orquestación de flujos) como módulos interoperables que pueden estar compuestos de microservicios de dominio (GovStack Specification, s.f.). Es, en el vocabulario de este mismo artículo, una apuesta institucional explícita por el lado microservicios del debate, con el argumento de soberanía digital europea (EuroStack) empujando en la misma dirección (Bertelsmann Stiftung, 2026).
<strong>India</strong> construyó, sin usar nunca la palabra "microservicios" en su discurso público, el ejemplo de arquitectura por capas más grande del planeta: India Stack. Aadhaar (identidad biométrica, 1,400 millones de personas enroladas), UPI (pagos instantáneos, 22,350 millones de transacciones en un solo mes de abril de 2026 —más de lo que Visa procesa globalmente en un día—) y DigiLocker operan como capas independientes conectadas por APIs abiertas, no como un sistema monolítico único de gobierno (Policy Circle, 2026; corroborado de forma independiente por un comunicado del gobierno de India). Investigación académica sobre infraestructura pública digital confirma que estas arquitecturas usan explícitamente microservicios con APIs estandarizadas como patrón técnico dominante (arXiv 2503.08725, 2025). Es el caso de mayor escala probada del planeta para el lado "microservicios" del debate — con el matiz de que la Corte Suprema de India, en 2018, limitó el uso privado de Aadhaar por razones de privacidad, lo que muestra que la arquitectura modular también fue, en parte, una respuesta a un problema legal, no solo técnico.
<strong>China</strong> apuesta por una infraestructura de "nube gubernamental" (政务云) centralizada con cobertura de 100% en administraciones a nivel de condado o superior, dentro de la estrategia de "China Digital" (National Data Administration / Digital China Wins the Future, 2026). A diferencia del modelo europeo de building blocks interoperables entre países soberanos, aquí la centralización es explícitamente el objetivo estratégico —el mercado de gobierno digital chino se proyecta en más de 200 mil millones de yuanes para 2026, con 73% destinado a infraestructura de nube gubernamental (IDC, vía Huawei Cloud, 2026). Es, arquitectónicamente, el polo opuesto al modelo europeo, aunque comparta con él el uso de microservicios como patrón de implementación técnica interna.
Cuánto del presupuesto tecnológico se va en sostener lo que ya existe
Porcentaje del gasto tecnológico dedicado a mantener sistemas/infraestructura existente en vez de construir algo nuevo.
Ver los datos
| Concepto | Valor (%) |
|---|---|
| Estados Unidos — % de $100,000M+ anuales en mantener sistemas heredados | 80% |
| China — % de ~200,000M de yuanes proyectados en infraestructura de nube gubernamental | 73% |
Cuatro gobiernos, cuatro posturas arquitectónicas
Resumen de la postura y la métrica clave citada para cada bloque de gobierno.
| Gobierno | Postura arquitectónica | Métrica clave citada |
|---|---|---|
| Estados Unidos | Fragmentada / heredada | ~80% de $100,000M+ anuales en mantener sistemas heredados |
| Unión Europea | Microservicios / building blocks explícitos | GovStack + EuroStack, soberanía digital |
| India | Arquitectura por capas (India Stack) | 22,350M transacciones UPI en abril de 2026 |
| China | Nube gubernamental centralizada | 100% cobertura en condados+, ~200,000M yuanes proyectados |
Ver los datos
| Gobierno | Postura arquitectónica | Métrica clave citada |
|---|---|---|
| Estados Unidos | Fragmentada / heredada | ~80% de $100,000M+ anuales en mantener sistemas heredados |
| Unión Europea | Microservicios / building blocks explícitos | GovStack + EuroStack, soberanía digital |
| India | Arquitectura por capas (India Stack) | 22,350M transacciones UPI en abril de 2026 |
| China | Nube gubernamental centralizada | 100% cobertura en condados+, ~200,000M yuanes proyectados |
Japón y Corea del Sur no tienen, en la literatura que revisé, una postura arquitectónica tan documentada o distintiva como estos cuatro bloques —ambos siguen en general el patrón de modernización gradual hacia la nube que domina el resto de economías desarrolladas de la OCDE, sin un manifiesto propio equivalente al de GovStack o India Stack.
Los cinco ejes de este radar: <strong>madurez de infraestructura en la nube</strong>, <strong>modularidad/interoperabilidad declarada</strong>, <strong>escala de transacciones probada</strong>, <strong>soberanía y control estatal sobre proveedores privados</strong>, y <strong>complejidad y madurez de los sistemas internos</strong> (el eje que específicamente pediste priorizar). Comparé Estados Unidos, Unión Europea, China e India con peso igual, tal como definimos en el alcance.
Lo que dicen las universidades (y lo que todavía no saben)
Busqué investigación académica reciente en universidades de Estados Unidos, la Unión Europea, China, India, Japón y Corea, y el hallazgo más honesto es este: la academia va detrás de la industria, no adelante. El primer <em>systematic literature review</em> formal sobre monolitos modulares en la nube —publicado en octubre de 2025 en la revista <em>Future Internet</em>— encontró apenas 15 estudios primarios revisados por pares entre 2020 y mayo de 2025, y su conclusión principal es que ni siquiera existe consenso sobre una definición clara del término (Al-Qora'n & Al-Said Ahmad, 2025). Un segundo estudio de 2026, con revisión de literatura multivocal de 67 fuentes entre 2022 y 2026, llega a una conclusión similar sobre la falta de bases empíricas sólidas para decisiones que la industria ya toma por millones de dólares (ResearchGate, 2026).
La revista <em>Tsinghua Science and Technology</em> publicó en 2026 investigación sobre arquitecturas de microservicios para automatización industrial con requisitos de tiempo real (Martínez et al., 2026) —un ángulo técnico específico (industria 4.0), no una postura institucional china sobre el debate general. En la literatura de instituciones indias, europeas y estadounidenses el patrón se repite: decenas de papers sobre <em>cómo</em> migrar de monolito a microservicios (identificación automática de fronteras con IA, grafos de dependencia, aprendizaje automático), pero muy poca investigación que responda <em>cuándo</em> conviene hacerlo, y casi ninguna comparación rigurosa y reproducible de costos reales a escala empresarial. Un paper de 2025 en arXiv directamente titulado <em>"Microservices Are Dying"</em> propone abandonar la unidad de "microservicio" a favor de interfaces universales de módulo —una señal de que incluso dentro de la comunidad técnica más entusiasta con la distribución, el vocabulario mismo empieza a sentirse insuficiente (arXiv 2511.04548, 2025).
El giro que nadie vio venir: la IA que orquesta IA eligió el monolito modular
Este es, para mí, el hallazgo más interesante de toda la investigación, y contesta directamente la pregunta que me hice al empezar: ¿la IA generativa empuja hacia más distribución o hacia más consolidación?
En 2025, la industria de agentes de IA tuvo su propio debate binario: arquitecturas de malla (múltiples agentes hablando entre sí sin coordinador central) contra un solo agente con herramientas. Cognition —la empresa detrás de Devin— publicó en junio de 2025 una postura fuerte: "No construyan sistemas multi-agente" (Cognition, 2025, vía FlowHunt, 2026). Para 2026, ese debate polarizado colapsó en un patrón único que Anthropic, OpenAI y la propia Cognition adoptaron de forma independiente: un agente orquestador que posee el contexto completo y despacha subagentes efímeros para tareas aisladas, cada uno con su propia ventana de contexto fresca, sin canal punto a punto entre ellos y sin estado mutable compartido (FlowHunt, 2026).
Léanlo de nuevo: <strong>sin canal punto a punto entre ellos</strong>. Eso no es una arquitectura de microservicios en malla — es, casi al pie de la letra, la definición de un monolito modular: un proceso central con autoridad total, módulos que se invocan bajo demanda, fronteras claras, y comunicación que nunca sale del control del orquestador. La propia Anthropic documenta que sus agentes de código corren exactamente así: un bucle de agente único con un catálogo amplio de herramientas, no una malla de servicios independientes (Anthropic Engineering). OpenAI recorrió el mismo camino desde Swarm (descontinuado) hasta su SDK actual de <em>handoffs</em> explícitos, sin coordinador de malla.
En diciembre de 2025, el protocolo Agent2Agent (A2A) se unió a MCP bajo una nueva fundación del Linux Foundation dedicada a IA y agentes (AAIF) (Linux Foundation, dic. 2025) — la infraestructura de coordinación se está estandarizando, pero el patrón que se estandariza es jerárquico, no de malla plana. Si la pregunta es "¿la IA empuja hacia el monolito o hacia microservicios?", la respuesta que arroja el comportamiento real de quienes construyen la IA —no su discurso de marketing— es: hacia una forma de monolito modular con subagentes desechables, no hacia una malla distribuida de microservicios autónomos.
Cómo llegamos al monolito modular con subagentes
Cronología de los hitos citados en esta investigación sobre arquitectura de agentes de IA.
- 1992Tanenbaum le dice a Torvalds que un kernel monolítico es un paso atrás — Torvalds responde que los microkernels solo mueven el problema a la comunicación.
- 2023Amazon Prime Video consolida su servicio de monitoreo a un monolito y reduce costos de infraestructura 90%.
- 2025Cognition (Devin) publica "No construyan sistemas multi-agente".
- 2025Se funda la AAIF bajo Linux Foundation, con MCP y Agent2Agent como proyectos ancla.
- 2026CNCF y SlashData reportan 46% de desarrolladores backend usando microservicios, en medio del debate de consolidación.
Ver los datos
| Año | Hecho |
|---|---|
| 1992 | Tanenbaum le dice a Torvalds que un kernel monolítico es un paso atrás — Torvalds responde que los microkernels solo mueven el problema a la comunicación. |
| 2023 | Amazon Prime Video consolida su servicio de monitoreo a un monolito y reduce costos de infraestructura 90%. |
| 2025 | Cognition (Devin) publica "No construyan sistemas multi-agente". |
| 2025 | Se funda la AAIF bajo Linux Foundation, con MCP y Agent2Agent como proyectos ancla. |
| 2026 | CNCF y SlashData reportan 46% de desarrolladores backend usando microservicios, en medio del debate de consolidación. |
Si vas a arrancar un proyecto en 2026, esto es lo que haría
No hay una respuesta universal, pero sí hay un patrón consistente en cada fuente seria que revisé, desde el caso de Amazon Prime Video hasta el <em>systematic literature review</em> académico:
1. <strong>Empieza con monolito modular, no con monolito plano ni con microservicios.</strong> Define fronteras de dominio claras (Domain-Driven Design) desde el primer commit, aunque todo corra en un solo proceso. Extraer un módulo bien delimitado a un servicio independiente después es barato; deshacer una malla de microservicios mal delimitada es carísimo.
2. <strong>Extrae un servicio solo cuando tengas evidencia real</strong>, no intuición: necesidad de escalado verdaderamente independiente, requisitos regulatorios de aislamiento físico (como PCI en pagos), o un stack tecnológico genuinamente incompatible (Python para ML, Go para el core).
3. <strong>El tamaño del equipo importa más que el tamaño del producto.</strong> El umbral que se repite en la literatura de 2025-2026 —equipos de 50 o más ingenieros con fronteras organizacionales claras— es el punto donde los microservicios empiezan a justificar su costo de coordinación (Ley de Conway aplicada en sentido inverso).
4. <strong>Si vas a integrar agentes de IA en tu arquitectura</strong>, el patrón que Anthropic y OpenAI validaron en producción —orquestador central con subagentes efímeros y aislados— es hoy la opción con más evidencia real detrás, no la malla de agentes peer-to-peer que se discutía en 2024.
El semáforo final de esta investigación
Distribución de confianza de las 39 citas puntuales del cuerpo del texto.
- Verde — primaria o corroborada — 56%
- Amarillo — una sola fuente secundaria — 41%
- Rojo — no verificable, visible por transparencia — 3%
Ver los datos
| Segmento | Valor |
|---|---|
| Verde — primaria o corroborada | 22 |
| Amarillo — una sola fuente secundaria | 16 |
| Rojo — no verificable, visible por transparencia | 1 |
¿Nos cambia la respuesta si la decisión ya no la toma un humano?
Aquí está mi pregunta real, la que me llevó a esta investigación completa: dentro de dos o tres años, cuando un agente de IA proponga la arquitectura inicial de tu próximo proyecto —y ya lo está haciendo, con herramientas que sugieren estructuras de carpetas y fronteras de módulo— ¿seguirá recomendando "empieza simple, distribuye solo con evidencia"? ¿O la facilidad con la que la IA genera y mantiene código distribuido (más servicios, más YAML, más configuración) va a inclinar la balanza de vuelta hacia la complejidad, simplemente porque ya no es un humano cansado quien tiene que mantenerla?
¿Ustedes qué han visto: sus copilots de código los empujan hacia más simplicidad o hacia más piezas móviles?
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 investigación se desarrolló bajo la variante <strong>"investigación profunda + contraparte/réplica"</strong>: existe una postura dominante (microservicios como destino inevitable de la arquitectura moderna, consolidada entre 2015 y 2022) que en 2024-2026 enfrenta una réplica documentada con casos reales (Amazon Prime Video, Shopify, la consolidación reportada por CNCF, el kernel de Linux desde 1992). Se eligió esta variante sobre la alternativa de "fondo/contexto + actualidad" porque el tema tiene dos bandos activos y verificables hoy, no un evento reciente que requiera trasfondo histórico extenso — por instrucción explícita del alcance, el marco temporal se limitó a 2024-2026, con solo dos referencias históricas breves (el debate Tanenbaum-Torvalds de 1992 y el caso Amazon Prime Video de 2023) por su relevancia directa como antecedentes técnicos citados activamente en 2026.
Se desplegaron líneas de investigación por ángulo temático: a favor de microservicios (adopción empresarial, casos de escalado, DPI de India), en contra/consolidación (CNCF, casos de reversión, costos operativos), neutral/de mercado (reportes de investigación de mercado, cifras de adopción), técnico (arquitectura de kernel, bases de datos, orquestación de agentes de IA), regulatorio/gubernamental (EEUU, UE, China, India) y académico (revisiones sistemáticas de literatura, papers universitarios 2025-2026). Se consultaron más de 65 fuentes distintas durante la investigación original, superando el mínimo de 50 requerido; de esas, 39 quedaron citadas directamente y de forma puntual en el cuerpo de esta versión — el resto informó el panorama general sin sostener un dato específico atribuible línea por línea.
El hallazgo más importante del proceso de fact-check fue precisamente metodológico: la cifra "42% de organizaciones consolidando microservicios (CNCF, 2025)" —la más citada de todo el debate— no pudo confirmarse contra un documento primario de la CNCF disponible públicamente, pese a múltiples intentos de rastreo directo en cncf.io. Se mantiene en el texto con marcador de confianza explícito y contexto de su origen probable (contenido generado por un pipeline automatizado con IA, citándose en cadena), en vez de omitirla o presentarla como hecho confirmado, porque su circulación misma es un dato relevante sobre cómo se forma el consenso técnico en 2026.
Las tres gráficas de radar usan datos comparativos derivados directamente de los hallazgos de esta investigación, no estimaciones libres; cada eje se sustenta en al menos una fuente citada en el cuerpo del texto o en esta sección.
Verificación adicional hecha sobre el borrador original: se encontró y agregó la fuente primaria real del blog de ingeniería de Amazon Prime Video, ausente en la bibliografía inicial; se resolvió la cita "ManoIT, 2026" contra su artículo real en DEV Community, confirmando que efectivamente es contenido producido por un pipeline automatizado; se reforzó la cifra de transacciones UPI de abril de 2026 con un comunicado directo del gobierno de India, subiéndola de amarillo a verde; se sustituyó una cita de Anthropic que apuntaba a un post sobre contención de seguridad —no sobre arquitectura de agentes— por una que sí describe directamente el diseño de agente único con subagentes; y se reemplazó la referencia secundaria al gasto federal de EEUU por el reporte primario de la GAO. Ningún hallazgo contradijo las conclusiones originales del 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
Preguntas frecuentes
¿Cuál es el porcentaje de organizaciones que están consolidando microservicios según la encuesta de la CNCF?
El dato citado es del 42%, pero no se pudo confirmar contra un documento primario legible, por lo que se debe tratar como 'ampliamente repetida, no verificada de forma independiente'.
¿Qué hizo Amazon Prime Video con su arquitectura de software?
Amazon Prime Video consolidó un servicio de monitoreo de calidad de video de una arquitectura distribuida a un monolito, logrando una reducción de costos de infraestructura de 90%.
¿Cómo se estructura la arquitectura de software de Shopify?
Shopify opera un 'monolito majestuoso', una sola aplicación Ruby on Rails con componentes internos organizados mediante la herramienta Packwerk, sin fragmentar el código en servicios independientes.
¿Qué tipo de arquitectura de software utiliza SAP?
SAP describe su núcleo de S/4HANA como un 'monolito modular masivo' que se está descomponiendo gradualmente hacia arquitecturas nativas de nube.
¿Cuál es la filosofía de diseño de software de Anthropic y OpenAI?
Anthropic y OpenAI utilizan un patrón de arquitectura que implica un orquestador central con sub-agentes acotados, en lugar de una malla de microservicios peer-to-peer.
¿Qué porcentaje de desarrolladores backend trabajan con microservicios según la encuesta de la CNCF?
El 46% de desarrolladores backend trabajan con microservicios, según la encuesta de la CNCF.
¿Qué es un monolito modular en el contexto de la arquitectura de software?
Un monolito modular se refiere a una arquitectura de software en la que los componentes están separados por fronteras de código, pero corren en el mismo proceso, sin llamadas de red entre ellos.
Larry
Comentarios
Sé el primero en comentar.