¿Dividir el monolito o estabilizarlo? Criterios de decisión para la modernización modular

Lunes por la mañana, 9:10: Un área funcional informa de un «pequeño ajuste» en el proceso de pedidos. TI echa un vistazo rápido al texto del ticket, parece factible. Dos horas después el ambiente es otro. La compilación tarda más de lo previsto, un job en segundo plano depende del mismo paquete de release, y al mirar la base de datos queda claro: este cambio afecta a más tablas y triggers de lo pensado. A más tardar ahora surge la pregunta que ocupa con regularidad a muchos equipos: ¿descomponer el monolito o estabilizarlo?

Quien responda de forma reflexiva «¡Microservices!» suele pasar por alto el núcleo: no se trata de una etiqueta arquitectónica, sino de la capacidad de entrega y la fiabilidad operativa. Esta guía práctica conduce por una evaluación pragmática, muestra criterios de decisión para la modernización modular y describe pasos aplicables. Además incluye patrones de fallo típicos y puntos claros de interrupción y de escalado – para que la modernización no se convierta en un proyecto interminable sin efecto medible.

Descomponer el monolito o estabilizarlo: primero el síntoma, luego la arquitectura

«El monolito tiene la culpa» suena contundente, pero rara vez es lo bastante preciso para decidir. Un monolito (una aplicación como artefacto de despliegue común) puede funcionar con mucha fiabilidad —o provocar fricción permanente. Igual ocurre al contrario: los microservicios (muchos servicios pequeños desplegables por separado) pueden reducir los tiempos de entrega, pero implican inevitablemente más tareas operativas.

Martin Fowler sitúa esta realidad con mesura: Microservices son ante todo otro Operations-Footprint — es decir, otra carga operativa con más componentes, más despliegues, más fuentes de error y mayor necesidad de automatización.^[Fuente] El matiz de esta afirmación: no sustituye un análisis de su sistema. La conclusión práctica, sin embargo, es clara: quien proclame „Microservices“ como objetivo antes de que el cuello de botella esté descrito con precisión, moderniza con rapidez en el lugar equivocado.

Criterios de decisión: cuándo descomponer ayuda de verdad — y cuándo no

La presión por modernizar es real: aumentan los requisitos de seguridad, crecen las interfaces, cambian los equipos y el software empresarial debe seguir funcionando y evolucionando al mismo tiempo. La descomposición puede ser un paso sensato, pero solo si aborda el cuello de botella y no se limita a embellecer el diagrama de arquitectura.

Criterio 1: Madurez operativa — ¿puede su operación soportar el footprint?

Con cada unidad desplegable adicional aumenta la necesidad de una entrega y supervisión ordenadas: CI/CD (cadena automatizada de build/test/deploy), Observability (métricas, logs y traces para diagnóstico), procesos de incidentes, runbooks y responsabilidades claras. AWS lo formula como una ponderación: una segmentación más fina puede aportar ventajas en fiabilidad y escalado, pero incrementa la complejidad operativa con el número de componentes.^[Fuente] El matiz: esto es una directriz, no una garantía de éxito. La consecuencia: si hoy ya tiene dificultades para ejecutar un despliegue de forma estable, un paisaje de servicios multiplicará ese problema.

Puntos de verificación concretos que no debe soslayar:

• Capacidad de despliegue: Rollback/Backout está definido, las ventanas de mantenimiento y la comunicación están establecidas.
• Monitorización y alarmas: Las alertas están orientadas a la acción (no „todo en rojo“), las fuentes de error son acotables.
• Manejo de incidentes: Existe un ritmo para postmortems y medidas, no solo apagar incendios ad-hoc.
• Responsabilidad (ownership): ¿Quién decide sobre las interfaces, quién prioriza, quién asume operación y calidad?

Criterio 2: Desacoplamiento de cambios — ¿se bloquean mutuamente los requisitos?

La descomposición merece la pena cuando cambios independientes en el monolito se vuelven regularmente dependientes entre sí, aunque estén separados funcionalmente. Patrón típico: un área de portal necesita ajustes frecuentes, mientras que el área de facturación rara vez debe modificarse y exige gran cuidado. Si ambas siempre viajan en el mismo tren de releases, se frenan mutuamente.

Al contrario, la descomposición suele ser un autogol cuando casi todo cambio atraviesa muchas áreas (permisos, lógica de precios, reporting, limpieza de datos). Entonces se genera tráfico de interfaces en lugar de desacoplamiento — y la coordinación aumenta en vez de disminuir.

Criterio 3: Acoplamiento de datos – ¿está la complejidad en la base de datos?

Muchos sistemas están acoplados menos por el código que por los datos: tablas compartidas, triggers, flujos transaccionales y jobs por lotes. Sam Newman destaca en sus patrones de descomposición que el verdadero desafío con frecuencia es la estrategia de datos e integración – y que los proyectos Big-Bang resultan especialmente riesgosos en ese contexto.^[Fuente]

Conclusión práctica para la operación: si varios componentes escriben en las mismas tablas sin reglas, surgen efectos secundarios que es difícil revertir de forma limpia. La modernización modular requiere por tanto decisiones tempranas sobre la soberanía de los datos, la consistencia y el desacoplamiento del reporting.

Criterio 4: Estabilidad y valor funcional – ¿qué debe conservarse?

En soluciones empresariales digitales maduradas a lo largo del tiempo suele existir mucha lógica de dominio correctamente implementada: casos especiales, reglas comerciales, excepciones en procesos, depuraciones de datos heredadas históricamente. Eso no es «basura legacy», sino a menudo la razón por la que el negocio funciona. La modernización es económicamente viable si no descarta ese valor de forma imprudente – y al mismo tiempo identifica las áreas que hacen que la operación y la evolución sean desproporcionadamente costosas.

Elegir: tres modelos objetivo que funcionan en las empresas

Entre «todo se queda» y «todo pasa a microservicios» existen modelos objetivo prácticos que hacen la modernización planificable. AWS Prescriptive Guidance recomienda explícitamente verificar, antes de la descomposición, qué partes deberían descomponerse y favorecer enfoques incrementales.^[Fuente]

Guía práctica: de la evaluación a la implementación (con puntos Stop/Go)

1) Hacer visibles los límites del sistema – lo bastante pequeño para ser utilizado

No necesita una documentación de sistema de 80 páginas para decidir. Lo útil es un mapa compacto: procesos principales, interfaces críticas (p. ej. portales, EDI, exportaciones de ficheros, REST-APIs), trabajos por lotes, así como puntos con alta propensión a fallos. Objetivo: poder tomar decisiones, no archivar conocimiento.

Ha demostrado su valía una perspectiva que reúna operaciones y negocio: «¿Qué trayecto de proceso es crítico para el negocio y de qué depende técnicamente?» Entonces queda rápido visible dónde una extracción sería arriesgada — y dónde realmente podría aliviar la carga.

2) Definir métricas de referencia – si no, queda en cuestión de fe

Modernizar sin una línea base es como optimizar el rendimiento sin medición. Son decisivas las métricas que reflejen tanto la entrega como la operación: frecuencia de despliegue, Lead Time (desde la solicitud hasta producción), Change Failure Rate (fallos tras cambios), MTTR (Mean Time to Recovery) y clases de incidentes recurrentes. Las métricas no tienen que ser académicamente perfectas, pero deben recogerse de forma consistente para que un Stop/Go sea posible.

3) Cortar candidatos – por dominio, no por capas técnicas

Un inicio erróneo frecuente es el corte por capas (“UI-Service”, “DB-Service”). Eso genera dependencias nuevas en lugar de reducirlas. El corte por dominio significa: un módulo se responsabiliza de un área funcional incluyendo reglas y datos. Para los equipos suele ser más tangible que una delimitación puramente técnica.

Si no pueden nombrar los límites funcionales, eso no es motivo para cortar más rápido, sino una señal de primero estabilizar y modularizar dentro del monolito: aclarar términos, entender flujos de datos, identificar funciones transversales.

4) Strangler en lugar de Big Bang – redirigir de forma controlada, apagar de forma consecuente

Cuando la disponibilidad cuenta y hay que controlar riesgos, el patrón Strangler-Fig es una vía con peso: las funciones se sustituyen gradualmente junto al sistema existente; el tráfico se redirige de forma controlada hasta que se apaguen las rutas antiguas.^[Fuente]

Importante es la disciplina tras el patrón: decisiones claras de enrutamiento, compatibilidad en datos e interfaces, monitorización a través de ambas vías — y un verdadero “hecho” cuando se elimina la ruta antigua. Si no, el funcionamiento en paralelo se convierte en un estado permanente.

5) Definir desde temprano la estrategia de datos e informes

En la práctica, la modernización se decide a menudo por dos preguntas: ¿quién «posee» qué datos y cómo se elaboran los informes? Si los informes acceden directamente a tablas operativas, bloquean los cambios. Si varios componentes «comparten» datos sin reglas, surgen inconsistencias.

Planifique por tanto explícitamente:

• Soberanía de datos: ¿qué módulo es líder para qué entidad (cliente, pedido, factura …)?
• Requisitos de consistencia: ¿dónde se necesita consistencia fuerte y dónde basta la consistencia eventual?
• Desacoplamiento de informes: ¿cómo se suministran los análisis sin endurecer los modelos operativos?

6) Definir seguridad y operación por módulo – no añadirlos después de forma improvisada

Con cada nueva componente aumenta la superficie de ataque: comunicación servicio a servicio, secrets, permisos, registros de auditoría. Aclare pronto cómo interactúan autenticación (p. ej., centralizada mediante SSO) y autorización (basada en roles/permisos por dominio). En el día a día también cuenta: los logs deben ser útiles para el diagnóstico, pero no pueden vulnerar las normas de protección de datos y de conservación. Estos puntos deben incluirse en runbooks y en la documentación de operación – no solo en las diapositivas de arquitectura.

Lista de verificación de 8 pasos para una decisión Go/No-Go sólida

1. Nombrar el cuello de botella: ¿Qué debe mejorar exactamente (duración de las releases, estabilidad, escalado, desarrollo paralelo)?
2. Medir la línea base: ¿Qué métricas reflejan el estado actual (Lead Time, Change Failure Rate, MTTR etc.)?
3. Verificar la operatividad: CI/CD, monitorización, alertas, runbooks, procesos de incidentes, responsabilidad (ownership).
4. Esbozar el corte de dominio: ¿Dónde están los límites naturales de dominio? ¿Qué temas son transversales?
5. Diseñar la estrategia de datos: soberanía de datos, consistencia, informes, rutas de migración.
6. Inventariar dependencias: tareas, interfaces, exportaciones de archivos, grupos de usuarios, permisos.
7. Planificar el slice: un paquete pequeño y entregable que incluya rollback y objetivos de monitorización.
8. Establecer criterios Stop/Go: ¿Qué señales detienen la descomposición o exigen un paso de estabilización?

Patrones de error típicos – así se manifiestan en operación

Error 1: Más componentes, pero sin responsabilidad de extremo a extremo

Si nadie es responsable de extremo a extremo (priorización, calidad, operación), el desacoplamiento se convierte en un problema de coordinación. En caso de incidentes esto conduce a largas rondas, decisiones poco claras y al reflejo de volver a desplegar «todo junto». Contramedida: un equipo responsable claro por módulo, entregas definidas y un registro de decisiones (Decision-Log) para interfaces y soberanía de datos.

Error 2: Datos compartidos sin reglas

El anti‑patrón es conocido: los servicios están separados pero siguen escribiendo en las mismas tablas o usan accesos directos a la base de datos a través de dominios. Eso rompe el aislamiento, complica las auditorías y hace que los rollbacks no sean fiables. Contramedida: accesos a datos mediante interfaces definidas, responsabilidad clara sobre los datos y —donde sea necesario— sincronización controlada (p. ej., eventos).

Error 3: Se planifica la latencia de red y las cascadas de fallos, pero no se prueban

Lo que en el monolito era una llamada in‑process, en arquitecturas distribuidas se convierte en una llamada de red con timeouts, reintentos y potenciales cascadas. Sin timeouts bien definidos, correlación (Request‑IDs) y pruebas de extremo a extremo realistas, el análisis de fallos se complica notablemente. Contramedida: SLOs claros (objetivos de servicio medibles), timeouts definidos, correlación de trazas y pruebas de carga a lo largo de rutas de proceso completas.

Error 4: División según el organigrama en lugar de según la lógica de dominio

Si los servicios reflejan principalmente los límites de los equipos, pero funcionalmente atraviesan procesos, el acoplamiento persiste —solo en otro nivel. Contramedida: corte por dominio, aunque inicialmente genere fricción. Si eso no es posible organizativamente, un monolito modular suele ser un mejor paso intermedio.

Puntos de parada y de escalado: cuándo estabilizar se convierte en la mejor decisión

Un proyecto de modernización necesita reglas de detención; de lo contrario consume presupuesto y atención. Estas señales son motivos contundentes para cambiar de estrategia de forma deliberada:

• Sobrecarga operativa: avalancha de alertas, MTTR creciente, guardias on-call imposibles de cubrir.
• Sin mejora medible: Lead Time, Change Failure Rate o la estabilidad no muestran mejoras perceptibles.
• La complejidad de las interfaces se dispara: versionado sin aclarar, proliferan Breaking Changes, depurar se convierte en un juego de adivinanzas.
• Conflictos de datos: inconsistencias, verdades duplicadas, desviaciones en informes difíciles de explicar.
• Ownership sigue sin estar claro: las decisiones se retrasan, nadie asume la responsabilidad del funcionamiento y la evolución.

Escalar no significa „volver a lo anterior“, sino: priorizar la estabilización. Las medidas típicas son: aplicar pruebas de regresión para los procesos núcleo, mejorar la observabilidad, consolidar los accesos a datos, afinar los límites de los módulos en el monolito —y solo después volver a evaluar si una extracción aporta realmente beneficio.

Qué significa concretamente „estabilizar“ — y por qué suele actuar más rápido

La estabilización no es una limpieza cosmética. En operación se traduce en menos sorpresas y despliegues planificables. Palancas concretas que los equipos notan de inmediato:

• Mecánica de despliegues: compilación reproducible, entornos coherentes, camino de rollback probado.
• Transparencia: estándares de logging, clasificación de errores, correlación de requests a lo largo de las trayectorias de proceso.
• Enfoque en pruebas: regresión de extremo a extremo para los flujos núcleo (no solo pruebas aisladas).
• Límites de módulo en el monolito: APIs internas definidas, acceso a datos disciplinado, responsabilidades claras.
• Higiene de datos: fuentes maestras únicas, efectos secundarios de jobs documentados, lógica de casos especiales reducida.

El resultado suele ser un monolito modular resistente: el software sigue siendo operable como unidad, pero con una separación interna más clara. Con ello los equipos recuperan gran parte de lo que esperaban obtener con la descomposición —sin multiplicar de inmediato la complejidad operativa.

Última pregunta de comprobación antes de decidir

Si descompusiera hoy: ¿puede decir mañana por la mañana durante un incidente rápidamente qué parte es responsable, quién reacciona, qué métrica evidencia el fallo y cómo revertir? Si esta pregunta permanece incómodamente sin respuesta, la decisión suele no ser „más arquitectura“, sino „más seguridad operativa“.

Si desea evaluar su punto de partida de forma estructurada y definir un camino de modernización con puntos de parada/avance claros, puede contactarnos de forma puntual y dirigida para ello:

Para este tema también son importantes la modernización de legados y el patrón Strangler Fig. El artículo contextualiza claramente estos aspectos y muestra en qué hay que centrarse en la práctica.

Discutir un proyecto o iniciativa de modernización con Net-Base.