Ya conocemos qué son los microservicios, qué ventajas y costes traen y cómo se comparan con el monolito. Falta la pregunta más importante y la que menos se responde con rigor: ¿cuándo conviene adoptarlos? Demasiadas organizaciones toman esta decisión por moda, por presión de un proveedor o porque "lo hace Netflix", y acaban pagando la complejidad de un sistema distribuido sin obtener ninguna de sus ventajas.

Esta lección ofrece criterios concretos y verificables para decidir. Veremos los factores que de verdad inclinan la balanza (organización, madurez DevOps, conocimiento del dominio, escalado, disponibilidad, velocidad de entrega), el enfoque "monolith first", las señales que indican que un monolito pide ser dividido y las que indican lo contrario, los prerrequisitos mínimos sin los cuales no se debería empezar, una lista de comprobación de decisión, los costes ocultos que nadie pone en la presentación y los antipatrones más habituales. Los ejercicios te pedirán decidir sobre escenarios ficticios distintos, incluido el propio TechCorp. No entraremos en cómo se ejecuta una migración (lección 08-01) ni en la técnica de descomposición (lección 02-02): aquí se trata de decidir si, no cómo.

1. Los criterios que importan
2. El enfoque "monolith first"
3. Señales de que un monolito pide ser dividido
4. Señales de que NO conviene
5. Prerrequisitos mínimos
6. Lista de comprobación de decisión
7. Costes ocultos
8. Antipatrones
9. Errores comunes y consejos
10. Ejercicios
11. Conclusión

En 1967, Melvin Conway observó que las organizaciones diseñan sistemas que reflejan su estructura de comunicación. Si tienes tres equipos, tendrás tres subsistemas; si los equipos se comunican mal, las interfaces entre sus subsistemas serán malas.

Aplicado a nuestra decisión:

• Un único equipo pequeño (digamos, menos de 8-10 personas) no obtiene casi nada de la autonomía entre equipos que ofrecen los microservicios, porque no hay nadie de quien independizarse. Sí obtiene, en cambio, todo el coste operativo.
• Varios equipos que se estorban trabajando sobre el mismo código y el mismo despliegue son la señal más clara de que unos límites de servicio alineados con esos equipos ayudarían.
• La estructura importa tanto como el tamaño: si los equipos están organizados por capa técnica (front-end, back-end, base de datos, sistemas), los microservicios encajan mal, porque cada servicio necesitaría a todos los equipos. Si están organizados por capacidad de negocio (equipo de pedidos, equipo de catálogo), encajan de forma natural.

Hay incluso una estrategia llamada maniobra inversa de Conway: reorganizar los equipos primero, en torno a las capacidades de negocio deseadas, para que la arquitectura resultante siga esa forma. En TechCorp, hoy hay un equipo de back-end único; parte del camino consistirá en que el equipo de Luis sea de verdad "el equipo de Pedidos".

Los microservicios multiplican el número de cosas que hay que construir, probar, desplegar y vigilar. Si hoy el despliegue del monolito es manual, si no hay pruebas automatizadas fiables o si nadie sabe qué pasa en producción hasta que un cliente se queja, dividir el sistema convertirá un problema en seis. Pregúntate: ¿podemos desplegar a producción con un clic y con confianza? ¿Tenemos métricas y logs centralizados? Si la respuesta es no, ese es el primer trabajo, no la división.

Dividir un sistema en servicios significa fijar límites entre capacidades de negocio. Esos límites son caros de mover después: cambiar de sitio una responsabilidad entre dos servicios implica renegociar contratos, migrar datos y coordinar despliegues.

• Si el dominio es estable y bien conocido (una tienda online que lleva años vendiendo, con áreas claras como catálogo, pedidos y pagos), los límites se pueden trazar con confianza.
• Si el dominio es exploratorio (una startup que todavía cambia de modelo de negocio cada trimestre), cualquier división será prematura y habrá que rehacerla. En un monolito, mover una responsabilidad de un módulo a otro es cambiar unos ficheros; en microservicios, es un proyecto.

Si todas las partes del sistema crecen en carga de forma parecida, replicar el monolito funciona bien. El escalado selectivo solo aporta valor cuando hay partes con perfiles de carga muy distintos (en TechCorp, el catálogo recibe cien veces más lecturas que escrituras recibe pagos) o con necesidades de recursos muy distintas (un servicio que genera informes pesados junto a otro que atiende peticiones ligeras).

Si un fallo en una parte secundaria del sistema (los correos, las estadísticas) no puede permitirse tumbar la parte crítica (cobrar), el aislamiento que ofrecen los servicios separados es valioso. Si toda la aplicación tiene los mismos requisitos y una caída de una hora es asumible, ese argumento pesa poco. Ojo: los microservicios ofrecen la posibilidad de aislar fallos, no la garantía; hay que diseñarla.

¿Está el ritmo de entrega limitado por la arquitectura? Si los equipos esperan al despliegue semanal, si un cambio pequeño requiere probar todo, si las colas de revisión se atascan por conflictos entre equipos, la arquitectura está frenando la entrega. Si el ritmo está limitado por otras cosas (falta de personas, requisitos poco claros, decisiones lentas), los microservicios no lo acelerarán.

Martin Fowler y otros autores defienden desde hace años una postura muy pragmática: empieza con un monolito, incluso si crees que acabarás en microservicios. Los argumentos:

1. No conoces el dominio lo suficiente al principio. Los límites que traces el primer día serán incorrectos, y en un monolito corregirlos es barato.
2. El coste inicial de los microservicios retrasa el valor. Un producto nuevo necesita llegar al mercado, no un clúster de Kubernetes.
3. Un monolito modular ya bien organizado se puede dividir después con relativa facilidad, extrayendo módulos que ya tienen límites claros.
4. Casi todos los casos de éxito de microservicios empezaron como monolitos que crecieron hasta que dolieron. Los intentos de empezar directamente en microservicios tienen un historial mucho peor.

La forma práctica de aplicarlo: construye un monolito modular desde el principio (módulos con API interna, cada uno dueño de sus tablas), automatiza el despliegue y la observabilidad, y extrae un servicio solo cuando un módulo concreto tenga una razón concreta (escalado, equipo propio, tecnología distinta, aislamiento). Es exactamente el camino que recorrerá TechCorp en el curso: partiendo de un monolito que ya duele, no de una hoja en blanco.

Estas señales, sobre todo si aparecen varias a la vez, indican que el monolito ha llegado a un punto en que su coste supera al de los microservicios:

• Despliegues lentos, poco frecuentes y temidos. El despliegue se ha convertido en un evento (el "viernes de despliegue"), requiere ventanas de mantenimiento y con frecuencia se revierte.
• Equipos que se pisan. Conflictos constantes en el código, esperas para fusionar cambios, un equipo bloqueado por otro.
• Escalado ineficiente y caro. Se replica toda la aplicación por culpa de una parte; la factura de infraestructura crece más deprisa que el negocio.
• Fallos que se propagan. Un error en un módulo secundario tumba funciones críticas.
• Suites de pruebas de decenas de minutos que todo el mundo intenta saltarse.
• Tiempo de incorporación de nuevos desarrolladores muy largo porque nadie entiende el sistema entero.
• Necesidad tecnológica real en una parte (por ejemplo, un modelo de datos que en la base de datos actual es un martirio).

TechCorp presenta casi todas estas señales, como veremos en la lección 01-05.

Con la misma claridad, situaciones en las que dividir sería un error:

• Un único equipo pequeño que trabaja bien con el monolito.
• Un producto que aún busca su modelo de negocio; el dominio cambia demasiado.
• Sin automatización: despliegues manuales, sin pruebas fiables, sin monitorización. Primero eso.
• Carga baja o uniforme: un servidor modesto atiende todo con holgura.
• La motivación es la moda, un currículum o una presentación de un proveedor, no un problema concreto.
• El monolito duele por mala calidad de código, no por acoplamiento de despliegue. La solución es refactorizar hacia un monolito modular; distribuir el desorden solo lo empeora.
• La organización no está dispuesta a cambiar: equipos por capas, un departamento de operaciones que centraliza todo, decisiones muy jerárquicas. La arquitectura chocará con la estructura y perderá.

Antes de extraer el primer servicio, deberían estar razonablemente resueltos estos cuatro pilares. Sin ellos, cada servicio nuevo añade riesgo en lugar de restarlo.

Un buen consejo: construye estos pilares sobre el monolito antes de dividirlo. Un monolito con CI/CD, contenedores y buena observabilidad ya es mucho mejor sistema, y si finalmente se divide, la división será infinitamente más segura.

Usa esta lista como matriz. No es una fórmula matemática, sino una forma de obligarte a mirar todos los factores. Cuenta las respuestas afirmativas de cada bloque.

Bloque A. Razones para dividir (cuantas más, más sentido tiene)

• [ ] Hay dos o más equipos que se estorban trabajando en el mismo código y despliegue.
• [ ] Los equipos están (o pueden estar) organizados por capacidad de negocio.
• [ ] Hay partes del sistema con necesidades de escalado claramente distintas.
• [ ] Un fallo en partes secundarias ha tumbado (o puede tumbar) funciones críticas.
• [ ] Los despliegues son lentos, poco frecuentes o temidos por el acoplamiento.
• [ ] El dominio es estable y sus áreas se pueden nombrar sin discusión.
• [ ] Hay una necesidad tecnológica real en alguna parte concreta.

Bloque B. Capacidad para hacerlo (todas deberían ser sí, o estar en camino)

• [ ] Existe CI/CD fiable.
• [ ] Se sabe construir y operar contenedores.
• [ ] Hay logs y métricas centralizados y se está dispuesto a añadir trazas.
• [ ] Los equipos pueden desplegar sin autorización externa y se responsabilizan de la operación.
• [ ] Hay presupuesto y personas para operar más infraestructura (broker, gateway, orquestador, varias bases de datos).

Bloque C. Señales de alarma (una sola debería hacer parar y pensar)

• [ ] La motivación principal es la moda, un proveedor o un currículum.
• [ ] El equipo total es muy pequeño (menos de unas 8-10 personas) y no hay previsión de crecer.
• [ ] El modelo de negocio o el dominio cambian con frecuencia.
• [ ] El dolor actual se debe a mala calidad de código, no a acoplamiento de despliegue.

Interpretación orientativa:

Hay costes que raramente aparecen en la propuesta inicial y siempre aparecen en la factura:

• Infraestructura de apoyo que el monolito no necesitaba: broker de mensajes, gateway, orquestador, registro de contenedores, herramientas de observabilidad, gestión de secretos. Cada una hay que instalarla, actualizarla, protegerla y saber operarla.
• Duplicación: código de utilidad, configuración, pipelines, paneles de monitorización, políticas de seguridad... multiplicados por el número de servicios.
• Coordinación de contratos: tiempo dedicado a acordar, documentar y versionar APIs y eventos, y a mantener la compatibilidad hacia atrás.
• Entornos de desarrollo y pruebas más complejos: levantar "toda la tienda" en local pasa de npm start a orquestar una docena de contenedores.
• Formación: el equipo tiene que aprender a razonar sobre sistemas distribuidos (idempotencia, reintentos, consistencia eventual), y esa curva es real.
• Guardias y soporte: más servicios significa más alertas y más cosas que pueden despertar a alguien a las tres de la mañana.
• Coste de deshacer: si la división resulta un error, volver a consolidar servicios es tan costoso como dividirlos.

Se adopta la arquitectura porque es lo que hace la competencia, porque queda bien en una oferta de empleo o porque un proveedor de nube la recomienda. No hay un problema concreto que resolver. Resultado típico: un sistema más complejo, más caro y más lento de desarrollar que el monolito que sustituyó, sin ninguna ventaja tangible.

Servicios tan pequeños que su alcance no es una capacidad de negocio sino una función técnica ("servicio de validación de códigos postales", "servicio de formateo de fechas"). El coste de comunicación y operación supera con mucho el valor de la separación. Regla práctica: si un servicio no puede hacer nada útil sin llamar a otros tres, probablemente es demasiado pequeño.

Ya lo hemos nombrado en lecciones anteriores porque es el antipatrón más dañino: varios procesos que comparten base de datos, que deben desplegarse juntos porque sus contratos cambian de forma acoplada, o que dependen síncronamente unos de otros de tal forma que ninguno funciona si otro cae. Tiene todo el coste de la red y ninguna de las ventajas de la autonomía. Cómo detectarlo:

• Servicio de entidad: un servicio por tabla (servicio-cliente, servicio-direccion, servicio-telefono) en lugar de por capacidad de negocio.
• Capa de servicios compartidos de la que dependen todos ("servicio de utilidades comunes"), que reintroduce el acoplamiento central.
• Big bang: reescribir todo el monolito en microservicios de golpe, en un proyecto de dos años, sin entregar nada por el camino. Se estudia la alternativa incremental en la lección 08-01.

• Decidir sin datos. "El monolito es lento" o "los equipos se pisan" deberían poder cuantificarse: frecuencia de despliegue, tiempo de la suite de pruebas, número de reversiones, coste de infraestructura por pedido. Sin números, la decisión es una opinión.
• Saltarse los prerrequisitos "porque los pondremos después". Después nunca llega, y mientras tanto se opera un sistema distribuido a ciegas.
• Dividir por capas o por tablas. Los límites deben seguir capacidades de negocio; lo contrario produce nanoservicios o servicios de entidad.
• Ignorar la organización. Si los equipos no se reorganizan en torno a las capacidades, la Ley de Conway devolverá el sistema a la forma de la organización, con la complejidad añadida.
• Tratar la decisión como definitiva y global. No es "todo o nada": se puede extraer un servicio, comprobar si compensa y decidir el siguiente paso con lo aprendido.
• Consejo: rellena la lista de comprobación del apartado 6 con al menos dos personas más y compara respuestas. Las discrepancias son la conversación más valiosa que puedes tener antes de decidir.

En cada escenario, aplica la lista de comprobación del apartado 6 y toma una decisión razonada: microservicios (incrementales), monolito modular, o "todavía no". Justifica con los criterios de la lección.

Un antiguo equipo de TechCorp funda una startup para vender kits de electrónica educativa. Son cuatro personas (tres desarrolladores y una persona de producto). Llevan seis meses; han cambiado dos veces el modelo de negocio (primero venta directa, luego suscripción mensual, ahora dudan si añadir marketplace). Despliegan a mano con git pull en un servidor. Reciben unos 300 pedidos al mes. El fundador técnico ha leído sobre microservicios y quiere "hacerlo bien desde el principio".

Una aseguradora tiene una plataforma monolítica en Java con doce equipos de desarrollo organizados por producto (hogar, auto, vida, salud...) trabajando sobre el mismo repositorio. Los despliegues son mensuales, requieren una ventana nocturna y un comité de cambios, y se revierten con frecuencia. La suite de pruebas tarda 90 minutos. Tienen CI, contenedores en preproducción y un equipo de plataforma que ya opera Kubernetes para otros sistemas. Los productos son estables (llevan quince años vendiéndolos). El área de tarificación consume diez veces más CPU que el resto y obliga a sobredimensionar todo. Los equipos se quejan de esperar semanas para que sus cambios lleguen a producción.

Con lo que sabes de TechCorp (monolito Node.js con una PostgreSQL, seis áreas funcionales, despliegues semanales temidos, caídas en campañas por saturación del catálogo, un equipo de back-end que empieza a organizarse por áreas con Luis al frente de Pedidos, CI básico y contenedores en pruebas pero sin orquestación en producción ni observabilidad más allá de los logs del servidor), decide qué le recomendarías a Marta y qué debería hacer antes de extraer el primer servicio.

Ejercicio 1: TechCorp Labs

• Bloque A: prácticamente ninguna casilla. Un equipo, carga mínima, sin problemas de despliegue por acoplamiento.
• Bloque B: no hay CI/CD ni observabilidad; despliegues manuales.
• Bloque C: tres señales de alarma: equipo muy pequeño, dominio exploratorio (dos pivotes en seis meses) y motivación por "hacerlo bien" sin problema concreto.
• Decisión: monolito, y ni siquiera hace falta que sea muy modular todavía. Lo que sí conviene: automatizar el despliegue (CI/CD sencillo) y añadir monitorización básica. Si en un año el negocio se estabiliza y el equipo crece, evolucionar hacia monolito modular. Empezar en microservicios aquí retrasaría el producto meses y fijaría límites de un dominio que aún no existe.

Ejercicio 2: la aseguradora

• Bloque A: doce equipos que se estorban (sí), organizados por producto (sí, por capacidad de negocio), escalado diferenciado en tarificación (sí), despliegues lentos y temidos (sí), dominio estable (sí). Cinco o seis casillas.
• Bloque B: CI sí, contenedores sí, plataforma Kubernetes operada por un equipo especializado sí. Observabilidad probablemente parcial (habría que verificar trazas). Cultura de propiedad: no del todo, hay un comité de cambios que aprueba despliegues; ese es el punto a trabajar.
• Bloque C: ninguna señal clara de alarma; el dolor viene del acoplamiento, no de la calidad del código (aunque conviene comprobarlo).
• Decisión: adoptar microservicios de forma incremental. Candidato evidente para la primera extracción: tarificación, que tiene la razón de escalado más clara y probablemente un límite de dominio nítido. En paralelo, cambiar la gobernanza para que los equipos puedan desplegar sin comité (con controles automáticos en el pipeline) y asegurar la observabilidad distribuida antes de que haya más de dos o tres servicios.

Ejercicio 3: TechCorp

• Bloque A: equipos que se pisan (sí, empieza a haber varios), organización por capacidad de negocio (en marcha), escalado diferenciado (sí, catálogo frente al resto), fallos que se propagan (sí, las campañas tumban toda la tienda), despliegues temidos (sí), dominio estable (sí, es una tienda con áreas claras). Al menos cinco casillas.
• Bloque B: CI básico (parcial), contenedores solo en pruebas (parcial), sin orquestación en producción (no), observabilidad limitada a logs (no), cultura de propiedad naciente (parcial).
• Bloque C: ninguna señal de alarma; el dolor es real y de acoplamiento.
• Decisión: sí a los microservicios, pero de forma incremental y con deberes previos. Antes de extraer el primer servicio, Marta debería: consolidar CI/CD para el monolito, llevar los contenedores a producción con un orquestador, montar observabilidad (logs centralizados, métricas y preparar trazas) y consolidar los equipos por área con responsabilidad de operación. Mientras se hace eso, modularizar el monolito para que los límites de catálogo, pedidos, etc. sean explícitos. El primer candidato razonable a extraer es el catálogo, por su razón de escalado clarísima y por ser mayoritariamente de lectura (bajo riesgo). Esta es, de hecho, la hoja de ruta que seguirá el curso, presentada en la próxima lección.

Decidir si adoptar microservicios no es una cuestión de gustos ni de tendencias, sino de contrastar problemas concretos con capacidades concretas. Los criterios que inclinan la balanza son la estructura de la organización (Ley de Conway), la madurez DevOps, la estabilidad del dominio, las necesidades de escalado y disponibilidad diferenciadas y el freno real a la velocidad de entrega. El enfoque "monolith first" recomienda empezar con un monolito modular y extraer servicios solo cuando haya una razón específica; las señales de dolor (despliegues temidos, equipos que se pisan, escalado ineficiente, fallos que se propagan) indican cuándo ha llegado ese momento, y las señales contrarias (equipo pequeño, dominio cambiante, sin automatización, motivación por moda) indican cuándo no. Los cuatro prerrequisitos (CI/CD, contenedores, observabilidad y cultura de propiedad) deberían construirse sobre el monolito antes de dividirlo, y la lista de comprobación de decisión obliga a mirar todos los factores a la vez, incluidos los costes ocultos y los antipatrones que hay que evitar (moda, nanoservicios, monolito distribuido).

Hemos aplicado estos criterios a TechCorp y la conclusión es que su caso justifica la migración, con deberes previos. En la próxima lección presentaremos ese caso con todo detalle: quién es TechCorp, cómo es su monolito hoy, qué problemas sufre, cuál es el flujo de negocio central que nos acompañará durante todo el curso, el mapa de servicios que construiremos y la hoja de ruta módulo a módulo.