Un equipo de ocho personas mantiene veinte microservicios. Cada release toca cuatro repos. Una transacción que antes era una llamada a base de datos ahora viaja por cinco servicios, dos colas y un service mesh. Y aun así, si uno falla, se cae todo. No tienes microservicios: tienes un monolito distribuido. Y es la peor arquitectura posible.
El video de arriba, del canal The Serious CTO, pone el dedo en una llaga que en SISCON vemos cada vez que aterrizamos en un proyecto de modernización: equipos que se compraron el discurso de los microservicios sin tener ni la escala, ni la organización, ni el músculo de plataforma para sostenerlos. El resultado no es un sistema más ágil. Es uno más caro, más frágil y más lento de cambiar.
Microservicios no son una estrategia de escalamiento. Son una estrategia de coordinación.
Esta es la confusión central del mercado. Microservicios no nacieron para "escalar tu tráfico" — un monolito bien hecho aguanta órdenes de magnitud más carga de la que la mayoría de empresas mexicanas jamás verá. Microservicios nacieron en Amazon, Netflix y Spotify para resolver un problema de gente: cómo permitir que 200 equipos liberen software de forma independiente sin pisarse entre ellos.
Si tu organización tiene un equipo de doce desarrolladores, no tienes un problema de coordinación entre 200 equipos. Tienes un problema de doce personas. Y para doce personas, un monolito bien estructurado es objetivamente mejor: un solo deploy, una sola transacción, un solo log, una sola base de datos. La complejidad operativa colapsa.
El "impuesto de coordinación" del que nadie te avisó
Cuando partes un sistema en N servicios, no eliminas la complejidad — la mueves. Sale de tu código y entra en la red, en la operación y en los procesos de tu equipo. Esto es lo que algunos llaman el coordination tax, y casi siempre se subestima en el business case original:
- Cada nueva feature toca varios repos. Una historia de usuario que antes era un PR se vuelve cuatro PRs coordinados, con dependencias de orden de merge.
- Tu CI/CD se vuelve un sistema en sí mismo. Pipelines, registries, gestión de versiones de contratos, ambientes de prueba con N servicios arriba. Necesitas un equipo de plataforma dedicado.
- Debugging cross-service es un deporte extremo. Sin tracing distribuido bien implementado, encontrar dónde se rompió una transacción puede tomar días.
- Las transacciones distribuidas son un mito. Lo que tenías como una transacción ACID se vuelve un saga pattern con compensaciones, idempotencia y estados inconsistentes que el negocio tiene que aprender a tolerar.
- Tu factura de cloud se dispara. Encuestas de la CNCF y reportes públicos de empresas que migraron muestran consistentemente que los costos de infraestructura suben tras adoptar microservicios — más nodos, más networking, más observabilidad, más almacenamiento.
Cómo se ve un "monolito distribuido" (y por qué es lo peor de los dos mundos)
El monolito distribuido es lo que pasa cuando partes el código pero no partes los acoplamientos. Las señales son brutales y casi siempre las mismas:
- Para liberar una feature necesitas desplegar 3, 4 o 5 servicios en un orden específico.
- Los servicios comparten la misma base de datos (o peor: distintas tablas pero del mismo esquema lógico).
- Una caída en el servicio "menos importante" tira al resto porque alguien lo invoca síncronamente en el flujo crítico.
- Los contratos entre servicios cambian sin versionar, así que un cambio en uno rompe a los demás.
- Ningún equipo "es dueño" claro de un servicio — todos editan todos.
Si te suena familiar, no tienes un problema de implementación. Tienes un problema de arquitectura: aplicaste el patrón equivocado al tamaño equivocado de organización.
La pregunta honesta antes de fragmentar nada
Antes de partir un sistema, vale la pena responder en serio tres preguntas — sin "porque está de moda" como respuesta válida:
1. ¿Cuál es el problema de negocio real que esto resuelve? Si la respuesta es "queremos modernizar" o "queremos estar en cloud", no es razón suficiente. Razones legítimas: un módulo tiene un ciclo de vida radicalmente distinto al resto (cambia 10x más rápido o 10x menos), un módulo tiene requerimientos de escalamiento o cumplimiento muy distintos, o hay equipos físicamente separados que necesitan operar de forma independiente.
2. ¿Tenemos el músculo de plataforma para sostenerlo? Microservicios requieren observabilidad seria (logs, métricas y trazas correlacionadas), CI/CD maduro, un service mesh o equivalente, gestión de secretos centralizada, y políticas claras de versionado de APIs. Si no tienes esto antes de empezar, vas a aprender a tenerlo en producción — y va a doler.
3. ¿Nuestra estructura organizacional empata con esta arquitectura? La Ley de Conway es implacable: terminas construyendo sistemas que reflejan la comunicación de tu organización. Si tienes un solo equipo de desarrollo, vas a construir un monolito disfrazado. Si quieres microservicios reales, primero necesitas equipos reales con dueños, OKRs y autonomía.
La alternativa que rara vez se propone: el monolito modular
Entre "todo en un solo blob de código" y "microservicios desde el día uno" hay un punto medio que es donde viven la mayoría de los sistemas exitosos: el monolito modular (también llamado modular monolith). Es un solo proceso, un solo deploy, una sola base de datos — pero internamente está dividido en módulos con fronteras claras, sin que un módulo pueda meter la mano a las entrañas del otro.
Ventajas: te quedas con la simplicidad operativa de un monolito (un log, un deploy, transacciones ACID, debugging local), pero con la disciplina de límites internos que hacen que cuando llegue el día en que un módulo realmente necesite vivir aparte, lo puedas extraer con poco dolor. Empresas como Shopify han documentado durante años cómo esta arquitectura los llevó muy lejos antes de necesitar extraer servicios.
¿Cuándo sí tiene sentido fragmentar?
Hay escenarios reales donde microservicios son la respuesta correcta — no queremos caer en el extremo opuesto. Los más comunes que vemos en proyectos serios:
- Un módulo necesita escalar de forma muy distinta al resto. Por ejemplo, un motor de cómputo intensivo que necesita GPUs vs. una capa web que necesita muchas réplicas pequeñas.
- Un módulo tiene requerimientos regulatorios o de aislamiento. Datos personales sensibles, módulos sujetos a auditorías independientes, segregación por país.
- Hay un equipo dedicado real con un dominio claramente delimitado. No "un equipo que toca cuatro servicios", sino un equipo dueño de un bounded context completo.
- Estás haciendo strangler fig sobre un sistema legacy. Aquí los "microservicios" son una táctica de migración, no la arquitectura final.
La conclusión que no vende cursos pero sí construye sistemas que duran
La arquitectura de software no es una moda. Es una decisión que vas a vivir cinco a diez años. Adoptar microservicios sin tener ni el problema, ni la escala, ni el equipo para sostenerlos te garantiza una cosa: pagar el costo completo de la complejidad distribuida sin recibir ninguno de los beneficios.
Si estás arrancando un sistema nuevo, empieza con un monolito modular bien diseñado. Si ya tienes un monolito que duele, no asumas que microservicios son la respuesta — primero entiende por qué duele. A veces es arquitectura. Muchas veces es disciplina, observabilidad o procesos. Y si ya estás en un monolito distribuido, lo mejor que puedes hacer es tener el coraje de reconsolidar lo que nunca debió partirse.
¿Estás evaluando partir o reconsolidar un sistema? Agenda una sesión de 30 min → · Conoce nuestros servicios de desarrollo de software y mantenimiento y soporte.
Fuente del video: "The Microservices Scam Nobody Talks About" — The Serious CTO. Ver en YouTube.