Microservicios: cuando distribuir el sistema también distribuye el problema
Dividir una aplicación en múltiples servicios no garantiza autonomía ni agilidad. Cuando los límites del dominio son débiles, los equipos siguen dependiendo unos de otros y cada interacción incorpora nuevos puntos de falla; solo trasladamos el monolito a la red. En este artículo reflexiono sobre cuándo los microservicios realmente ayudan a evolucionar un negocio y cuándo únicamente distribuyen su complejidad. Te invito a leerlo y compartir tu experiencia.
Separar una aplicación en múltiples servicios no garantiza la autonomía. A veces solo convierte un problema conocido en muchos problemas conectados por la red.
Durante años, los microservicios se han presentado como el destino natural de cualquier arquitectura que necesite crecer.
La promesa resulta atractiva: equipos autónomos, despliegues independientes, escalabilidad selectiva y mayor velocidad de entrega.
Pero existe una diferencia importante entre dividir un sistema y desacoplarlo.
Podemos separar una aplicación en decenas de servicios y conservar las mismas dependencias, las mismas decisiones centralizadas y los mismos cuellos de botella. La única diferencia es que ahora también debemos gestionar la latencia, los fallos de red, la consistencia distribuida, la observabilidad y una infraestructura mucho más exigente.
En ese escenario, no construimos microservicios. Construimos un monolito distribuido.
Dividir no es desacoplar
Una arquitectura no se vuelve modular solo porque cada componente tenga su propio repositorio, contenedor o endpoint.
El desacoplamiento se demuestra en la capacidad de cambiar una parte del sistema sin provocar una cadena de modificaciones en las demás.
Si para desplegar un servicio necesitamos coordinar versiones con otros cinco; si varios equipos deben reunirse para aprobar cada cambio; si una modificación en el modelo de datos rompe consumidores inesperados, la autonomía es solo aparente.
La pregunta relevante no es:
¿Cuántos servicios tenemos?
La pregunta es:
¿Cuántos pueden evolucionar, desplegarse y recuperarse sin depender del resto?
Esa diferencia cambia por completo la conversación.
Los microservicios también son una decisión organizacional
Con frecuencia, la discusión comienza con tecnologías: lenguajes, contenedores, plataformas de orquestación, API gateways o mecanismos de mensajería.
Sin embargo, la arquitectura de microservicios es también —y quizá principalmente— una decisión sobre cómo organizamos el trabajo.
Cada servicio necesita límites claros, un propósito reconocible y un equipo con autoridad para tomar decisiones sobre él.
Cuando la estructura técnica no coincide con la estructura organizacional, aparecen fricciones inevitables:
- Un equipo es responsable del servicio, pero otro controla sus datos.
- Un cambio requiere la aprobación de varias áreas.
- La operación pertenece a un grupo diferente al que desarrolla.
- Las prioridades se negocian entre proyectos en lugar de responder a los resultados.
- Nadie tiene una visión completa del recorrido del usuario.
El resultado es una arquitectura distribuida con una organización aún centralizada. Y una organización que no puede trabajar con autonomía difícilmente producirá servicios autónomos.
El monolito distribuido
Un monolito no es necesariamente un problema. De hecho, puede ser una excelente decisión cuando permite desarrollar, probar y operar el producto con sencillez. El verdadero problema surge cuando distribuimos sus componentes sin eliminar sus dependencias internas.
Algunas señales son fáciles de reconocer:
- Los despliegues deben coordinarse.
- Los servicios comparten tablas o modifican directamente la misma base de datos.
- Una operación sencilla atraviesa una larga cadena de llamadas síncronas.
- Los contratos cambian sin mecanismos claros de compatibilidad.
- Un servicio solo puede probarse si todo el ecosistema está disponible.
- Una interrupción local se propaga hasta convertirse en una caída general.
- Ningún equipo se atreve a modificar un componente sin consultar a los demás.
La arquitectura parece distribuida en los diagramas, pero se comporta como una sola unidad en producción. Con una diferencia: ahora la complejidad también viaja por la red.
Los límites deben surgir del negocio
Uno de los errores más comunes es dividir los servicios según capas técnicas. Un servicio para clientes. Otro para productos. Otro para validaciones. Otro para notificaciones. Otro para acceder a los datos.
Aunque la separación parezca ordenada, cada proceso empresarial termina recorriendo prácticamente todos los servicios. Las dependencias se multiplican y ninguna unidad puede entregar valor de principio a fin.
Una alternativa más saludable consiste en pensar en capacidades de negocio y límites de dominio.
- ¿Qué decisiones pertenecen juntas?
- ¿Qué datos necesitan cambiar de manera consistente?
- ¿Qué parte del negocio tiene un ciclo de evolución distinto?
- ¿Qué capacidad podría administrar un equipo sin depender continuamente de otros?
Los buenos límites no eliminan la comunicación, pero reducen la coordinación obligatoria. Ese es uno de los objetivos centrales de la arquitectura: que los cambios frecuentes puedan realizarse dentro de un límite y que las interacciones entre límites sean explícitas, estables y comprensibles.
Cada llamada remota introduce una posibilidad de falla
Dentro de un proceso, una llamada a una función suele ser rápida y predecible. Entre los servicios, esa misma interacción está expuesta a la latencia, la saturación, las interrupciones, las respuestas parciales y la pérdida de conectividad.
El servicio remoto puede tardar en responder, procesar la solicitud sin que recibamos la confirmación o devolver un error temporal. Un reintento puede resolver el problema o duplicar una operación que ya se había ejecutado.
Por eso, distribuir una arquitectura obliga a diseñar conscientemente aspectos como:
- Límites de tiempo.
- Reintentos y espera progresiva.
- Idempotencia.
- Aislamiento de fallos.
- Degradación controlada.
- Procesamiento asíncrono.
- Compatibilidad entre versiones.
- Recuperación ante operaciones incompletas.
Estas decisiones no son detalles de implementación. Determinan el comportamiento real del producto cuando las condiciones dejan de ser ideales.
Un sistema distribuido bien diseñado no supone que todo funcione siempre. Se prepara para fallar sin convertir cada incidente en una crisis general.
Los datos dejan de ser un detalle interno
La recomendación de que cada servicio sea propietario de sus datos tiene un propósito: proteger su autonomía.
Pero también introduce responsabilidades.
Cuando una operación atraviesa varios servicios, ya no podemos asumir que una sola transacción mantendrá todo en perfecto estado. Debemos decidir qué significa consistencia para el negocio, qué información puede actualizarse de manera eventual y cómo corregiremos los estados parciales.
El desafío no consiste únicamente en elegir una base de datos para cada servicio. Consiste en definir:
- ¿Quién es la fuente autorizada de cada dato?
- ¿Cómo se comparte la información sin exponer el almacenamiento interno?
- ¿Qué sucede si una parte de la operación falla?
- ¿Cómo se detectan y reparan inconsistencias?
- ¿Qué eventos forman parte del contrato?
- ¿Durante cuánto tiempo debe mantenerse la compatibilidad?
Distribuir los datos sin aclarar su propiedad puede generar más acoplamiento que una base compartida.
La observabilidad debe formar parte del diseño
En un monolito, seguir una operación suele ser relativamente sencillo.
En una arquitectura distribuida, una sola acción del usuario puede atravesar numerosos servicios, colas, bases de datos y proveedores externos. Si cada componente produce registros aislados, reconstruir el problema se convierte en una tarea manual.
Por eso la observabilidad no puede añadirse al final. Necesitamos identificar una operación de extremo a extremo, relacionar sus eventos y comprender tanto el estado técnico como el impacto en el negocio.
Esto requiere, entre otras capacidades:
- Identificadores de correlación.
- Registros estructurados.
- Métricas técnicas y de negocio.
- Trazas distribuidas.
- Alertas vinculadas con síntomas relevantes.
- Objetivos de servicio comprensibles.
- Información suficiente para reproducir y explicar los fallos.
No basta con saber que un contenedor está funcionando. Necesitamos saber si el cliente pudo completar lo que intentaba hacer.
La autonomía incluye operar lo que construimos
Asignar un servicio a un equipo no lo convierte automáticamente en propietario.
La propiedad real exige autoridad y responsabilidad durante todo el ciclo de vida: diseño, desarrollo, despliegue, seguridad, operación, evolución y retiro.
Pero esa responsabilidad debe ir acompañada de capacidad.
No podemos pedir a los equipos que operen sus servicios si no cuentan con herramientas, conocimientos, tiempo y estándares compartidos. De lo contrario, cada equipo inventará su propia plataforma o dependerá de un grupo central para tomar cada decisión.
Las plataformas internas pueden reducir esa carga mediante caminos conocidos para desplegar, monitorear y proteger los servicios. Su función no es imponer una solución idéntica a todos, sino hacer que las prácticas recomendadas sean las más sencillas de adoptar.
La autonomía sostenible combina la libertad local con capacidades comunes.
No todo sistema necesita microservicios
Elegir una arquitectura más distribuida no es una señal automática de madurez.
Si el dominio todavía es incierto, el equipo es pequeño, el producto cambia rápidamente o la organización carece de automatización y experiencia operativa, un monolito modular puede ser una opción más eficaz. Permite mantener límites internos claros sin pagar por adelantado el costo de la distribución.
Los microservicios adquieren sentido cuando resuelven necesidades concretas, por ejemplo:
- Equipos que necesitan evolucionar capacidades distintas de forma independiente.
- Partes del sistema con demandas de escalabilidad muy diferentes.
- Dominios suficientemente comprendidos para establecer límites estables.
- Necesidad real de aislar fallos o tecnologías.
- Capacidad operativa para administrar múltiples componentes en producción.
La decisión debería comenzar por el problema, no por el patrón.
Antes de crear otro servicio
Conviene detenerse y responder algunas preguntas:
- ¿Qué capacidad de negocio será responsabilidad del servicio?
- ¿Qué equipo podrá modificarla y operarla de principio a fin?
- ¿El servicio podrá desplegarse sin coordinar una liberación general?
- ¿Será propietario de sus decisiones y de sus datos?
- ¿Qué dependencias síncronas introducirá?
- ¿Cómo se comportará cuando esas dependencias fallen?
- ¿Cómo seguiremos una operación a través del sistema?
- ¿Qué beneficio justifica el nuevo costo operativo?
- ¿Podríamos obtener el mismo resultado mediante un módulo bien definido?
- ¿Estamos resolviendo una necesidad actual o anticipando una escala que todavía no existe?
Si estas preguntas no tienen respuestas claras, probablemente aún no necesitamos otro servicio. Necesitamos comprender mejor los límites del sistema.
Distribuir autonomía, no solamente código
El valor de los microservicios no está en la cantidad de componentes que podemos desplegar.
Es posible que equipos con capacidades bien definidas puedan tomar decisiones, entregar cambios y responder ante fallos con menor dependencia del resto de la organización.
Cuando distribuimos código sin distribuir contexto, autoridad, propiedad y capacidad operativa, la complejidad aumenta, pero la velocidad no.
Modernizar la arquitectura no significa multiplicar servicios.
Significa diseñar límites que permitan que el negocio evolucione con seguridad.
Porque un sistema verdaderamente desacoplado no es el que tiene más piezas.
Es el que requiere menos coordinación para cambiar.
#Microservicios #ArquitecturaDeSoftware #SistemasDistribuidos #EngineeringLeadership #Observabilidad
Referencias rápidas
Haro Peralta, J. (2023). Microservice APIs: Using Python, Flask, FastAPI, OpenAPI and more. Manning Publications.
Tune, N., & Perrin, J.-G. (2024). Architecture modernization: Socio-technical alignment of software, strategy, and structure. Manning Publications
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article