Modernizacion de sistemas legacy: el patron strangler fig en la practica

Por que las reescrituras completas fracasan

La tentacion ante un sistema legacy doloroso es familiar: “Tiramos todo y lo reescribimos desde cero.” La historia de la ingenieria de software esta plagada de cadaveres de reescrituras completas. Netscape lo intento y tardo tres años en lanzar un navegador mientras Firefox le comia el mercado. Las estimaciones de la reescritura siempre subestiman la complejidad acumulada del sistema original, porque esa complejidad no es accidental. Son años de reglas de negocio, edge cases y decisiones que ya no recuerda nadie pero que mantienen el sistema funcionando.

El patron strangler fig ofrece una alternativa: reemplazar el sistema legacy pieza a pieza, manteniendo el sistema antiguo en funcionamiento hasta que no quede nada que reemplazar. Es la estrategia que recomendamos en el 90% de los casos. No es sexy. No es rapida. Pero funciona.

El patron strangler fig, explicado

El nombre viene de la higuera estranguladora, un arbol tropical que crece alrededor de su huesped, alimentandose de sus nutrientes, hasta que el arbol original muere y la higuera queda en su lugar. El paralelismo con software es directo: el sistema nuevo crece alrededor del antiguo, asumiendo funcionalidad progresivamente, hasta que el legacy puede apagarse.

En terminos tecnicos, el patron tiene tres fases:

Fase 1: Interceptar. Se coloca un proxy o fachada delante del sistema legacy que intercepta todas las peticiones. Inicialmente, el proxy simplemente redirige todo al sistema antiguo. No cambia nada. Pero establece el punto de control necesario para el reemplazo incremental.

Fase 2: Reemplazar. Funcionalidad por funcionalidad, se construyen implementaciones nuevas. El proxy redirige el trafico de cada funcionalidad reemplazada al sistema nuevo. El sistema legacy sigue manejando todo lo que aun no se ha migrado.

Fase 3: Eliminar. Cuando toda la funcionalidad relevante esta en el sistema nuevo, se apaga el legacy. En la practica, esta fase suele dejar un residuo: funcionalidades que nadie usa pero que nadie se atreve a eliminar. El strangler fig te obliga a tomar esa decision explicitamente.

La anti-corruption layer

El mayor riesgo del strangler fig no es tecnico. Es que el sistema nuevo herede la deuda tecnica del antiguo. Si el nuevo servicio de pedidos habla directamente con la base de datos del sistema legacy, el modelo de datos del legacy contamina el diseño del sistema nuevo.

La solucion es una anti-corruption layer (ACL): una capa de traduccion entre el sistema nuevo y el legacy. La ACL traduce los conceptos del dominio legacy a los conceptos del dominio nuevo y viceversa. Un “ORDER_HEADER” con 47 campos nullable en la base de datos legacy se convierte en un objeto Order limpio en el nuevo sistema, con solo los campos que el negocio realmente usa.

La ACL tiene un coste: es codigo adicional que hay que mantener durante la migracion. Pero ese coste es trivial comparado con la alternativa de construir un sistema nuevo que replica los defectos del antiguo.

En la practica, la ACL se implementa como:

• Un adaptador de base de datos que lee del schema legacy y expone un modelo limpio
• Un servicio de traduccion que convierte eventos del legacy a eventos del nuevo dominio
• Un API gateway que transforma peticiones y respuestas entre formatos

¿Cual elegir? Depende de como se comunican los sistemas. Si comparten base de datos (comun en monolitos legacy), el adaptador de base de datos es el punto de partida. Si hay comunicacion via API o mensajeria, el servicio de traduccion es mas apropiado.

Sincronizacion de datos durante la migracion

El problema mas dificil del strangler fig no es mover funcionalidad. Es mantener los datos sincronizados entre el sistema antiguo y el nuevo durante el periodo de coexistencia, que puede durar meses o años.

Hay tres patrones de sincronizacion:

Dual write: el sistema nuevo escribe en ambas bases de datos. Es el patron mas intuitivo y el mas peligroso. Si una escritura falla y la otra no, los datos se dessincronizan. Sin transacciones distribuidas (que añaden su propia complejidad), el dual write es una bomba de relojeria.

Event sourcing: cada cambio genera un evento que ambos sistemas consumen. Es el patron mas robusto pero tambien el que requiere mas infraestructura (necesitas un broker de eventos como Kafka o RabbitMQ) y mas cambios en el sistema legacy (que debe empezar a publicar eventos).

Change Data Capture (CDC): una herramienta monitoriza los cambios en la base de datos del legacy (normalmente via el log de transacciones) y los replica al sistema nuevo. Debezium es el estandar open-source para esto. La ventaja: no requiere cambios en el legacy. La desventaja: estas acoplado al schema de la base de datos, y los cambios de schema pueden romper la sincronizacion.

Nuestra recomendacion: CDC con Debezium para la fase inicial (porque no requiere tocar el legacy), evolucionando hacia event sourcing a medida que el sistema nuevo asume mas funcionalidad. El dual write solo como ultima opcion y con mecanismos de reconciliacion.

Decidir por donde empezar

No toda funcionalidad se migra igual de facil. La prioridad deberia basarse en tres criterios:

Valor de negocio: ¿que funcionalidad genera mas dolor hoy? Si el modulo de facturacion tarda 20 minutos en generar una factura y el equipo de administracion pierde 3 horas diarias, ese es un candidato prioritario.

Independencia: ¿que funcionalidad tiene menos dependencias con el resto del sistema? Un modulo de reporting que lee datos pero no los modifica es mas facil de extraer que el nucleo de procesamiento de pedidos.

Riesgo: ¿que funcionalidad es mas segura de migrar? Empezar por funcionalidades de bajo riesgo permite probar la infraestructura de migracion (proxy, ACL, sincronizacion) antes de tocar lo critico.

La interseccion de alto valor, alta independencia y bajo riesgo es el punto de partida ideal. Rara vez existe una funcionalidad perfecta en los tres ejes, pero la combinacion de al menos dos suele señalar un buen candidato.

Lo que los libros no cuentan

La migracion tarda mas de lo estimado. Siempre. Planifica un 50% de margen. Las reglas de negocio ocultas en el sistema legacy aparecen cuando empiezas a reemplazar funcionalidad, no cuando la analizas desde fuera.

El equipo necesita mantener dos sistemas. Durante la migracion, el equipo soporta el legacy y construye el nuevo. Si no se dimensiona la capacidad para ambas cosas, o el legacy se degrada (porque nadie quiere trabajar en el) o el nuevo se retrasa (porque el legacy absorbe toda la atencion).

La definicion de “terminado” es borrosa. ¿Cuando se apaga el legacy? Cuando toda la funcionalidad esta migrada, dicen los libros. En la realidad, siempre hay un 5-10% de funcionalidad que nadie usa lo suficiente para justificar la migracion pero que nadie se atreve a eliminar. Hay que tomar esa decision explicitamente. Nuestra regla: si una funcionalidad no se ha usado en 6 meses, no se migra. Se documenta y se apaga.

El proxy es la pieza mas critica. Si el proxy que intercepta el trafico falla, todo falla. Tiene que ser extremadamente fiable, con failover, con metricas, con alertas. No es un componente glamuroso pero es el que mantiene la migracion en pie.

Un patron, no una receta

El strangler fig no es una receta paso a paso. Es un patron que requiere adaptacion a cada situacion. Un monolito Java de 15 años con base de datos Oracle requiere una implementacion diferente que una aplicacion PHP con MySQL. Los principios (interceptar, reemplazar, eliminar) son universales. Los detalles son siempre especificos.

Lo que si es universal: la paciencia necesaria para hacerlo bien. Una migracion legacy exitosa se mide en trimestres, no en sprints. Pero cada funcionalidad migrada es un paso irreversible hacia un sistema mejor. Y a diferencia de la reescritura completa, cada paso entrega valor al negocio inmediatamente.

Si tu organizacion enfrenta un sistema legacy que frena la innovacion, podemos ayudarte a diseñar una estrategia de modernizacion incremental. Nuestro equipo de desarrollo a medida tiene experiencia en migraciones strangler fig para sectores como logistica y legal. Consulta tambien nuestro analisis sobre el coste real de la deuda tecnica para cuantificar el impacto de mantener el status quo.