El péndulo se cansó de columpiarse Verifiqué el debate monolito vs. microservicios de 2026 contra 65+ fuentes primarias -- de Shopify y Amazon a la Unión Europea, China e India. Transcripción de la versión narrada (27 min). Narrada con voz sintética (Larry). El texto es de Esteban Rey — kilowatto.com. --- El péndulo se cansó de columpiarse. Verifiqué el debate monolito vs. microservicios de 2026 contra 65+ fuentes primarias -- de Shopify y Amazon a la Unión Europea, China e India. 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, en la que un grupo jura que romper el monolito fue la mejor decisión de su carrera, mientras que el otro grupo, en el mismo chat, manda capturas de pantalla de facturas de Kubernetes que no bajan de cinco cifras al mes, y ninguno miente, lo que es justamente el problema, ya que 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, y lo que encontré no es un ganador, sino un mapa de quién está haciendo qué, por qué, y 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", según ManoIT y DEV Community en 2026. Fui directo a cncf.io, revisé el reporte de la encuesta anual 2024, publicado por la CNCF en 2025, el anuncio de noviembre 2025 sobre el estudio con SlashData, también publicado por la CNCF en 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, según el reporte de la CNCF y SlashData en 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, incluida la caída de adopción de service mesh de 18% a 8%, según fuentes como SoftwareSeni, ThirdEyeData y ByteIota en 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, es 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%, según Amazon Prime Video Engineering en 2023. Sobre el caso más citado contra los microservicios, es un ejemplo que 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, y sigue siendo relevante después de tres años. 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, según se menciona en el blog de Shopify Engineering. 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, como se explicó en TechWorld with Milan por Kovyrin en dos mil veinticinco. La distinción importa: Shopify no evitó la modularidad, evitó la distribución. 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 dos mil veinticinco a dos mil veintiséis identifica como la tercera vía real, no binaria, entre monolito clásico y microservicios, según lo encontraron Al-Qora'n y Al-Said Ahmad en su investigación en dos mil veinticinco. El primer systematic literature review académico sobre el tema, publicado en la revista Future Internet, encontró apenas quince estudios primarios revisados por pares entre dos mil veinte y mayo de dos mil veinticinco, 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. En cuanto a Radar 1, que se enfoca en lo que hacen de verdad las grandes casas de software, los detalles se presentan de manera descriptiva. Mirando a las seis empresas que originaron esta pregunta, que son 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, se puede analizar su enfoque. SAP es quizás el caso más honesto del lote, ya que 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, según lo mencionado por la SAP Community en 2025. Esto no se trata de marketing de transformación digital, sino de una empresa de 50 años admitiendo que romper un monolito de ERP toma más de una década. Oracle, por otro lado, corre en paralelo dos discursos. Fusion Applications nació en 2011 sobre una arquitectura orientada a servicios clásica, y desde entonces el Proyecto Spectra mueve funcionalidad hacia microservicios en contenedores sobre Kubernetes gestionado, usando el framework Helidon, como se menciona en el Oracle Cloud Blog de 2023. Sin embargo, 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. Microsoft 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, es decir, empezar con monolito modular y extraer microservicios solo con evidencia real de necesidad, según Murmu Software en 2026. Además, su propia práctica interna de IA, el orquestador con subagentes aislados, confirma la misma filosofía. Apple no publica arquitectura de backend, pero dentro 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, lo que implica separar en frameworks internos sin fragmentar el proceso de compilación y despliegue, como menciona Tariq en 2025. Este patrón es el mismo que Shopify usa en el backend, aplicado al cliente. Anthropic y OpenAI son el caso más interesante de este radar, porque no compiten en ERP o e-commerce, sino en cómo se orquestan agentes de IA, y ahí su arquitectura es 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. OpenAI abandonó su framework experimental Swarm en 2024 por el SDK de Agentes en 2025, pero mantuvo el mismo principio de diseño minimalista, es decir, un agente que decide cuándo transferir el control a otro, sin coordinador central complejo ni comunicación en malla. Para este radar, se eligieron seis ejes que la propia investigación identificó como los más reveladores: independencia arquitectónica del legado, velocidad de despliegue, complejidad operativa asumida, integración nativa de IA/agentes, costo de mantenimiento por feature y madurez de gobernanza de fronteras, que se refiere a qué tan en serio se toman el Conway's Law. Se compararon cuatro perfiles representativos: SAP, con su ERP heredado en transición, Shopify, con su monolito modular nativo, Oracle, con su SOA híbrida, y Anthropic/OpenAI, con su IA nativa y orquestador más subagentes, porque intentar graficar 24 empresas en un solo radar habría sido ilegible. El resto del panorama corporativo, que incluye a 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. Sobre Radar 2 — El otro bando: quién mantiene el open source, los detalles están en el artículo. 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 es que el mundo del open source lleva décadas teniendo esta discusión, mucho antes de que "microservicios" fuera una palabra de moda corporativa. El caso fundacional es el kernel de Linux. 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. Torvalds respondió que los microkernels "empujan el problema al espacio de la comunicación, que es un problema más grande que el que dicen resolver". Treinta y cuatro años después, Linux, que es monolítico, corre en la inmensa mayoría de servidores del planeta, y GNU Hurd, que es un microkernel, sigue siendo un proyecto académico. La ironía es evidente: la infraestructura que hace posible correr microservicios, como contenedores, Kubernetes y la nube entera, está construida sobre un kernel que ganó su propia guerra siendo monolítico. PostgreSQL, MySQL y MariaDB 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. La respuesta dominante en 2025-2026 es mantener la base de datos monolítica y ponerle microservicios de aplicación alrededor, no adentro. Proxmox es el ejemplo más nítido del "otro estilo" de open source: una empresa austriaca pequeña, sin respaldo de una fundación como CNCF ni gobierno multi-vendor, que mantiene una plataforma todo-en-uno, hipervisor más contenedores LXC más almacenamiento más red, deliberadamente simple frente a la alternativa nativa de Kubernetes, KubeVirt. Es, en software de infraestructura, el mismo patrón que André Staltz describió hace años como la "escuela monolítica" del open source: 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. 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 open source. Para este radar usé cinco ejes: filosofía monolítica declarada, tamaño del equipo mantenedor, modularidad interna sin red, escala de adopción y dependencia de gobernanza de fundación. Comparé Linux, el 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 más de 20 proyectos, que 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. En el análisis de Radar 3 — Los gobiernos: cuatro filosofías, un mismo problema de escala, se destaca que los gobiernos no compiten por velocidad de mercado, sino que compiten por soberanía, interoperabilidad y no colapsar bajo su propia escala. Estados Unidos se encuentra en una situación complicada, ya que, según cifras de la Oficina de Rendición de Cuentas del Gobierno, 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, como se informó en 2025. Esto refleja el problema de la deuda técnica, que se paga en presupuesto, no en elegancia arquitectónica, similar al que enfrenta cualquier director de tecnología con un monolito de diez años. Por otro lado, la Unión Europea ha adoptado una postura contraria de forma explícita y documentada a través de GovStack, una iniciativa fundada por la ITU, Estonia, Alemania y DIAL, con financiamiento del Global Gateway de la UE. GovStack tiene una sesión de entrenamiento oficial titulada "Evitando el Monolito: Integrando Microservicios para una Transformación Digital sin Fricciones", según se documentó en 2025. La especificación técnica de GovStack define "building blocks" como módulos interoperables que pueden estar compuestos de microservicios de dominio. Esto representa una apuesta institucional explícita por el lado microservicios del debate, con el argumento de soberanía digital europea empujando en la misma dirección, como se menciona en un informe de la Bertelsmann Stiftung en 2026. India, por su parte, construyó el ejemplo de arquitectura por capas más grande del planeta, conocido como India Stack, sin usar nunca la palabra "microservicios" en su discurso público. India Stack incluye Aadhaar, con 1,400 millones de personas enroladas, UPI, con 22,350 millones de transacciones en un solo mes de abril de 2026, y DigiLocker, que operan como capas independientes conectadas por APIs abiertas, no como un sistema monolítico único de gobierno, según se informó en un comunicado del gobierno de India y corroborado por Policy Circle en 2026. La 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, como se detalla en un estudio publicado en arXiv en 2025. China, en cambio, 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", según se informó en 2026. A diferencia del modelo europeo de building blocks interoperables entre países soberanos, la centralización es explícitamente el objetivo estratégico, con un mercado de gobierno digital chino proyectado en más de 200 mil millones de yuanes para 2026, con 73% destinado a infraestructura de nube gubernamental, según un informe de IDC vía Huawei Cloud en 2026. En cuanto a Japón y Corea del Sur, no tienen una postura arquitectónica tan documentada o distintiva como los cuatro bloques mencionados, y 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 son la madurez de infraestructura en la nube, la modularidad/interoperabilidad declarada, la escala de transacciones probada, la soberanía y control estatal sobre proveedores privados, y la complejidad y madurez de los sistemas internos. Se compararon Estados Unidos, Unión Europea, China e India con peso igual, tal como se definió 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 systematic literature review formal sobre monolitos modulares en la nube, publicado en octubre de 2025 en la revista Future Internet, 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, según Al-Qora'n y Al-Said Ahmad en 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, según ResearchGate en 2026. La revista Tsinghua Science and Technology publicó en 2026 investigación sobre arquitecturas de microservicios para automatización industrial con requisitos de tiempo real, realizado por Martínez y otros, que se enfoca en un ángulo técnico específico, relacionado con la industria 4.0, y no en una postura institucional china sobre el debate general. En la literatura de instituciones indias, europeas y estadounidenses, se repite el patrón de decenas de papers sobre cómo migrar de monolito a microservicios, incluyendo la identificación automática de fronteras con inteligencia artificial, grafos de dependencia y aprendizaje automático, pero muy poca investigación que responda cuándo conviene hacerlo, y casi ninguna comparación rigurosa y reproducible de costos reales a escala empresarial. Un paper de 2025 publicado en arXiv, directamente titulado "Microservices Are Dying", propone abandonar la unidad de "microservicio" a favor de interfaces universales de módulo, lo que sugiere que incluso dentro de la comunidad técnica más entusiasta con la distribución, el vocabulario mismo empieza a sentirse insuficiente. 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, que consisten en 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", según se informó vía FlowHunt en 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, como se menciona en FlowHunt en 2026. Es importante destacar que esto significa que no hay canal punto a punto entre los subagentes. Esto no es una arquitectura de microservicios en malla, sino 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, según se puede ver en la documentación de Anthropic Engineering. OpenAI recorrió el mismo camino desde Swarm, que fue descontinuado, hasta su SDK actual de handoffs explícitos, sin coordinador de malla. En diciembre de 2025, el protocolo Agent2Agent se unió a MCP bajo una nueva fundación del Linux Foundation dedicada a IA y agentes, conocida como AAIF, según se informó en Linux Foundation en diciembre de 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, y no su discurso de marketing, es: hacia una forma de monolito modular con subagentes desechables, no hacia una malla distribuida de microservicios autónomos. 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 systematic literature review académico. Empieza con monolito modular, no con monolito plano ni con microservicios, y define fronteras de dominio claras, siguiendo el 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, mientras que deshacer una malla de microservicios mal delimitada es carísimo. Extrae un servicio solo cuando tengas evidencia real, no intuición, como necesidad de escalado verdaderamente independiente, requisitos regulatorios de aislamiento físico, como PCI en pagos, o un stack tecnológico genuinamente incompatible, como Python para ML, Go para el core. El tamaño del equipo importa más que el tamaño del producto, y 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, aplicando la Ley de Conway en sentido inverso. Si vas a integrar agentes de IA en tu arquitectura, 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, y no la malla de agentes peer-to-peer que se discutía en 2024. Sobre el semáforo final de esta investigación, los detalles están en la información del artículo.