Definición
Los microservicios son un estilo arquitectónico en el que una aplicación se construye como un conjunto de servicios pequeños, autónomos e independientes. Cada servicio se ocupa de una capacidad de negocio concreta (facturación, catálogo, autenticación, notificaciones), se despliega por separado y se comunica con los demás mediante APIs bien definidas.
El término se popularizó alrededor de 2014 con publicaciones de Martin Fowler y James Lewis, y fue impulsado por empresas como Netflix, Amazon y Spotify, que necesitaban escalar equipos y sistemas a un ritmo imposible para una aplicación monolítica.
Conviene desmitificarlos desde el principio: los microservicios no son una mejora gratuita del monolito. Resuelven problemas concretos (escalabilidad de equipos, despliegues independientes, escalado granular) introduciendo otros nuevos (latencia de red, consistencia distribuida, observabilidad compleja). Mal aplicados son el camino más rápido a un infierno operativo.
Cómo funciona
Una aplicación bajo arquitectura de microservicios se organiza típicamente así:
- Servicios autónomos: cada uno tiene su propio código, su propio equipo y, frecuentemente, su propia base de datos.
- Comunicación por API: REST/HTTP, gRPC o mensajería asíncrona (RabbitMQ, Kafka).
- Gateway de entrada: un API Gateway agrupa las llamadas del exterior y enruta a los servicios internos.
- Service discovery: como los servicios escalan dinámicamente, necesitan localizarse entre sí (Consul, Eureka, DNS de Kubernetes).
- Observabilidad transversal: logging centralizado, métricas (Prometheus), tracing distribuido (Jaeger, OpenTelemetry).
- Despliegue independiente: cada servicio sube a producción cuando su equipo decide, en su propio pipeline.
Ejemplo práctico
Imaginemos que IMDICA crece y decidimos descomponer el ERP monolítico actual en microservicios. Una posible división:
- Servicio de catálogo: gestiona productos y precios. BD: PostgreSQL.
- Servicio de pedidos: crea y actualiza pedidos. BD: PostgreSQL propia.
- Servicio de almacén: stocks, ubicaciones, picking. BD: MongoDB.
- Servicio de facturación: emite facturas, integra con Hacienda. BD: PostgreSQL propia + cola.
- Servicio de notificaciones: emails, SMS, push. Sin BD, consume eventos.
Cuando un cliente hace un pedido:
- El frontend llama al API Gateway → ruta a
pedidos. pedidosconsultacatálogopara validar precios.pedidospublica un eventopedido_creadoen Kafka.almacénconsume el evento y reserva stock.facturaciónconsume el evento y prepara la factura.notificacionesconsume el evento y manda email al cliente.
Cada servicio puede actualizarse, escalarse o caer sin tumbar el resto. Si la web se llena en Black Friday, escalamos solo pedidos y catálogo, no toda la app.
Microservicios vs monolito
| Aspecto | Monolito | Microservicios |
|---|---|---|
| Despliegue | Una unidad | Cada servicio por separado |
| BD | Compartida | Una por servicio (idealmente) |
| Comunicación interna | Llamadas a función | HTTP/gRPC/eventos |
| Escalado | Toda la app | Por servicio |
| Equipo | Suele trabajar sobre el mismo código | Cada equipo dueño de su servicio |
| Coste operacional | Bajo | Alto (K8s, observabilidad, devops) |
| Velocidad de inicio | Rápida | Lenta (montar infra) |
Para una empresa con 1-3 desarrolladores y < 10k usuarios, el monolito casi siempre gana. Para una empresa con 50+ desarrolladores y necesidad de desplegar 20 veces al día, los microservicios empiezan a tener sentido.
Errores comunes
- Adoptarlos sin necesidad: empezar con microservicios "porque mola" cuando tu equipo es de 3 personas → operativa imposible.
- Microservicios con base de datos compartida: rompe el aislamiento; cualquier cambio de schema afecta a todos. No es microservicios, es monolito distribuido.
- Llamadas en cadena síncronas: A llama a B que llama a C que llama a D → un fallo de D tumba todo. Usa colas y patrones tipo Saga.
- Olvidar la observabilidad desde el día uno: sin tracing distribuido, depurar un bug que cruza 5 servicios es un drama.
- Confundir microservicio con "una API pequeña": el microservicio implica independencia de despliegue, datos y equipo. No es solo trocear endpoints.
Cuándo usarlos
Sí, considera microservicios cuando:
- Tienes equipos numerosos y necesitas que trabajen en paralelo sin pisarse.
- Distintas partes del sistema tienen perfiles de carga muy diferentes y quieres escalarlas por separado.
- Algunos componentes requieren lenguajes o tecnologías distintas (ML en Python, web en TypeScript).
- Tu monolito se ha vuelto un cuello de botella organizativo claro y medible.
No, evítalos cuando:
- Tu equipo es pequeño (< 10 personas).
- El producto está aún buscando product-market fit y cambia mucho.
- No tenéis aún devops sólido (CI/CD, Kubernetes, observabilidad).
- "Lo hace Netflix" no es un argumento — tú no eres Netflix.
Referencias
- Martin Fowler · Microservices — artículo seminal de Fowler y Lewis
- Microservices.io — catálogo de patrones mantenido por Chris Richardson
- Sam Newman · Building Microservices (libro) — referencia práctica más completa del mercado