Cuándo no necesitas microservicios

Qué son los microservicios

Un microservicio es una pieza pequeña de software que se encarga de una sola cosa del negocio, se despliega por separado y se comunica con las demás mediante APIs o eventos. En lugar de una aplicación grande que lo contiene todo, el sistema es un conjunto de servicios independientes: uno para el catálogo, otro para los pagos, otro para las notificaciones.

El término se popularizó a partir de 2014, con un artículo de James Lewis y Martin Fowler que describía este estilo de arquitectura. Su idea central es que cada servicio puede cambiarse, desplegarse y escalarse sin tocar al resto.

Monolito

Una sola aplicación y una sola base de datos.

Catálogo Pagos Notificaciones Usuarios Base de datos

Microservicios

Servicios independientes, cada uno con sus propios datos.

API Gateway

CatálogoBD propia

PagosBD propia

NotificacionesBD propia

UsuariosBD propia

En un monolito todo vive y se despliega junto. En microservicios, los servicios se hablan a través de APIs.

Qué ganas y qué pagas

Los microservicios no son gratis: cambian un tipo de complejidad por otro. Conviene mirar los dos lados.

Lo que ganas

Despliegues independientes. Un cambio en pagos no obliga a publicar todo el sistema.
Escalado selectivo. Aumentas solo el servicio que recibe la carga.
Equipos autónomos. Cada equipo es dueño de un servicio de punta a punta.
Aislamiento de fallas. Si un servicio falla, no necesariamente cae todo.
Libertad tecnológica. Cada servicio puede usar la herramienta que mejor le quede.

Lo que pagas

Complejidad operativa. Más piezas que desplegar, monitorear y asegurar.
Datos distribuidos. Sin una sola base de datos, las transacciones entre servicios se complican.
Red y latencia. Lo que antes era una llamada interna ahora cruza la red y puede fallar.
Observabilidad. Seguir una petición por varios servicios exige trazas y registros centralizados.
Pruebas más difíciles. Hay que probar las integraciones, no solo cada pieza.

Las ventajas aparecen cuando el sistema y la organización son lo bastante grandes como para necesitarlas. Antes de eso, el costo suele llegar primero.

Casos de uso donde sí tienen sentido

Los microservicios rinden cuando las partes del sistema tienen ritmos, cargas o dueños distintos. Estos son escenarios típicos:

Comercio electrónico

El catálogo recibe consultas todo el día, mientras que el pago y el inventario se saturan en fechas como el Hot Sale o el Buen Fin. Separarlos permite escalar solo lo que se llena.

Catálogo, carrito, pagos, envíos

Pagos y banca digital

Los cobros y el antifraude tienen requisitos de seguridad y auditoría más estrictos que el resto. Aislarlos limita el alcance de los controles y de los fallos.

Cobros, antifraude, conciliación

Streaming y contenido

Reproducción, recomendaciones y facturación tienen cargas muy distintas. Empresas como Netflix y Amazon suelen citarse como ejemplos clásicos de este enfoque.

Reproducción, recomendaciones, facturación

Integración empresarial

Conectar Salesforce, un ERP y otras bases de datos mediante capas de APIs permite reutilizar servicios y cambiar un sistema sin romper los demás. Es la idea detrás del enfoque API-led de plataformas como MuleSoft.

API de sistema, de proceso y de experiencia

Notificaciones y mensajería

Enviar correos, SMS o mensajes es una tarea que usa todo el sistema. Un servicio dedicado evita duplicar lógica y permite cambiar de proveedor en un solo lugar.

Plantillas, envío, reintentos

Inteligencia artificial en producción

Los modelos suelen desplegarse como servicios aparte porque necesitan hardware y ritmos de actualización distintos a los de la aplicación que los usa.

Inferencia, evaluación, preprocesamiento

Señales de que no los necesitas

La pregunta honesta no es si los microservicios son buenos, sino si resuelven un problema que de verdad tienes. Suelen sobrar cuando:

Tu equipo es pequeño. Si un solo equipo puede desplegar todo sin pisarse, no tienes el problema que los microservicios resuelven.
El producto aún se está definiendo. Los límites entre servicios son difíciles de acertar cuando el negocio cambia cada semana, y moverlos después cuesta mucho más que mover un módulo dentro de una aplicación.
Tus datos están muy conectados. Si casi todo depende de transacciones entre las mismas tablas, separarlas crea más problemas de consistencia que beneficios.
No hay base operativa. Sin despliegue automatizado, monitoreo y alertas, cada servicio nuevo es una fuente de fallos sin supervisión.
El escalado es uniforme. Si todo el sistema crece al mismo ritmo, escalar una sola aplicación es más barato.

Un caso muy citado es el de Prime Video. En 2023, el equipo de su servicio de monitoreo de audio y video publicó que, al pasar de una arquitectura distribuida a una sola aplicación, redujo el costo de infraestructura en más de 90%. Conviene leerlo con matices: fue un componente específico y no toda la plataforma, y el propio equipo concluyó que la decisión debe tomarse caso por caso.

Sam Newman, autor de Building Microservices, ha insistido en que los microservicios no deberían ser la opción por defecto.

El camino intermedio: el monolito modular

Entre una aplicación desordenada y veinte servicios hay un punto medio: el monolito modular. Es una sola aplicación, pero dividida por dentro en módulos con límites claros, cada uno con su responsabilidad y con reglas sobre quién puede llamar a quién. Se despliega junta, pero queda lista para separarse el día que haga falta.

Es la idea detrás del enfoque “primero el monolito” que describe Martin Fowler: aprender el dominio con una aplicación sencilla y dividir cuando el dolor sea real. Y cuando ese día llegue, no hace falta reescribir todo. El patrón de la higuera estranguladora (strangler fig) consiste en extraer servicios uno por uno, redirigiendo poco a poco el tráfico mientras el resto sigue funcionando.

Antes de dividir, pregúntate

¿Hay equipos que se bloquean entre sí al desplegar?
¿Una parte concreta necesita escalar distinto del resto?
¿Puedo nombrar con claridad el límite del servicio y qué datos le pertenecen?
¿Tengo despliegue automatizado, monitoreo y trazas?
¿El beneficio justifica el costo operativo que voy a asumir?

Si la mayoría de las respuestas es sí, probablemente es hora de dividir. Si no, un monolito bien ordenado es una decisión de ingeniería acertada, no un atraso. Como con la piedra, primero se desbasta la forma general y solo después se tallan los detalles.