Amazon —la empresa que te vende la infraestructura para construir microservicios— reconoció que para uno de sus componentes críticos, un monolito funcionaba mejor. El ahorro fue del 90% en costos operativos. Si eso no te hace cuestionar cómo tu equipo toma decisiones de arquitectura, sigue leyendo.
¿Qué significa volver al monolito?
Mantener cientos de servicios distribuidos que se comunican entre sí por red es caro y complejo. La alternativa que Amazon eligió se llama monolito modular: una aplicación que se despliega como una sola unidad, pero cuyo código interno mantiene fronteras estrictas entre módulos con APIs internas claras. Piénsalo como un edificio bien organizado por departamentos en lugar de cien casas separadas que se llaman por teléfono todo el día.
Desaparecen los costos de red y la orquestación de piezas independientes. La organización interna se mantiene. Aquí están las diferencias clave:
Microservicios vs monolito modular: comparativa directa
| ¿Qué comparamos? | Microservicios / Serverless | Monolito modular |
|---|---|---|
| Costo operativo | Alto: pagas por transferencia de datos y orquestación | Bajo: la comunicación ocurre en memoria, sin costo de red |
| Complejidad | Elevada: estás gestionando un sistema distribuido | Reducida: todo corre en un solo proceso |
| Rendimiento | Añade latencia por red y por convertir datos a JSON en cada llamada | Máxima velocidad: las llamadas entre módulos son en memoria |
| Pruebas | Lentas y complejas: pueden tardar minutos u horas | Rápidas: se ejecutan en milisegundos |
| Caso Amazon | AWS Step Functions + Lambda | Amazon ECS + EC2 |
¿Por qué este debate sacudió a la industria?
El problema no es técnico. Es de imitación. Muchas empresas copiaron la arquitectura de Netflix sin tener sus mismos problemas de escala, sus mismos presupuestos ni sus mismos equipos. Eso tiene nombre: Cargo Cult, que es adoptar las formas externas de una práctica exitosa sin entender por qué funciona en ese contexto específico.
El resultado: equipos de 5 personas gestionando la complejidad operativa diseñada para equipos de 500. Infraestructuras carísimas, difíciles de mantener y con bugs que saltan entre servicios como si fueran pistas de un laberinto.
Ventajas del monolito modular
✓ Qué recuperas al consolidar tu arquitectura
-
Tu factura de infraestructura baja drásticamenteDesaparecen los cargos por transiciones de estado en herramientas como AWS Step Functions y por la transferencia de datos entre servicios. Amazon lo comprobó con un 90% de ahorro en su componente de monitoreo.
-
Tu sistema responde más rápidoLas llamadas entre módulos ocurren en memoria. No hay red, no hay serialización (convertir objetos a JSON y viceversa en cada llamada). La latencia casi desaparece.
-
Operar el sistema deja de ser un trabajo de tiempo completoMenos despliegues que coordinar, menos sistemas de monitoreo distribuidos y un solo log donde buscar cuando algo falla.
-
Tu equipo puede iterar de nuevoLos desarrolladores dejan de esperar despliegues en cascada y pruebas de integración que tardan horas. Vuelven a medir el progreso en minutos.
Desventajas y riesgos reales
✓ Qué pierdes y qué debes vigilar
-
Escalar partes del sistema se complicaSi un módulo necesita más recursos, tienes que escalar toda la aplicación, no solo ese pedazo. En cargas muy asimétricas, eso puede salirte caro.
-
Sin disciplina, el código se convierte en un enredoCon el tiempo y sin reglas claras, los límites entre módulos se erosionan. Terminas con una 'bola de lodo': código tan acoplado que nadie quiere tocar.
-
Un error en un módulo menor afecta a todosSi algo sale mal en cualquier parte, el despliegue involucra a toda la aplicación, no solo al componente afectado.
Cómo consolidar tu monolito
Si deseas mantener y mejorar tu arquitectura monolito, déjame sugerirte algunos puntos importantes para hacerlo.
✓ Hoja de ruta para consolidar un monolito
-
1. Deja de cavarCongela la creación de nuevos microservicios. Elige uno existente como punto de partida donde irá la nueva funcionalidad mientras defines la estrategia de consolidación.
-
2. Une primero los flujos que más duelenIdentifica procesos de negocio fragmentados en varios servicios —compras, autenticación, notificaciones— y únelos en un solo proceso. Ahí es donde más vas a notar la mejora.
-
3. Reduce cuántos lenguajes y frameworks usasLo razonable es no superar dos lenguajes en el backend. Cada lenguaje adicional es un equipo adicional de mantenimiento.
-
4. Simplifica dónde viven los datosEvalúa si puedes mover los datos a una base de datos centralizada o modularizada. Eliminar llamadas de red entre servicios de datos es uno de los mayores ahorros.
-
5. Mantén fronteras internas aunque el código esté juntoUsa módulos o namespaces con APIs internas claras. Así, si en el futuro la escala exige extraer un servicio, el código ya está preparado para hacerlo sin un rediseño completo.
Casos reales que ya funcionan
✓ Empresas que consolidaron y midieron el resultado
-
Amazon Prime VideoMigró su sistema de monitoreo de video de AWS Step Functions y Lambda a un proceso único en Amazon ECS. Resultado: 90% de reducción en costos operativos.
-
Segment (Twilio)Consolidó más de 140 microservicios en uno solo llamado Centrifuge. Sus pruebas de integración pasaron de durar una hora a ejecutarse en milisegundos.
-
IstioEl plano de control de esta herramienta de red de servicios (service mesh) volvió a ser un monolito para reducir la complejidad de despliegue y hacerlo viable para equipos más pequeños.
Errores que cuestan dinero y tiempo
✓ Errores comunes al adoptar microservicios
-
Microservicios para el currículum, no para el productoImplementar arquitecturas distribuidas para que los ingenieros tengan 'microservicios' en LinkedIn, no porque el problema lo exija. El sistema lo paga, no el CV.
-
Dividir antes de entenderFragmentar el sistema antes de conocer bien el dominio de negocio genera servicios mal definidos que luego son imposibles de fusionar sin un rediseño completo.
-
No calcular cuánto cuesta mover datosMover fotogramas de video, archivos de audio o imágenes pesadas entre servicios a gran escala puede convertir una decisión técnica en una crisis financiera. Amazon lo vivió en carne propia.
Consejos útiles
✓ Recomendaciones de referentes de la industria
-
Martin Fowler: empieza con el monolitoComienza con un monolito y extrae servicios solo cuando el dolor real de la escala lo justifique con datos medibles, no con suposiciones sobre el futuro.
-
Sam Newman: los microservicios son el último recursoDeberían considerarse después de haber agotado todas las opciones de modularización dentro de un monolito bien estructurado.
-
David Heinemeier Hansson: el majestuoso monolitoSolo empresas con miles de ingenieros tienen los problemas que los microservicios resuelven. El resto paga los costos sin recibir los beneficios.
Preguntas frecuentes
¿Amazon abandonó los microservicios en toda su plataforma?
No. Solo consolidó un componente específico de monitoreo de video. El resto de la plataforma sigue usando arquitecturas distribuidas donde la escala lo justifica.
¿Esto significa que los microservicios son una mala idea?
No. Son herramientas poderosas para escalar equipos grandes y cargas de trabajo impredecibles, pero tienen un costo operativo muy alto que no todas las organizaciones pueden o deben asumir.
¿Qué es un monolito modular?
Una aplicación que se despliega como un solo bloque pero cuyo código interno está estrictamente dividido en módulos independientes con APIs internas claras, sin comunicación por red.
¿Cuándo tiene sentido usar microservicios?
Cuando tienes equipos grandes (más de 50 desarrolladores) que necesitan trabajar de forma autónoma, o cuando partes específicas del sistema tienen necesidades de escalado extremas y distintas al resto.
¿El serverless es el problema?
El serverless funciona muy bien para cargas bajas o esporádicas. El problema aparece en procesos constantes de alto volumen, donde el costo por ejecución se vuelve prohibitivo.
¿Cuál es más seguro: un monolito o los microservicios?
Los microservicios exponen más APIs y aumentan la superficie de ataque, aunque permiten aislar fallos entre servicios. Un monolito es más simple de proteger, pero un fallo puede propagarse a toda la aplicación.
Impresiones finales
El caso Amazon Prime Video no cierra el debate. Lo reencuadra. La pregunta correcta nunca fue '¿microservicios o monolito?' sino '¿qué arquitectura resuelve mis problemas actuales al menor costo?'.
La industria está redescubriendo que la simplicidad es una ventaja competitiva real. Un monolito modular como base sólida, y los microservicios como la excepción que se justifica con datos, no con tendencias.
La próxima vez que alguien en tu equipo proponga dividir un servicio, hazte una pregunta antes de aprobar: ¿estamos resolviendo un problema real o añadiendo complejidad para sentirnos modernos?
Etiquetas
¿Te gustó este artículo? ¡Compártelo y suscríbete!
