Microservicios prematuros en un equipo de seis personas
Una startup con 6 desarrolladores migró un monolito funcional a 14 microservicios en 8 meses. Síntomas: los despliegues requieren coordinar 5 servicios y tardan 3 días; un cambio de una regla de negocio toca 4 repositorios; el entorno local no arranca sin 11 contenedores y el onboarding de un nuevo dev tarda 3 semanas; hay 3 incidentes semanales por versiones incompatibles de contratos entre servicios. La dirección atribuye los problemas a 'falta de madurez en DevOps' y propone contratar 2 SRE y adoptar service mesh. El CTO pide una segunda opinión técnica antes de invertir.
1. Evalúa el diagnóstico de la dirección ('falta de madurez DevOps') frente a una explicación alternativa basada en el tamaño del equipo y los límites del dominio.
Read the worked answer
El diagnóstico de la dirección confunde síntoma con causa. Los síntomas (despliegues coordinados, cambios multi-repo, onboarding lento) son consecuencias esperables de 14 servicios con 6 personas, no de falta de herramientas.
Explicación alternativa:
- Ley de Conway invertida: los límites de servicio no reflejan equipos reales. Con 6 personas no hay 14 equipos; hay acoplamiento organizativo forzado a parecer técnico.
- Fronteras de dominio incorrectas: si una regla de negocio toca 4 repositorios, esos 4 servicios no son límites de dominio, son cortes arbitrarios. Un cambio de negocio debería vivir en un servicio.
- Coste de coordinación: cada frontera añade latencia de comunicación, versionado de contratos y despliegue conjunto. Con 6 personas, ese coste supera el beneficio de independencia.
Conclusión: un service mesh y 2 SRE harían los servicios más fáciles de operar, pero no arreglarían fronteras mal trazadas ni el exceso de servicios. Sería invertir en gestionar complejidad autoinfligida.
2. Propón una arquitectura objetivo realista para 6 personas y describe la migración por pasos, sin big-bang.
Read the worked answer
Objetivo: un monolito modular (2–3 despliegues como máximo) con límites de dominio explícitos internos, y extraer solo lo que tenga razón operativa propia.
Criterios para extraer un servicio: escala distinta, ciclo de release distinto, requisito de aislamiento (seguridad/cumplimiento) o equipo dedicado. Si no cumple ninguno, se queda dentro.
Migración por pasos (strangler, no big-bang):
- Consolidar los servicios que cambian juntos en un solo despliegue; mantener sus APIs internas como módulos con interfaces claras.
- Reagrupar por dominio: los 4 repositorios que toca una regla de negocio pasan a un módulo único.
- Mantener extraídos solo los servicios con razón operativa demostrada (p. ej. el que necesita escalar o aislar pagos).
- Contratos: versionado explícito y pruebas de contrato para lo que quede como servicio.
Entorno local: un solo comando para arrancar el monolito modular; los servicios extraídos se simulan con stubs.
Métrica de éxito: tiempo de onboarding < 1 semana, despliegue < 1 día, cambio de regla de negocio en 1 repositorio.
3. La dirección insiste en contratar 2 SRE y adoptar service mesh. ¿Qué evidencia presentarías y qué decisión recomendarías, considerando el coste de oportunidad?
Read the worked answer
Evidencia a presentar (no opinión):
- Tiempo de ciclo: medir lead time de un cambio de regla de negocio (hoy: 4 repos, 3 días de despliegue) frente al objetivo.
- Coste de coordinación: número de despliegues coordinados y de incidentes por contratos (3/semana) → atribuibles a fronteras, no a operación.
- Onboarding: 3 semanas con 11 contenedores; estimar el ahorro de consolidar.
- Contrafactual: ¿cuántos de los 3 incidentes semanales desaparecerían con mesh? Probablemente pocos: el mesh no corrige contratos incompatibles ni fronteras mal trazadas.
Recomendación:
- No contratar 2 SRE ni mesh antes de consolidar: se operaría mejor una arquitectura equivocada y se fijaría el coste.
- Sí invertir el mismo presupuesto en la consolidación (2 sprints de refactor de fronteras) y en CI/CD básico.
- Reevaluar SRE/mesh después, cuando queden 2–3 servicios con razón operativa; entonces el mesh tendrá sentido y el SRE tendrá algo que operar.
Coste de oportunidad: el presupuesto de 2 SRE durante un año es comparable al de la consolidación; solo uno de los dos reduce el tiempo de ciclo. Se decide por impacto medible, no por madurez percibida.