Varios equipos en un producto
Menos conflictos y releases por dominio.
¿Qué es una arquitectura de microservicios? Definición y decisiones
Una arquitectura de microservicios divide la aplicación en servicios autónomos, cada uno con un alcance de negocio acotado y despliegue independiente. Se comunican por red — normalmente vía API — en lugar de un único ejecutable monolítico. Busca flexibilidad y escalado selectivo, a cambio de más complejidad operativa.
En una frase
Microservicios: varios programas especializados que colaboran, no un solo bloque grande.
Para recordar
- Cada servicio tiene su ciclo de release y, idealmente, su propia base de datos.
- Los límites siguen capacidades de negocio, no solo capas técnicas.
- La resiliencia exige gestionar fallos de red, timeouts y consistencia eventual.
- No es requisito inicial: muchos productos maduros empezaron monolíticos.
Ficha del término
- Arquitectura de microservicios
- Microservices architecture
- Término en inglés
- Microservices architecture
- Dominio
- Desarrollo web
- Categoría
- Arquitectura
- Nivel
- Intermedio a avanzado
¿Por qué microservicios?
Plataformas web grandes popularizaron el estilo para evolucionar equipos y tráfico sin congelar todo el sistema en cada release.
El coste oculto: observabilidad distribuida, versionado de API, pruebas end-to-end más difíciles. Sin DevOps y automatización, amplían el caos.
La pregunta es cuándo el dolor del monolito supera el coste de distribuir. Señales: despliegues arriesgados, equipos bloqueándose, necesidad de escalar solo una función.
¿Cómo estructurarlos?
- 01
Identificar contextos acotados
Partir del lenguaje de negocio: lo que cambia junto permanece junto.
- 02
Contratos de API
Versionado, esquemas, idempotencia.
- 03
Automatizar pipelines
CI/CD por servicio, contenedores o PaaS, pruebas de contrato.
- 04
Observar en producción
Trazas distribuidas, logs correlacionados, alertas por servicio.
Ejemplo concreto
Una plataforma de formación separa auth, catálogo, vídeo y facturación. El pico del sábado golpea el vídeo: se escala ese servicio. Un bug entre facturación y acceso exige revisar tres sistemas de logs.
Cuándo compensa
Carga desigual
Escalar un componente sin sobredimensionar todo.
Modernización gradual
Extraer un módulo legacy con el monolito activo.
Disponibilidad diferenciada
Aislar un servicio crítico.
Ventajas y límites
- Despliegues independientes
- Escalado fino
- Tecnologías heterogéneas posibles
- Mejor aislamiento de fallos
- Complejidad de red y consistencia
- Coste de infraestructura y skills
- Pruebas end-to-end más pesadas
- Riesgo de nano-servicios
¿Microservicios o monolito?
| Arquitectura de microservicios | Arquitectura monolítica | |
|---|---|---|
| Despliegue | Por servicio | Artefacto único |
| Datos | Almacenes separados | Base compartida, ACID simple |
| Inicio | Caro sin automatización | Rápido para MVP |
| Observabilidad | Trazas distribuidas | Logs centralizados |
Lo que debe saber la dirección
Elegir microservicios por moda suele reventar presupuesto y plazos. Compensa cuando el monolito ya no escala con el producto o los equipos. Antes, un monolito bien modularizado suele ser más rentable.
Preguntas frecuentes
¿Obligan Kubernetes?
No. PaaS, contenedores pequeños o serverless pueden bastar.
¿Cuántos servicios?
Pocos y bien delimitados mejor que muchos minúsculos.
¿Consistencia de datos?
A menudo consistencia eventual con sagas o mensajería.
Términos relacionados
Fuentes y referencias
¿El monolito frena entregas? Evaluamos si un corte gradual tiene sentido.
Hablar de arquitectura