Lecciones migrando un monolito de años a microservicios en AWS
Por Floppai Engineering
Lo difícil de una migración rara vez es el código. Es la secuenciación, los datos y mantener todo en marcha mientras reconstruyes el motor.
Toda migración de monolito empieza con el mismo diagrama optimista: un conjunto ordenado de cajas con flechas entre ellas. La realidad es más desordenada. El monolito funciona — ese es el problema. Acumula años de reglas de negocio que nadie recuerda del todo, y los clientes dependen de él cada minuto.
Estas son las lecciones que sobrevivieron al contacto con producción.
Migra por capacidad, no por tabla
El fallo más común es trocear los servicios siguiendo el esquema de base de datos existente. Acabas con un monolito distribuido: servicios que no pueden desplegarse de forma independiente porque comparten datos. Trocea por capacidades de negocio y deja que cada servicio sea dueño de sus datos.
Usa el patrón strangler-fig: enruta el tráfico de forma incremental, capacidad a capacidad, con el monolito y los nuevos servicios funcionando en paralelo hasta que el camino antiguo sea código muerto.
La migración de datos es el proyecto
Los equipos presupuestan reescribir código y olvidan que mover datos — de forma consistente, sin downtime, con camino de rollback — es donde se van los meses. Doble escritura, backfill, reconciliación y luego cutover. Mide la reconciliación de forma continua; no confíes en una comprobación puntual.
En AWS esto suele significar un baile cuidadoso de RDS, DMS, streams de eventos y consumidores idempotentes. Nada de ello es glamuroso. Todo ello es donde los proyectos triunfan o fracasan.