Amazon reconoció que uno de sus componentes críticos funciona mejor como monolito que como conjunto de microservicios: la migración generó un ahorro del 90% en costos operativos. La empresa que provee la infraestructura estándar de la industria para construir arquitecturas distribuidas terminó consolidando una de sus propias piezas.
Qué significa volver al monolito
Mantener cientos de servicios distribuidos que se comunican entre sí por red resulta caro y complejo. La alternativa elegida por Amazon se denomina 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. Es comparable a un edificio organizado por departamentos, en lugar de cien casas separadas que se comunican por teléfono todo el día.
Los costos de red y la orquestación de piezas independientes desaparecen. La organización interna del sistema se mantiene. A continuación, las diferencias clave:
Microservicios vs monolito modular: comparativa directa
| ¿Qué comparamos? | Microservicios / Serverless | Monolito modular |
|---|---|---|
| Costo operativo | Alto: se paga por transferencia de datos y orquestación | Bajo: la comunicación ocurre en memoria, sin costo de red |
| Complejidad | Elevada: implica gestionar 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, 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é se recupera al consolidar la arquitectura
-
Reducción de la factura de infraestructuraLos cargos por transiciones de estado en herramientas como AWS Step Functions y por la transferencia de datos entre servicios desaparecen. Amazon registró un ahorro del 90% en su componente de monitoreo.
-
Mayor velocidad de respuestaLas llamadas entre módulos ocurren en memoria. No hay red ni serialización (convertir objetos a JSON y viceversa en cada llamada), por lo que la latencia se reduce casi a cero.
-
Menor carga operativaMenos despliegues que coordinar, menos sistemas de monitoreo distribuidos y un único registro (log) donde revisar los fallos.
-
Mayor capacidad de iteración del equipoLos equipos de desarrollo dejan de esperar despliegues en cascada y pruebas de integración que tardan horas; el progreso vuelve a medirse en minutos.
Desventajas y riesgos reales
✓ Qué se pierde y qué conviene vigilar
-
Dificultad para escalar partes del sistemaSi un módulo necesita más recursos, es necesario escalar toda la aplicación, no solo esa parte. En cargas muy asimétricas, esto puede resultar costoso.
-
Riesgo de acoplamiento sin disciplinaCon el tiempo y sin reglas claras, los límites entre módulos se erosionan. El resultado es una 'bola de lodo': código tan acoplado que nadie quiere modificar.
-
Propagación de errores entre módulosSi algo falla en cualquier parte, el despliegue involucra a toda la aplicación, no solo al componente afectado.
Cómo consolidar un monolito
Consolidar y mejorar una arquitectura de este tipo implica considerar varios puntos clave.
✓ Hoja de ruta para consolidar un monolito
-
1. Detener la creación de nuevos microserviciosImplica congelar los nuevos microservicios y elegir uno existente como punto de partida para la nueva funcionalidad, mientras se define la estrategia de consolidación.
-
2. Unificar primero los flujos más problemáticosLos procesos de negocio fragmentados en varios servicios —compras, autenticación, notificaciones— se unifican primero, ya que es donde más se nota la mejora.
-
3. Reducir la cantidad de lenguajes y frameworksLo razonable es no superar dos lenguajes en el backend: cada lenguaje adicional representa un equipo adicional de mantenimiento.
-
4. Simplificar dónde viven los datosConviene evaluar si los datos pueden moverse a una base de datos centralizada o modularizada. Eliminar llamadas de red entre servicios de datos es uno de los mayores ahorros posibles.
-
5. Mantener fronteras internas aunque el código esté juntoEl uso de módulos o namespaces con APIs internas claras permite que, 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. La consolidación redujo los costos operativos en un 90%.
-
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 un diseño monolítico para reducir la complejidad de despliegue y hacerlo viable en 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 sumen 'microservicios' a su perfil profesional, sin que el problema lo exija, es un error frecuente: el costo lo asume el sistema, no quien tomó la decisión.
-
Dividir antes de entenderFragmentar el sistema antes de conocer bien el dominio de negocio genera servicios mal definidos que luego son difíciles 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, como ocurrió en el caso de Amazon.
Consejos útiles
✓ Recomendaciones de referentes de la industria
-
Martin Fowler: empezar con el monolitoFowler recomienda comenzar con un monolito y extraer servicios solo cuando el dolor real de la escala lo justifique con datos medibles, no con suposiciones sobre el futuro.
-
Sam Newman: los microservicios como último recursoNewman sostiene que los microservicios deberían considerarse después de haber agotado todas las opciones de modularización dentro de un monolito bien estructurado.
-
David Heinemeier Hansson: el majestuoso monolitoHansson afirma que solo las empresas con miles de ingenieros enfrentan 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 hay 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 relevante nunca fue '¿microservicios o monolito?', sino qué arquitectura resuelve los problemas actuales al menor costo.
La industria está redescubriendo que la simplicidad es una ventaja competitiva real. El patrón que emerge de los casos revisados —Amazon, Segment, Istio— sugiere que el monolito modular funciona mejor como base por defecto, y que los microservicios se justifican como excepción respaldada por datos, no por tendencia.
La decisión de dividir un servicio debería depender de si resuelve un problema de escala medible, no de la necesidad de parecer moderno: ese es, en última instancia, el criterio que separa a las empresas que ahorran costos de las que solo replican patrones ajenos.
Etiquetas
¿Te gustó este artículo? ¡Compártelo y suscríbete!
