Microservicios suena a la arquitectura que toca tener si tu negocio crece, pero la mayoría de equipos de desarrollo arrastra la misma pregunta sin resolver: ¿compensa dividir la aplicación en servicios independientes o el monolito actual aguanta con otro diseño interno? La respuesta no depende del tamaño de la empresa, sino de cuántos equipos tocan el código a la vez, cuánto varía la carga entre los módulos más usados y cuánto cuesta mantener lo que se construya. Esto es lo que conviene mirar antes de decidir, con datos de quien ya se equivocó calculando esa cuenta.
Microservicios solo compensa cuando varios equipos bloquean el despliegue entre sí, cuando un módulo necesita escalar mucho más que el resto o cuando el monolito ya falla por tamaño, no antes. Para la mayoría de empresas con menos de 15 desarrolladores, un monolito modular bien diseñado cubre lo mismo con una infraestructura y un coste de mantenimiento muy inferiores.
Qué diferencia un monolito modular de microservicios
Un monolito clásico mezcla toda la lógica de negocio en una única base de código sin fronteras internas claras: tocar el catálogo puede romper la facturación porque todo comparte las mismas clases y la misma base de datos. Microservicios resuelve ese problema partiendo la aplicación en servicios independientes, cada uno con su propio despliegue y su propia base de datos. La guía de modernización de AWS sobre descomposición de monolitos lo resume así: dividir tiene sentido cuando el monolito ya tiene problemas de fiabilidad o rendimiento, no como paso obligado de cualquier proyecto que crece.
Un monolito modular es una única aplicación, con un solo despliegue y una sola base de datos, pero organizada internamente en módulos con fronteras de dominio claras: el código de facturación no puede llamar directamente a las clases del catálogo.
El patrón strangler fig para migrar sin parar producción
Cuando sí toca dividir, nadie reescribe la aplicación entera de golpe: el riesgo de parar la facturación o el catálogo durante semanas no lo asume ninguna empresa. El patrón strangler fig, de AWS, plantea tres pasos: transformar (construir la pieza nueva en paralelo), coexistir (un proxy delante del monolito que redirige el tráfico de esa pieza al servicio nuevo) y eliminar (retirar esa parte del monolito cuando ya no recibe tráfico). Un ecommerce de moda con picos de campaña puede extraer así solo el buscador de catálogo, sin tocar el checkout. El monolito y el servicio nuevo conviven semanas: eso es lo que hace reversible el cambio si algo falla a mitad de camino.
Las señales que de verdad piden una arquitectura distribuida
El tamaño de equipo importa más que el tráfico. Con menos de 10 o 15 personas tocando el mismo código, coordinar un único despliegue sigue siendo más barato que mantener varios servicios, sus pipelines y su monitorización por separado. La señal real aparece cuando dos o más equipos se bloquean constantemente para sacar una versión, cuando una parte de la aplicación necesita escalar diez veces más que el resto en según qué momentos, o cuando hay que desplegar partes con frecuencias muy distintas: el catálogo cambia cada día y la facturación cada mes.
Service per equipo, el bloqueo que justifica dividir
El patrón que AWS llama service per team asigna cada servicio a un equipo que lo diseña, lo despliega y lo escala sin depender de otro para sacar su propia versión. Tiene sentido en sectores muy distintos: una clínica dental que gestiona citas online y facturación con equipos separados, una correduría de seguros cuyo comparador de pólizas recibe diez veces más tráfico que el backoffice de siniestros, o un fabricante industrial que expone un catálogo B2B público mientras su ERP interno solo lo usan quince personas. En los tres casos el motivo no es el volumen total, sino que una parte necesita moverse a un ritmo que la otra no soporta sin frenar al equipo que la mantiene.
El límite del 5% que frenó a Prime Video
El equipo de monitorización de vídeo y audio de Prime Video construyó su primer sistema con componentes serverless: funciones Lambda orquestadas por Step Functions, con S3 como almacén intermedio entre pasos. Funcionaba, hasta que el tráfico subió: el diseño solo soportaba, según el análisis publicado por InfoQ sobre el caso, alrededor del 5% de la carga que necesitaban cubrir, y cada paso entre servicios cobraba por invocación y por almacenamiento intermedio. La solución no fue meter más servicios: fue juntar la lógica en un solo proceso sobre contenedores ECS, pasando los datos en memoria en lugar de por S3, lo que redujo el coste operativo de ese sistema un 90%. La lección no es que los microservicios estén mal diseñados por naturaleza, sino que dividir una carga que necesita miles de invocaciones por segundo en pasos independientes añade una factura por cada salto. Antes de replicar una arquitectura distribuida porque funciona en otra empresa, hay que medir cuánto cuesta cada llamada entre servicios con el volumen real, no con el que se espera tener dentro de tres años.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Lo que cuesta mantener microservicios de sobra
Dividir una aplicación no cuesta en el momento de escribir el código: cuesta cada mes después, en infraestructura que antes no existía y en guardias que antes no hacían falta. Lo que suma factura, apartado a apartado, es esto:
- Un orquestador de contenedores como Kubernetes y quien lo mantenga actualizado y parcheado.
- Una puerta de entrada y, a partir de cierto número de servicios, una malla de servicios para que se hablen entre sí con seguridad.
- Trazabilidad distribuida: sin ella, un fallo que cruza seis servicios se investiga a ciegas.
- Un pipeline de integración continua por servicio, con su propio tiempo de build y sus propios minutos de cómputo — el mismo límite de minutos gratuitos que ya frena a un solo repositorio se multiplica por cada servicio nuevo.
- Guardias de incidencias repartidas entre más piezas, cada una con su propio ciclo de parches de seguridad.
Nada de esto aparece en el presupuesto inicial del proyecto, y es la razón habitual por la que una migración que parecía barata en la propuesta acaba costando más que el monolito que sustituyó. Quien se encargue del mantenimiento de software a medida necesita saber desde el primer día cuántas piezas va a vigilar, porque el nivel de SLA que puede ofrecer depende directamente de ese número.
Cómo elige tu equipo entre monolito y arquitectura distribuida
La decisión se toma mirando tres datos propios, no comparando con lo que usa otra empresa del sector: cuántas personas tocan el código a diario, cuánto varía la carga entre los módulos más usados y cuántas veces al mes se bloquean dos equipos esperando el despliegue del otro. Si la respuesta a las tres es pocas veces, el monolito modular gana por coste y por velocidad de desarrollo; si alguna de las tres pesa de verdad, merece la pena extraer solo esa pieza con el patrón strangler fig, no rehacer toda la aplicación.
Monolito modular, el término medio que gana
Un monolito modular organiza el código en módulos con fronteras de dominio claras (facturación, catálogo, usuarios), cada uno con sus propias reglas y sin acceso directo a las tablas de los demás, aunque todo se despliegue junto y comparta base de datos. Da casi toda la claridad de microservicios para el día a día del equipo, saber dónde tocar y qué puede romper qué, sin la factura de infraestructura distribuida. Es el punto de partida que recomienda la propia guía de AWS antes de decidir si merece la pena separar algún módulo: diseñar primero los límites internos, y solo cruzar a un servicio independiente la pieza que de verdad lo necesite. Para una auditoría de qué módulos tiene sentido separar hoy y cuáles no, conviene una consultoría de sistemas IT que mire el código real antes de proponer nada.
Preguntas frecuentes sobre microservicios y monolito modular
¿Qué es un monolito modular?
Es una aplicación que se despliega como una sola unidad y comparte base de datos, pero está organizada internamente en módulos con fronteras de dominio claras. Cada módulo solo expone lo necesario al resto, así que cambiar uno no obliga a tocar los demás ni a desplegarlos por separado.
¿Cuántos desarrolladores hacen falta para microservicios?
No hay un número fijo, pero por debajo de 10 o 15 personas tocando el mismo código, coordinar varios equipos y servicios cuesta más de lo que ahorra. La señal no es el número exacto, sino si ya hay dos o más equipos bloqueándose entre sí para desplegar.
¿Microservicios siempre son más caros que un monolito?
No siempre, pero sí cuando se adoptan sin el volumen que los justifica: cada servicio añade infraestructura, observabilidad y guardias propias. Prime Video redujo un 90% su coste volviendo a un proceso único tras comprobar que la versión distribuida no aguantaba ni el 5% de la carga esperada.
¿Se puede migrar sin reescribir todo de golpe?
Sí, con el patrón strangler fig: se construye el servicio nuevo en paralelo, un proxy redirige a él solo el tráfico de esa función concreta, y el monolito sigue funcionando para el resto mientras dura la transición. Solo se retira la pieza antigua cuando el servicio nuevo la sustituye por completo.
Fuente: AWS Prescriptive Guidance — Decomposing monoliths into microservices
