Micro­servi­cios o monolito: guía de decisión para equipos y productos

Empiece con un monolito modular y extraiga partes concretas como microservicios solo cuando haya un motivo concreto: varios equipos que se bloquean en las versiones, un área con una necesidad de escalado o disponibilidad claramente distinta o un componente técnicamente diferente. Los microservicios no son un sello de calidad, sino una herramienta con costes de operación apreciables.

Las grandes plataformas muestran lo que pueden lograr los servicios distribuidos. Pero lo que funciona en grandes grupos con cientos de desarrolladores suele ser innecesariamente complejo y caro de operar para un producto de una pyme. Este artículo ofrece una guía de decisión sólida: una comparación, criterios, errores habituales y un camino para pasar paso a paso de un monolito a servicios.

Dos arqui­tec­turas de un vistazo

Un monolito es una aplicación que se construye y entrega como un todo. Todas las funciones, como la gestión de usuarios, los pedidos y la facturación, se ejecutan en un único proceso y suelen compartir una base de datos. Con los microservicios, la aplicación se divide en servicios independientes. Cada servicio es responsable de un área funcional, a menudo tiene su propio almacenamiento de datos y se publica de forma independiente. La comunicación se realiza mediante interfaces o mensajes.

Entre ambos se sitúa el monolito modular: una aplicación que se opera como una unidad, pero que internamente se divide en módulos claramente delimitados. El siguiente resumen lo compara con los microservicios.

Criterio	Monolito modular	Microservicios
Despliegue	una unidad, una compilación, un rollback	pipeline y versión propias por servicio; coordinación en los cambios transversales
Consistencia de datos	transacciones en una sola base de datos	datos distribuidos; conciliación mediante eventos, sagas y consistencia eventual
Escalado	toda la aplicación en horizontal; las partes no por separado	servicios individuales escalables de forma independiente
Búsqueda de errores	un stack, un registro, un depurador	se necesita trazabilidad distribuida entre varios servicios
Autonomía de los equipos	limitada: código y versión compartidos	alta, siempre que los límites funcionales sean estables
Esfuerzo de operación	bajo a medio	alto: más infraestructura, red, monitorización y seguridad por servicio
Desarrollo local	sencillo	más laborioso: varios servicios, datos de prueba, mocks
Adecuado para	un equipo o pocos equipos, productos en construcción	varios equipos independientes, requisitos muy distintos por área

El monolito no es ninguna vergüenza

Un monolito claramente estructurado, con límites de módulo limpios, es para muchos productos la forma inicial más rentable. Hay motivos de peso:

• Despliegues sencillos: una compilación, una entrega, un rollback.
• Transacciones trazables: los cambios en una base de datos siguen siendo consistentes sin coordinación distribuida.
• Análisis de errores centrado: registros, métricas y depuración se concentran en un único stack.
• Menor esfuerzo de operación: menos infraestructura, menos red, menos piezas móviles.

La palabra “modular” es importante. Un monolito sin estructura interna se convierte con el tiempo en una maraña difícil de mantener. Incluso grandes empresas tecnológicas han descrito públicamente que volvieron a unificar algunos servicios porque el esfuerzo de operación superaba el beneficio; una señal de que no es cuestión de creencias, sino de sopesar ventajas e inconvenientes.

Cómo mantener modular un monolito

• Dividir los módulos por dominios funcionales, como usuarios, pedidos y facturación, y no por capas técnicas
• Permitir el acceso a un módulo solo a través de su interfaz pública definida
• Separar tablas o esquemas por módulo y no escribir consultas que crucen los límites de los módulos
• Pruebas de arquitectura en el pipeline que detecten dependencias prohibidas, por ejemplo con ArchUnit, Deptrac o dependency-cruiser
• Representar los efectos secundarios entre módulos mediante eventos internos en lugar de llamadas directas

Cuándo tienen sentido los micro­servi­cios

Los servicios muestran sus ventajas cuando la organización y los requisitos lo exigen. La arquitectura de software suele reflejar la estructura de comunicación de la organización (ley de Conway). Cuando varios equipos trabajan sobre una misma base de código y deben coordinarse constantemente, dividirla puede aliviar la situación. Señales típicas:

• Varios equipos deben desarrollar y publicar de forma independiente.
• Las áreas tienen ciclos de publicación muy distintos, por ejemplo un módulo de precios que se ajusta constantemente y un frontend de CMS que cambia poco.
• Funciones concretas deben escalar mucho más que el resto.
• Un componente intensivo en cálculo necesita otro lenguaje de programación o entorno de ejecución.
• Los dominios tienen requisitos distintos de disponibilidad y nivel de servicio.

Los costes de los sistemas distribuidos

Los microservicios no son gratis. Las transacciones distribuidas requieren patrones como las sagas o aceptar la consistencia eventual, y los mensajes deben procesarse de forma idempotente. Las llamadas de red traen latencia y nuevas fuentes de error. La monitorización, la trazabilidad, el descubrimiento de servicios y la automatización de despliegues pasan a ser obligatorios. Cada interfaz entre servicios necesita un contrato estable y versionado; cómo lograrlo se explica en el artículo API REST con OpenAPI. El desarrollo y las pruebas locales también se complican cuando varias piezas deben ejecutarse para una sola prueba. Sin una práctica DevOps madura surge enseguida un “monolito distribuido”: servicios que solo pueden modificarse y publicarse juntos, con los inconvenientes de ambos mundos.

Una regla práctica: antes de dividir en servicios, debería poder compilar, probar, monitorizar y revertir un monolito de forma automatizada. Si ahí no lo consigue, en un entorno distribuido no será más fácil.

Ayuda a la decisión en cinco preguntas

1. Estructura de los equipos: ¿hay varios equipos que se bloquean mutuamente en las versiones?
2. Escalado: ¿debe una parte del sistema escalar de forma independiente y mucho más?
3. Niveles de servicio: ¿tienen los dominios requisitos distintos de disponibilidad?
4. Operación: ¿dispone de las competencias y herramientas para sistemas distribuidos?
5. Límites funcionales: ¿son los dominios lo bastante estables como para separarlos de forma duradera?

Si la respuesta a las tres primeras preguntas es mayoritariamente “no”, un monolito modular suele ser la mejor opción. La quinta pregunta es el freno para las decisiones precipitadas: quien aún no conoce los límites funcionales los dividirá mal sin remedio, y los servicios mal divididos son más caros de corregir que los módulos de un monolito.

Tres errores habituales

“Los micro­servi­cios escalan mejor de forma automática”

La escalabilidad nace de una arquitectura limpia, de la caché y de un almacenamiento de datos adecuado, no solo de dividir en servicios. Un monolito bien construido también puede escalarse en horizontal con varias instancias tras un balanceador de carga. Cómo encontrar los cuellos de botella antes de cambiar la arquitectura se explica en Escalado en la nube para plataformas.

“Con servicios iremos más rápido”

Eso solo es cierto si los equipos pueden trabajar realmente de forma independiente. Si para cada función nueva hay que modificar tres servicios y publicarlos de forma coordinada, la velocidad baja en lugar de subir.

“Un monolito nunca se vuelve a separar”

Con límites de módulo claros y el procedimiento adecuado, es perfectamente posible. Lo decisivo es cuidar la estructura interna desde el principio y no sacrificarla a la presión de los plazos.

Del monolito a los servicios: el patrón Strangler

Cuando crece la necesidad, un módulo puede extraerse de forma deliberada como servicio. Este procedimiento gradual, a menudo llamado patrón Strangler, reduce mucho el riesgo, porque el sistema existente sigue funcionando mientras se sustituyen partes concretas. En la práctica ha dado buen resultado este orden:

1. Elegir un candidato: un área con necesidades propias de escalado, publicación o disponibilidad y datos claramente delimitados, como el procesamiento de imágenes, un servicio de importación o la sincronización para una app móvil.
2. Definir la interfaz: fijar un contrato de API o eventos y encapsular primero el módulo dentro del monolito detrás de esa interfaz.
3. Separar los datos: tablas o base de datos propias para el servicio y una sincronización planificada con cuidado. Suele ser el paso más laborioso.
4. Redirigir el tráfico poco a poco: mediante un proxy o un feature flag, operando primero en paralelo y comparando resultados.
5. Eliminar el código antiguo: solo cuando el servicio funciona de forma estable, borrar la parte original del monolito.

Cómo decidir qué abordar primero en sistemas existentes depende también de la carga heredada. Un método de evaluación se muestra en el artículo Priorizar la deuda técnica.

Ejemplos prácticos y lista de comprobación

Dos escenarios de pymes

Ejemplo 1: portal de clientes. Supongamos que un proveedor de servicios crea un portal con gestión de usuarios, datos de pedidos, documentos, facturación e interfaces con sistemas de terceros. Un equipo pequeño lo desarrolla como monolito modular con límites de módulo claros. Un año después se añade una app móvil con función sin conexión. Su sincronización genera otros picos de carga y cambia con más frecuencia que el resto. Ahora compensa un servicio de sincronización propio; el resto del portal no cambia.

Ejemplo 2: software sectorial crecido con los años. Tres equipos trabajan en un monolito, las versiones solo se publican de forma conjunta y exigen una coordinación laboriosa. Aquí la solución no empieza con servicios, sino con límites de módulo y pruebas de arquitectura en el código existente. Solo cuando un área, por ejemplo el cálculo de precios, está bien separada y necesita su propio ritmo de publicación, se extrae con el patrón Strangler.

Lista de comprobación antes de decidir

• Los dominios funcionales y sus límites están descritos.
• La estructura de equipos y de publicaciones de los próximos años es previsible.
• Los requisitos de escalado y disponibilidad se conocen por área.
• El monolito puede compilarse, probarse y revertirse de forma automatizada.
• La capacidad operativa para monitorización, trazabilidad y automatización existe o está prevista.
• El coste total de desarrollo y operación está estimado a grandes rasgos para ambas variantes.

Cómo le ayuda Nano Concepts

Para aplicaciones nuevas de pymes, por ejemplo portales con gestión de usuarios, mantenimiento de datos e interfaces con sistemas de terceros, recomendamos por lo general el monolito modular como punto de partida. Solo cuando un área tiene demostrablemente otros requisitos compensa un servicio independiente. Le apoyamos en la decisión de arquitectura dentro de la consultoría tecnológica, realizamos aplicaciones nuevas en el desarrollo de software y llevamos paso a paso los sistemas existentes a una estructura sostenible con la modernización de software. En la primera consulta gratuita aclaramos qué arquitectura encaja con su equipo y sus objetivos.