¿Qué es un microservicio, para qué se hace y en qué se diferencia de un servicio?

1) Definición rápida (sin rodeos)

Microservicio: una pieza pequeña y autónoma de software que hace una cosa muy bien (un “bounded context”), se despliega de forma independiente, expone una API (normalmente HTTP/JSON o gRPC), y no comparte base de datos con otros. Cada microservicio puede tener su propio repositorio, ciclo de vida y tecnología.
Servicio (SOA/tradicional): componente de negocio más grande y transversal que también expone una interfaz, pero suele compartir modelos/datos y depende de un bus de mensajería o ESB para orquestación. Tiende a ser más acoplado, con despliegues coordinados.

Piensa en una ciudad:

Microservicios: muchos talleres especializados (neumáticos, frenos, pinturas). Cada uno decide su herramienta, abre/cierra cuando quiere y solo hace su labor.
Servicios (SOA): centros de servicios grandes dentro de un parque industrial que comparten almacenes, logística y normas comunes del polígono.

2) Un pelín de historia (porque el pasado enseña)

Monolitos (años 90–2000): una sola app grande. Fácil al inicio, dura de escalar y desplegar.
SOA (2000–2010): se trocea en servicios (a menudo SOAP) coordinados por un ESB. Redujo el monolito… pero introdujo acoplamientos y gobernanza pesada.
Microservicios (2013 en adelante): inspirados por prácticas de Amazon/Netflix. Servicios pequeños, independientes y equipos autónomos. “You build it, you run it”.

Curiosidad: Amazon popularizó el mantra de “two-pizza team” (un equipo tan pequeño que se alimenta con dos pizzas) y APIs obligatorias entre equipos.

3) Rasgos clave de un microservicio (la “lista de comprobación”)

Un solo propósito (p. ej., “facturación”, “inventario”, “catálogo”).
Propiedad de datos aislada (cada uno su BD; nada de joins entre servicios).
Despliegue independiente (puedes actualizar “catálogo” sin tocar “carrito”).
Observabilidad integrada (logs, métricas, trazas distribuidas).
Comunicación ligera (HTTP/REST, gRPC, eventos – Kafka/RabbitMQ).
Tolerancia a fallos (circuit breakers, timeouts, retries, idempotencia).
Autonomía tecnológica (un servicio en Python, otro en Go… si tiene sentido).

4) ¿Para qué se hacen? (beneficios reales)

Escalado fino: solo escalas lo que “duele” (p. ej., búsquedas en rebajas).
Despliegues rápidos: pequeños cambios, menos riesgo, CI/CD fluido.
Equipos dueños del negocio: más velocidad y foco.
Resiliencia: si cae “recomendaciones”, la compra puede seguir funcionando.
Evolución tecnológica sin dramas: migras un servicio a otra tech cuando convenga.

Ojo: los microservicios agregan complejidad operativa. Si no tienes CI/CD, observabilidad y cultura DevOps, sufrirás.

5) Microservicio vs Servicio (SOA) — comparativa directa

Aspecto	Microservicio	Servicio (SOA)
Granularidad	Fina (una capacidad concreta)	Más gruesa / transversal
Datos	Propios por servicio	A menudo compartidos/centralizados
Despliegue	Independiente	Frecuentemente coordinado
Comunicación	REST/gRPC/eventos, simple	ESB/WS-* (gobernanza más pesada)
Acoplamiento	Bajo (por contrato)	Mayor (modelos compartidos, ESB)
Gobernanza	Ligera (por equipo)	Centralizada (arquitectura corporativa)
Curva operativa	Alta (DevOps/observabilidad)	Menor, pero con menos agilidad
Casos ideales	Escalado rápido, equipos autónomos, releases frecuentes	Integración corporativa, procesos BPM, reglas comunes

6) ¿Cuándo conviene usarlos (y cuándo no)?

Úsalos si:

Tu producto crece rápido y necesitas lanzar features semanalmente.
Tienes múltiples equipos y quieres desacoplar agendas.
Hay picos de tráfico claros en dominios concretos.
Estás dispuesto a invertir en plataforma (Kubernetes, observabilidad, SRE).

Evítalos o espera si:

Estás en fase inicial con equipo pequeño (un monolito modular te hará más rápido).
No tienes aún CI/CD, monitorización ni testing automatizado decente.
Tu dominio es simple y el costo operativo no compensa.

Regla práctica: Empieza “mono-modular”. Cuando un módulo tenga razones claras (escala, ownership, velocidad), extráelo a microservicio.

7) Diseño: de la teoría a lo práctico

7.1 Bounded Context (DDD)

Define límites de negocio claros: Pedidos, Pagos, Catálogo, Usuarios.
Cada contexto = un microservicio con su modelo y su BD.

7.2 Contratos y eventos

Sincronía: REST/gRPC para consultas/acciones.
Asincronía: eventos tipo “OrderCreated”, “PaymentCaptured”.
Beneficio: menor acoplamiento, mejor resiliencia.

7.3 Datos: nada de “joins” remotos

Cada servicio propietario de su tabla. Para leer datos ajenos, usa APIs o proyecciones/eventos.

7.4 Idempotencia y consistencia eventual

Reintentos seguros (misma operación no debe duplicar efectos).
Acepta que algunas vistas tarden unos segundos en reflejar cambios.

8) Operativa: lo que suele romper (y cómo evitarlo)

Problemas típicos

“Zoo de servicios” sin observabilidad → imposibles de depurar.
Dependencias en cascada → caídas en dominó.
Contratos que cambian sin versionado → clientes rotos.
“Base de datos compartida por atajo” → acoplamiento mortal.

Buenas prácticas

Tracing distribuido (OpenTelemetry), métricas (Prometheus), logs centralizados.
Circuit breakers (resilience4j), timeouts, bulkheads.
Versionado de APIs (v1, v2) y contratos (OpenAPI, Pact).
Catálogo de servicios (Backstage) y documentación viva.
SRE: objetivos SLO/SLI, alertas útiles y runbooks.

9) Microservicios en Python (bonus práctico)

Frameworks API: FastAPI (rápido y tipado), Flask (ligero).
Mensajería: Kafka (eventos), RabbitMQ (colas).
Testing: pytest + contract tests (Pact), tests de integración con docker-compose.
Contenedores: Docker + Kubernetes (Helm, Kustomize).
CI/CD: GitHub Actions/GitLab CI; despliegues canary/blue-green.

10) Costes y ROI (la conversación seria)

+ Productividad por equipo (release independiente).
+ Escalado eficiente (pagas por lo que usas).
– Coste de plataforma (infra, observabilidad, seguridad).
– Complejidad cognitiva (más piezas, más conocimiento).

Conclusión financiera breve: compensa cuando tu velocidad de cambio y necesidad de escalar superan el coste de operar la plataforma.

🚀 Da el siguiente paso en tu carrera como QA

Has descubierto qué estudiar para ser QA, ahora es momento de dominar las herramientas y habilidades que te abrirán más puertas.
Entra en nuestro Centro de Recursos y accede a todos los libros y guías exclusivas que he publicado, diseñados para que aprendas de forma práctica y profesional.

👉 Accede ahora y transforma tu futuro

¿Te resultó útil esta guía? Compártela con otros profesionales de QA y mantente actualizado con las últimas tendencias salariales en el mundo del testing de software.