Microservicios: no es la respuesta a todo
La arquitectura de microservicios se ha convertido en un buzzword que muchos equipos adoptan sin evaluar si realmente la necesitan. Dividir una aplicación en servicios independientes tiene ventajas claras para sistemas grandes y equipos grandes, pero introduce complejidad que puede ser contraproducente para proyectos medianos.
Actualización — Julio 2026: hemos revisado y ampliado este artículo tres años después de su publicación. La tesis original —no adoptar microservicios por moda— ha envejecido bien: la industria ha consolidado el monolito modular como punto de partida por defecto y una parte significativa de las organizaciones que adoptaron microservicios está reagrupando servicios. Abajo analizamos qué ha cambiado y cómo abordar la decisión en 2026.
Qué son realmente los microservicios
Una arquitectura de microservicios divide la aplicación en servicios independientes que se comunican entre sí (normalmente vía HTTP/REST o mensajería asíncrona). Cada servicio tiene su propia base de datos, se despliega de forma independiente, y puede estar escrito en un lenguaje diferente. Un ecommerce, por ejemplo, podría tener servicios separados para catálogo, carrito, pagos, envíos, usuarios y notificaciones.
Cuándo sí tienen sentido
Los microservicios aportan valor real cuando: tu equipo de desarrollo tiene más de 8-10 personas y necesitas que trabajen en paralelo sin pisarse, cuando diferentes partes del sistema tienen requisitos de escalabilidad muy diferentes (el catálogo recibe 100x más tráfico que el panel admin), o cuando necesitas adoptar nuevas tecnologías gradualmente sin reescribir todo el sistema.
Cuándo NO tienen sentido
Para equipos pequeños (menos de 5 desarrolladores), aplicaciones nuevas sin tráfico probado, o MVPs que necesitan iterar rápido, un monolito bien estructurado es casi siempre mejor. La complejidad operativa de los microservicios (orquestación de contenedores, service discovery, observabilidad distribuida, gestión de transacciones) requiere un equipo con experiencia DevOps dedicada.
El camino intermedio: monolito modular
La alternativa más sensata para la mayoría de proyectos es el monolito modular: una aplicación desplegada como una unidad pero con módulos internos bien separados con interfaces claras. Esto facilita extraer módulos a servicios independientes cuando realmente sea necesario, sin pagar el coste de la complejidad distribuida desde el principio.
Tecnologías clave
Si decides ir por microservicios, necesitarás: Docker para contenedores, Kubernetes o similar para orquestación, un API Gateway (Kong, AWS API Gateway), un sistema de mensajería (RabbitMQ, Kafka), observabilidad distribuida (Grafana, Datadog, ELK), y un pipeline de CI/CD robusto. Todo esto tiene coste de infraestructura y de equipo.
Nuestra recomendación
Empieza con un monolito bien diseñado, con módulos separados y interfaces claras. Extrae a microservicios solo los componentes que realmente lo necesiten por escalabilidad, rendimiento o independencia de equipo. No diseñes microservicios porque suena moderno; diseña la arquitectura que tu proyecto y tu equipo necesitan hoy.
Qué ha pasado desde 2023: el péndulo ha vuelto
Cuando publicamos este artículo, defender el monolito frente a los microservicios era ir a contracorriente. Tres años después, el péndulo de la industria ha girado de forma visible. Una encuesta de la CNCF de 2025 apunta que en torno al 42% de las organizaciones que adoptaron microservicios están consolidando servicios de vuelta en unidades desplegables más grandes, y los casos públicos se han acumulado: el más citado sigue siendo el del equipo de análisis de calidad de vídeo de Amazon Prime Video, que migró de una arquitectura distribuida a un monolito de proceso único con una reducción de costes de infraestructura de en torno al 90%.
El consenso actual no es «los microservicios han muerto», sino algo más matizado: empieza con un monolito modular y extrae servicios solo cuando exista una razón concreta y demostrada. Es exactamente la recomendación con la que cerrábamos este artículo en 2023, y es también la que aplicamos cuando un cliente llega con una startup en fase de producto: como explicamos en nuestra guía sobre cómo pasar de MVP a producto escalable sin cometer errores técnicos, la arquitectura debe seguir al negocio, no al revés.
El coste real: infraestructura y equipo en 2026
Buena parte del reflujo se explica con la factura. Los costes de cloud han subido de forma sostenida y una arquitectura distribuida multiplica los conceptos facturables: tráfico entre servicios y zonas de disponibilidad, balanceadores internos, colas, réplicas de bases de datos por servicio y, sobre todo, observabilidad — trazas distribuidas, métricas y logs centralizados de decenas de servicios pueden costar más que la propia computación. A eso se suma el coste de equipo: mantener Kubernetes, service mesh y pipelines por servicio exige perfiles de plataforma que una pyme rara vez puede dedicar en exclusiva.
La pregunta correcta en 2026 no es «¿aguanta esta arquitectura un millón de usuarios?», sino «¿cuánto cuesta operar esta arquitectura con el tráfico que de verdad tengo?». Un monolito modular bien dimensionado en dos o tres servidores con réplica cubre las necesidades reales de la gran mayoría de plataformas de negocio por una fracción del coste, y deja el presupuesto libre para lo que sí mueve la aguja: producto, datos y seguridad.
El factor nuevo: la IA también lee tu código
Hay un argumento a favor de las fronteras claras que en 2023 no existía: los agentes de IA. En 2026, una parte relevante del código se escribe, revisa o refactoriza con asistentes que necesitan cargar contexto del repositorio. Un monolito modular con módulos bien delimitados e interfaces explícitas es un entorno mucho más productivo para estas herramientas que una constelación de repositorios y servicios cuyo comportamiento conjunto solo se entiende en producción. Las fronteras de dominio ya no solo organizan a los equipos humanos: organizan también el contexto que consumen las máquinas.
Esto refuerza una práctica que siempre hemos defendido: contratos y documentación viva. Si un módulo tiene su interfaz documentada, extraerlo a servicio —o pedirle a un agente que lo haga— es un proyecto acotado. Sin ella, es arqueología. Sobre cómo mantener esa base documental sin que se pudra, escribimos en nuestra guía de documentación funcional de proyectos IT en la era de la IA.
Seguridad: la superficie de ataque se multiplica
Cada servicio nuevo añade endpoints, credenciales, secretos y canales de comunicación que proteger. Lo que en un monolito es una llamada a función, en microservicios es una petición de red que hay que autenticar (mTLS o tokens de servicio), autorizar, cifrar y auditar. Los fallos de autorización entre servicios —del tipo BOLA, el número uno del OWASP API Security Top 10— son hoy una de las vías de ataque más comunes en plataformas distribuidas; los cubrimos en detalle en nuestra guía de seguridad de APIs REST: autenticación, rate limiting y buenas prácticas.
Si tu organización opera una arquitectura distribuida, la gestión de secretos, el inventario de APIs y el mínimo privilegio entre servicios deberían formar parte de un sistema de gestión formal — el marco de la certificación ISO 27001 encaja de forma natural con este problema. Y si no sabes por dónde empezar, nuestra guía de ciberseguridad para tu empresa: por dónde empezar ordena las prioridades; un pentesting sobre las comunicaciones entre servicios suele revelar sorpresas.
Cómo extraer un microservicio sin romper nada
Cuando la extracción está justificada, el método importa más que la tecnología. El patrón de referencia sigue siendo el strangler fig: en lugar de reescribir, se rodea. Primero se aísla el módulo dentro del monolito —interfaz explícita, datos propios, cero dependencias circulares—; después se coloca una fachada que intercepta todas las llamadas; a continuación se desvía el tráfico gradualmente hacia el nuevo servicio midiendo errores y latencia, con capacidad de rollback inmediata; y solo al final, cuando el servicio lleva semanas estable, se retira el código antiguo.
Los puntos que más proyectos rompen: los datos (separar la base de datos antes de estabilizar el contrato obliga a dobles escrituras y conciliación — hazlo al final, no al principio), la idempotencia (toda llamada entre servicios se repetirá alguna vez: diseña para ello desde el primer día) y las transacciones distribuidas (si dos servicios necesitan transaccionalidad conjunta constante, probablemente son un solo servicio). Ninguna de estas lecciones depende del stack: valen igual para un ecommerce que para una plataforma B2B.
Señales de que ha llegado el momento de extraer
En las auditorías técnicas usamos señales observables, no intuiciones. Merece la pena plantearse una extracción cuando varios equipos se bloquean sistemáticamente en los mismos despliegues; cuando un componente necesita escalar en una proporción radicalmente distinta al resto y dimensionar todo el monolito para su pico resulta caro; cuando una parte del sistema exige una tecnología o un ciclo de vida incompatible con el resto; o cuando un dominio de negocio se ha vuelto tan estable y bien delimitado que su contrato apenas cambia. Si ninguna de estas señales aparece, la extracción es coste sin retorno — y verlo con datos externos es precisamente el objetivo de una auditoría técnica previa.
Arquitectura por tipo de plataforma: ecommerce, B2B y SaaS
La decisión también depende del tipo de plataforma. En ecommerce, las plataformas consolidadas (WooCommerce, PrestaShop, Magento, Shopify) ya traen una arquitectura definida, y la vía sensata no es trocearlas sino complementarlas: el buscador, el motor de recomendaciones o la integración con el ERP pueden vivir como servicios satélite mientras el core sigue siendo la plataforma. Es una forma de obtener los beneficios de la separación sin renunciar al ecosistema.
En plataformas B2B a medida —portales de cliente, sistemas de pedidos, plataformas logísticas— el monolito modular es casi siempre el punto de partida correcto: los dominios (clientes, pedidos, facturación, catálogo) están claros y pueden modelarse como módulos con fronteras estrictas, listos para extraerse si algún día hace falta. Y en SaaS multi-tenant, la presión suele llegar antes por los datos que por el código: aislar la información de cada cliente y escalar la capa de persistencia pesa más que dividir la aplicación en servicios. En los tres casos, la infraestructura compartida —colas de mensajes, cachés, pipelines de datos— puede introducirse de forma incremental sin comprometerse con una arquitectura distribuida completa.
Observabilidad: el precio de saber qué pasa
En un monolito, un error tiene un stack trace; en microservicios, tiene una historia repartida entre cinco servicios, dos colas y un gateway. Por eso la observabilidad no es opcional en arquitecturas distribuidas: sin trazas distribuidas (OpenTelemetry se ha consolidado como el estándar), métricas por servicio y logs correlacionados por identificador de petición, cada incidente se convierte en una investigación forense. Montar y operar esa capa tiene un coste doble: el de las herramientas —las plataformas de observabilidad facturan por volumen ingerido, y una arquitectura parlanchina genera volumen a espuertas— y el de la disciplina de instrumentar cada servicio de forma consistente.
La recomendación práctica: define desde el principio un presupuesto de observabilidad (qué se traza, qué se muestrea, cuánto se retiene) igual que defines un presupuesto de infraestructura. Y si estás en el monolito modular, instrumenta ya los límites entre módulos: cuando llegue una extracción, la telemetría que necesitas para validar el cambio estará funcionando desde el primer día. Es el tipo de detalle que distingue una migración medible de un salto de fe, y forma parte de cualquier plan serio de evolución de plataforma.
Errores comunes que vemos en auditorías
Uno: microservicios como decisión de currículum — la arquitectura se eligió porque el equipo quería aprender Kubernetes, y el negocio paga la curva de aprendizaje en producción. Dos: el monolito distribuido — servicios separados que se despliegan siempre juntos porque comparten base de datos o se llaman en cadena síncrona; combina los inconvenientes de ambos mundos sin las ventajas de ninguno. Tres: fronteras dibujadas por capas técnicas (servicio de base de datos, servicio de lógica, servicio de frontend) en lugar de por dominios de negocio; genera acoplamiento máximo entre servicios. Cuatro: ignorar el fallo parcial — nadie diseñó qué pasa cuando el servicio de precios no responde, y el resultado es una caída total con más piezas que antes. Cinco: no medir antes de decidir — sin datos de tráfico, latencia y coste por componente, cualquier decisión de arquitectura es una apuesta. La mayoría de estos errores se detectan en una tarde de revisión con las preguntas adecuadas; corregirlos en producción cuesta meses.
¿Tu plataforma necesita una decisión de arquitectura?
En Keliam ayudamos a empresas y startups a decidir con datos: auditamos tu plataforma, cuantificamos el coste real de cada opción y ejecutamos la evolución —monolito modular, extracción de servicios o ambas— sin parar tu negocio.
Preguntas frecuentes sobre microservicios
¿Los microservicios son más escalables que un monolito?
Escalan de forma más selectiva, que no es lo mismo. Un monolito también escala horizontalmente replicando instancias; lo que no permite es dimensionar un componente de forma independiente. Si tu perfil de carga es homogéneo, la ventaja de los microservicios en escalabilidad es mucho menor de lo que se asume.
¿Qué tamaño de equipo justifica microservicios?
La referencia práctica sigue siendo la del artículo original: a partir de 8-10 personas de desarrollo con dominios de negocio claramente separables. Por debajo de eso, el coste operativo de la arquitectura distribuida suele superar el beneficio de la autonomía de equipos.
¿Un monolito modular no acaba degenerando en un monolito clásico?
Solo si las fronteras no se hacen cumplir. Las herramientas actuales permiten verificar las dependencias entre módulos en CI (fallando el build cuando un módulo importa lo que no debe), y la revisión de arquitectura pasa a ser parte del pipeline, no un documento olvidado.
¿Kubernetes es imprescindible para microservicios?
No, pero es el estándar de facto para orquestarlos, y su coste de operación es parte del precio de la arquitectura. Si el presupuesto o el equipo no dan para operarlo con garantías, las plataformas gestionadas (Cloud Run, ECS/Fargate, App Service) reducen esa carga a cambio de menos control.
¿Cómo afecta esta decisión al mantenimiento a largo plazo?
Es la variable más infravalorada. Cada servicio añade dependencias que actualizar, parches de seguridad que aplicar y compatibilidades que verificar — para siempre. Un plan de mantenimiento de software continuo es lo que evita que una arquitectura, del tipo que sea, se convierta en deuda técnica con intereses.
¿Merece la pena volver de microservicios a un monolito?
Si el sistema funciona y el coste es asumible, no: reagrupar también tiene riesgo. Los candidatos claros son los «monolitos distribuidos» — servicios que ya se despliegan juntos y comparten datos. Consolidarlos reduce coste operativo y fallos sin perder nada, porque la separación era solo aparente.
Conclusión
Tres años después, la recomendación de este artículo no solo sigue vigente: se ha convertido en el consenso de la industria. Empieza con un monolito bien diseñado, con módulos separados e interfaces claras; mide con datos reales dónde duele; y extrae a microservicio únicamente los componentes que lo justifiquen por escalabilidad, rendimiento o independencia de equipo. En 2026, con los costes de cloud al alza, la seguridad de las arquitecturas distribuidas bajo presión y los agentes de IA como nuevos lectores del código, las fronteras claras valen más que nunca — y la arquitectura correcta sigue siendo la que tu proyecto y tu equipo necesitan hoy.
