En los últimos años “microservicios” se ha convertido casi en una consigna: parece que toda aplicación moderna deba dividirse en muchos servicios pequeños. Los usamos a menudo, pero no siempre: resuelven problemas reales de crecimiento y de organización, e introducen otros que tienen un coste.
Veamos qué son, qué beneficios aportan de verdad, cuánto cuestan y cuándo un monolito bien estructurado es la mejor opción. La pregunta correcta no es “¿usamos microservicios?”, sino “¿qué problema tenemos que resolver?”.
Qué son los microservicios
Una arquitectura de microservicios divide una aplicación en servicios pequeños e independientes, cada uno con una tarea concreta: gestionar los usuarios, los pagos, los documentos o las notificaciones. Cada servicio tiene su propio código, se despliega por su cuenta y se comunica con los demás mediante API ligeras (interfaces con las que un programa dialoga con otro, normalmente REST sobre HTTP) o con mensajes.
La alternativa es el monolito: una única aplicación que contiene todas las funciones y se despliega en un solo bloque. Monolito no significa código antiguo: puede ser moderno, estar bien dividido en módulos y ajustarse a su objetivo.
Los beneficios reales
- Despliegues independientes: se actualiza el servicio de pagos sin tocar el resto, con despliegues más pequeños y menos arriesgados.
- Escalar solo lo necesario: si la carga está en el catálogo, se añaden copias del catálogo, no de toda la aplicación.
- Autonomía de los equipos: cada grupo se ocupa de sus servicios y trabaja a su ritmo, siempre que respete los contratos de las API.
- Aislamiento de fallos: si un servicio secundario se detiene, el resto puede seguir funcionando, siempre que se haya diseñado para ello.
En el ERP Atac para Ernst & Young, por ejemplo, la aplicación de los procedimientos de licitación se divide en microservicios Java y Spring Boot, con Spring Cloud Gateway como entrada única y cada microservicio en un contenedor Docker en el sistema on-premise proporcionado por el cliente.
Los costes que no se ven al principio
Un sistema distribuido es más difícil de diseñar, probar y operar que una aplicación única.
- Complejidad distribuida: una llamada que antes era una función se convierte en una petición de red, que puede ser lenta, fallar o llegar dos veces.
- La red: latencia, timeouts, reintentos y seguridad entre servicios hay que gestionarlos de forma explícita.
- Consistencia de los datos: con una base de datos por servicio ya no hay una transacción única; hacen falta eventos o sagas (secuencias de pasos con acciones de compensación) y se acepta que los datos se alineen tras unos instantes.
- Observabilidad: para entender qué ocurre hacen falta logs centralizados, métricas y el rastreo de cada petición entre servicios.
- Madurez DevOps: DevOps es el conjunto de prácticas que une desarrollo y operación de la infraestructura; con muchos servicios, los pipelines automáticos de compilación y despliegue y la monitorización se vuelven imprescindibles.
Un caso conocido: en 2023 el equipo Video Quality Analysis de Prime Video (Amazon) contó en su blog técnico que reunió en un solo proceso un servicio de monitorización de vídeo nacido como conjunto de componentes distribuidos, y que así redujo los costes de infraestructura en más del 90%. No es un rechazo de los microservicios, sino un recordatorio: la arquitectura se elige según la carga real, no por moda.
Cuándo un monolito modular es la mejor opción
En muchos proyectos, sobre todo al principio, la opción más sólida es un monolito modular: una única aplicación dividida en módulos con límites claros, cada uno con sus responsabilidades y sin acceso directo a los datos de los demás. Se despliega como un solo bloque, pero ya está preparada para dividirse algún día.
Es el camino adecuado cuando el equipo es pequeño, el dominio aún cambia, la carga es previsible o faltan pipelines y monitorización maduros. Martin Fowler, en su artículo “MonolithFirst” de 2015, observaba que casi todas las historias de éxito con microservicios empezaron con un monolito que creció demasiado y luego se dividió. Y los límites entre servicios se trazan mejor cuando el producto ya existe.
Señales de que ha llegado el momento de dividir
- Despliegues bloqueados: un cambio pequeño obliga a recompilar, probar y desplegar todo, y los equipos se estorban entre sí.
- Cargas muy distintas: una parte de la aplicación recibe mucho más tráfico que las demás o necesita otros recursos.
- Equipos que crecen: varios grupos trabajan sobre el mismo código y la coordinación cuesta más que el desarrollo.
- Requisitos distintos: un componente crítico necesita más fiabilidad o más seguridad y conviene aislarlo del resto.
- Límites ya claros: los módulos tienen interfaces estables y datos propios, así que extraerlos es un trabajo de ingeniería, no un rediseño.
En estos casos conviene extraer un servicio cada vez, empezando por el beneficio más claro, en lugar de reescribirlo todo.
Los patrones que usamos en nuestros proyectos
- API gateway: una entrada única que recibe las peticiones, comprueba el acceso y las envía al servicio correcto.
- Una base de datos por servicio: cada servicio es el único dueño de sus datos y los demás solo los leen a través de sus API.
- Mensajes y colas: para las operaciones largas o no urgentes, los servicios se comunican a través de una cola, así quien envía no espera.
- Contenedores: cada servicio se empaqueta en un contenedor, un paquete estándar con el código y todo lo que necesita para ejecutarse, idéntico en desarrollo y en producción.
- Registro de servicios y despliegue automático: los servicios se encuentran entre sí sin direcciones escritas a mano y cada cambio pasa por un pipeline de CI/CD (integración y entrega continuas).
En 2VitaBCognitive para Atlantia la aplicación está formada por 6 microservicios Spring Boot con el registro de servicios Eureka, en contenedores Docker sobre Amazon ECS y desplegados con los servicios de CI/CD de AWS. En el ERP Hera para Atos los microservicios REST funcionan en Microsoft Azure, con Spring Cloud Gateway, Eureka, acceso mediante Azure Active Directory (hoy Microsoft Entra ID) e informes en Power BI.
Si estás valorando dividir una aplicación existente o cómo plantear un proyecto nuevo, partimos de tus objetivos y de la carga real, no de una arquitectura elegida de antemano. Escríbenos y lo hablamos.
