¿Cómo permite el patrón strangler fig migrar un monolito a microservicios de forma incremental?
Llamado así por una enredadera que envuelve un árbol y termina por reemplazarlo, el patrón strangler fig enruta el tráfico a través de una fachada para extraer capacidades del monolito de a una -- nunca una reescritura de una sola vez.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
¿Cómo permite el patrón strangler fig migrar un monolito a microservicios de forma incremental?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#El problema de las reescrituras de una sola vez
La respuesta instintiva ante 'nuestro monolito es inmanejable' es programar una reescritura: congelar el sistema viejo, construir el nuevo bien esta vez, y hacer el corte en una fecha objetivo. En la práctica esto casi nunca sale como se planeó. El negocio no se detiene mientras la reescritura está en curso, así que los nuevos requerimientos siguen cayendo sobre el sistema viejo, el objetivo se sigue moviendo, y la reescritura tiene que acertarle a un blanco móvil mientras arranca cada vez más atrás. Los equipos que intentan esto suelen pasar entre uno y tres años en un sistema paralelo que nunca llega del todo a la paridad de funcionalidades, momento en el cual la presión para cancelar la reescritura y 'simplemente seguir parchando el viejo' se vuelve muy difícil de resistir.
#El patrón: una fachada que va tomando el control
El patrón strangler fig evita apostarlo todo a un único corte. Colocás una capa de enrutamiento -- un reverse proxy o un API gateway -- delante del monolito, y toda petición pasa primero por ahí. Al principio, el proxy reenvía el 100% del tráfico al monolito, de forma totalmente transparente para quien llama. Cuando extraés una capacidad hacia un servicio nuevo, cambiás las reglas de enrutamiento del proxy para que las peticiones de esa capacidad vayan al servicio nuevo en su lugar, mientras todo lo demás sigue fluyendo sin cambios hacia el monolito. Repetís esto, una costura a la vez, hasta que el proxy enruta casi todo hacia servicios nuevos y la superficie restante del monolito es lo bastante chica como para darla de baja directamente.
#El ciclo típico de migración
- Elegí una capacidad acotada y bien entendida en el borde del monolito -- idealmente algo intensivo en lecturas y con pocas dependencias de escritura.
- Construí el servicio nuevo contra su propio almacén de datos, haciendo un backfill de los datos históricos desde la base del monolito.
- Enrutá un pequeño porcentaje del tráfico (o un tenant específico, o un flag solo interno) hacia el servicio nuevo, mientras hacés shadowing o comparás sus respuestas contra las del monolito para detectar desvíos de comportamiento antes de que importen.
- Aumentá el porcentaje de enrutamiento una vez que el servicio nuevo demostró estar a la altura, vigilando la tasa de errores y la latencia todo el tiempo.
- Llevá el enrutamiento al 100%, eliminá del monolito el código ahora muerto, y repetí con la siguiente capacidad.
#Por qué la base de datos, no el proxy, es la parte difícil
Configurar reglas de enrutamiento es trabajo de un día. Lo que realmente consume meses es que, durante la transición, tanto el monolito como el servicio nuevo suelen necesitar acceso a datos que se superponen. Si el nuevo servicio de Órdenes necesita datos de clientes que todavía viven en la base del monolito, tenés que elegir entre dejarlo leer esa base directamente (el acoplamiento que justamente querías quitar), montar un mecanismo de sincronización (doble escritura, o change-data-capture transmitiendo los cambios hacia el almacén propio del servicio nuevo), o aceptar una dependencia temporal de API de vuelta hacia el monolito. Ninguna de estas opciones es gratis, y elegir mal acá es lo que convierte una migración strangler fig en un trabajo de varios años.
| Riesgo | Por qué ocurre | Mitigación |
|---|---|---|
| Acoplamiento por base de datos compartida | El sistema viejo y el nuevo leen o escriben las mismas tablas durante la transición | Introducir un límite temprano -- vistas, un schema dedicado, o sincronización basada en CDC |
| Doble mantenimiento | Ambos caminos de código deben mantenerse correctos hasta el corte | Mantener corta la ventana de transición por capacidad; extraer en rebanadas verticales pequeñas |
| Desvío silencioso de comportamiento | El servicio nuevo diverge sutilmente del comportamiento heredado | Shadow traffic y comparación de respuestas antes de cambiar el enrutamiento |
| Migración de datos | Los registros existentes necesitan un backfill hacia el almacén del servicio nuevo | Backfill por lotes, luego doble escritura, luego corte de lecturas |
🧠 Check your understanding
0/3 · 0/3 answered1. ¿Qué rol cumple el proxy en el patrón strangler fig?
2. ¿Cuál suele ser la parte más difícil de una migración strangler fig en la práctica?
3. ¿Por qué se prefiere generalmente el patrón strangler fig sobre una migración completa de reescritura y corte?