Cuando empezamos, el plan cabía en una diapositiva: contenedores, un clúster gestionado y a correr. Seis meses después tengo claro que el clúster fue la parte fácil.
El inventario que no teníamos#
Antes de mover nada hicimos lo que deberíamos haber hecho años antes: un inventario honesto de cada servicio. Quién lo mantiene, de qué depende, qué pasa si se cae.
| Tipo | Servicios | Migrados sin cambios |
|---|---|---|
| APIs sin estado | 24 | 21 |
| Trabajos en cola | 9 | 4 |
| Con estado propio | 7 | 0 |
Los siete con estado propio se quedaron fuera de la primera fase. Fue la mejor decisión del proyecto.
Límites de recursos: la trampa de los valores por defecto#
Desde entonces ningún despliegue pasa la revisión sin esto:
resources: requests: { cpu: 250m, memory: 256Mi } limits: { memory: 512Mi }Sin límite de CPU, a propósito: el throttling nos dio más latencia que ruido.
Lo que haría distinto#
- Empezar por la observabilidad, no por el clúster.
- Migrar primero los servicios aburridos: ganan confianza y no hacen ruido.
- Poner presupuestos de error antes de la primera migración, no después del primer incidente.
La migración terminó en febrero. El equipo, que al principio la veía como un castigo, hoy despliega cuatro veces más que antes.