Modernizar un sistema heredado: qué función desviar primero con una fachada Strangler Fig y cómo revertir el corte

La decisión

Proponemos desviar primero una función pequeña, con una costura identificable, un alcance de escritura acotado y semántica cercana a la del sistema nuevo. Ensaye el corte con una porción pequeña de tráfico detrás de la fachada y deje probada la regla que devuelve esas solicitudes al sistema heredado. Esa reversión diseñada y probada es la condición que proponemos para avanzar sin detener la operación; no es una garantía que la fachada traiga consigo.

Esta guía convierte esa decisión en pasos con responsable y evidencia. Los criterios técnicos vienen de cuatro referencias: el documento Patrón Strangler Fig del Centro de arquitectura de Azure de Microsoft Learn y el artículo Strangler Fig de Martin Fowler, publicado el 22 de agosto de 2024 como revisión del texto de 2004, más dos documentos del mismo Centro de arquitectura de Azure: Patrón Anti-Corruption Layer y Patrón Event Sourcing. Son documentación de proveedor y referencia internacional: no describen los sistemas de su empresa ni constituyen norma panameña. Donde el paso es una propuesta nuestra o una inferencia, lo decimos en el texto.

Cómo funciona la fachada

Microsoft Learn describe la migración incremental como el reemplazo gradual de partes específicas de la funcionalidad por aplicaciones y servicios nuevos. Una fachada, que actúa como proxy, intercepta las solicitudes dirigidas al sistema heredado y las enruta al sistema heredado o a los servicios nuevos. Al inicio dirige la mayoría al heredado y, a medida que avanza la migración, redirige gradualmente más solicitudes al nuevo. Los clientes siguen usando la misma interfaz y, según el documento, pueden no saber que hay una migración en curso.

El mismo documento señala que el patrón reduce los riesgos de la migración al permitir que los equipos avancen a un ritmo que se adapta a la complejidad del proyecto, y que el sistema heredado puede retirarse cuando toda la funcionalidad migró y no quedan dependencias. Proponemos que el equipo de ingeniería defina y mantenga la regla de enrutamiento, y que quien responde por el sistema, sea el director de tecnología o el gerente general, apruebe el ritmo de cada desvío. Como evidencia de este paso, proponemos llevar un registro de solicitudes enrutadas a cada ruta.

Por qué no reemplazar todo de una vez

Martin Fowler escribe que el plan simple de reemplazo total, construir un sistema nuevo que haga exactamente lo mismo en una tecnología mejor, ha fracasado la mayoría de las veces en su experiencia. Las razones que enumera: el reemplazo de un sistema serio tarda, los usuarios no pueden esperar nuevas funciones, el comportamiento existente es difícil de especificar y buena parte de ese comportamiento no se quiere realmente.

Fowler recoge cuatro actividades de alto nivel para la modernización incremental: entender los resultados que se quieren lograr, decidir cómo dividir el problema en partes, entregar las partes con éxito y cambiar la organización para sostenerlo. El orden no implica una secuencia. Advierte también que los sistemas heredados rara vez tienen componentes claros que se puedan reemplazar de forma independiente, así que hay trabajo en identificar costuras para dividir el sistema. Una vez aislados componentes pequeños, el riesgo de introducir software nuevo es menor y el negocio obtiene valor antes. De ahí inferimos que conviene empezar por una función pequeña y no por el corazón del sistema.

Criterios para comparar candidatas

Para comparar funciones candidatas al primer corte, proponemos evaluar primero que tenga una costura identificable, un límite donde el sistema se pueda dividir; Fowler sostiene que ese trabajo de identificación es parte central del enfoque. Proponemos también que su alcance de escritura sea acotado, y postergar como primer corte una función que obligue a cambiar un modelo de datos compartido por muchos sistemas. Este criterio es una propuesta de diligencia nuestra, no una regla de los documentos.

El otro aspecto a comparar es el costo de traducción. El documento Patrón Anti-Corruption Layer de Microsoft Learn propone una capa de fachada o adaptador entre subsistemas que no comparten la misma semántica, para traducir las solicitudes de uno al otro y que las dependencias externas no limiten el diseño. El mismo documento advierte que esa capa agrega latencia a las llamadas entre los dos sistemas y un servicio adicional que debe administrarse y mantenerse, y pide considerar cómo escalarla. De ahí inferimos que una candidata cuya semántica difiera mucho del sistema nuevo podría requerir una capa de traducción con ese costo operativo, y que ese costo es relevante para comparar. La comparación es nuestra: la construimos sobre la descripción de la capa y su costo, no sobre un ranking de candidatas que tomemos del documento.

La cautela de Event Sourcing

El documento Patrón Event Sourcing de Microsoft Learn se presenta como un patrón complejo con ventajas importantes: cambia la forma de almacenar datos, controlar la simultaneidad, evolucionar esquemas y consultar el estado; es costoso migrar hacia él o desde él y, tras adoptarlo, restringe decisiones de diseño futuras en las partes del sistema que lo usan. El documento recomienda adoptarlo cuando ventajas como la auditabilidad y la reconstrucción histórica justifican la complejidad, y señala que para la mayoría de los sistemas, y de las partes de un sistema, la administración de datos tradicional es suficiente.

Nuestra inferencia, y lo decimos como inferencia: una primera función que exija Event Sourcing cargaría con esa complejidad, ese costo de migración y esas restricciones de diseño desde el primer día. Salvo que la auditabilidad o la reconstrucción histórica sean el resultado buscado del corte, esa función parece demasiado amplia para empezar. La cautela es nuestra; no la atribuimos al documento, que en la evidencia citada trata del patrón en general y no del orden de los cortes de una migración.

El registro de decisión y la prueba de reversión

Proponemos que, antes de elegir la función, el equipo escriba un registro de decisión con estos campos: el resultado buscado, la función candidata, la interfaz que usan los clientes, la regla de enrutamiento de la fachada, las traducciones necesarias entre semánticas, el disparador de reversión, el responsable de cada paso y la evidencia de que la ruta antigua sigue funcionando. El registro lo redacta ingeniería y lo aprueba quien responde por el negocio; sin ese documento, la discusión sobre qué desviar primero se vuelve una negociación sin datos.

Para probar la reversibilidad proponemos ensayar el corte con un cliente o una porción pequeña de tráfico, y mantener en la fachada la posibilidad de devolver esas solicitudes al sistema heredado antes de ampliar el desvío. La evidencia que respalda este paso es concreta: el registro de solicitudes por ruta, la conciliación de salidas entre ambas rutas y una prueba ejecutada del disparador de reversión. Conviene ser claro sobre el límite del respaldo: en la evidencia citada, Microsoft Learn y Fowler respaldan el enrutamiento incremental y la reducción de riesgo, pero la reversibilidad de cada paso no aparece ahí como una garantía. Hay que diseñarla y probarla; esto es una inferencia nuestra, no una promesa de los documentos.

Cuándo cambia el enfoque y cuándo traer a un ingeniero

Hay condiciones que cambian la forma de trabajar. Si no encuentra una costura identificable, el trabajo previo es dividir el sistema, no desviar tráfico. Si la función obliga a cambiar un modelo de datos compartido, conviene postergarla y elegir otra. Si las semánticas difieren mucho, el corte podría requerir una capa anticorrupción, y en ese caso debe presupuestar su latencia y su mantenimiento, como advierte Microsoft Learn. Si la función parece exigir Event Sourcing, pida que alguien justifique la auditabilidad o la reconstrucción histórica antes de aceptar el costo.

Recomendamos traer a un ingeniero cuando la ruta en juego sea un cobro, una ruta de transacción, una integración entre sistemas o un flujo de datos. En nuestro juicio, un error ahí tiene costo monetario directo, y por eso proponemos que la prueba de reversión mida latencia, reintento y conciliación, no solo que la solicitud llegó. Esa medición es una propuesta nuestra; los documentos citados no la establecen.

Si antes de comprometer presupuesto quiere un trabajo de alcance fijo sobre una ruta concreta, Atom Panamá ofrece la Evaluación de Sistemas Críticos: un trabajo pagado sobre una ruta de software atada a una decisión, que entrega un informe para decidir, el registro del sistema con su evidencia y opciones de mantener, reparar o reemplazar con un plan por etapas. Es una oferta comercial nuestra, no un paso del método descrito arriba.

Lista de verificación

• Escriba el resultado buscado del corte y confírmelo con las áreas que usan la función.
• Verifique que la candidata tenga una costura identificable donde dividir el sistema.
• Acote el alcance de escritura y descarte funciones que obliguen a cambiar un modelo de datos compartido.
• Mida el costo de traducción si las semánticas difieren: latencia, mantenimiento y escala de la capa.
• Cuestione cualquier candidata que exija Event Sourcing y pida justificar la auditabilidad o la reconstrucción histórica.
• Registre la regla de enrutamiento de la fachada y el disparador de reversión, con un responsable por paso.
• Ensaye el corte con un cliente o una porción pequeña de tráfico.
• Ejecute la prueba que devuelve esas solicitudes al sistema heredado y guarde su evidencia.
• Concilie las salidas de ambas rutas antes de ampliar el desvío.
• Asigne la aprobación del ritmo a quien responde por el sistema, con el registro de solicitudes por ruta como evidencia.

Preguntas frecuentes

¿La fachada garantiza que cada paso se puede revertir?

No por sí sola. Microsoft Learn describe el enrutamiento gradual y la reducción de riesgo del patrón, no una garantía de reversibilidad. La reversión hay que diseñarla como regla de la fachada, documentarla en el registro de decisión y probarla con una porción pequeña de tráfico antes de ampliar el desvío.

¿Cuánto tráfico conviene desviar en el primer corte?

No se encontró un porcentaje fijo en la evidencia citada. Proponemos empezar con un cliente o una porción pequeña y ampliar solo después de ejecutar la prueba de reversión y conciliar las salidas de ambas rutas. Microsoft Learn sí señala que el ritmo debe adaptarse a la complejidad del proyecto.

¿Qué pasa si la función nueva y la heredada no comparten semántica?

Puede avanzar con una capa anticorrupción que traduzca entre las dos, según el documento de Microsoft Learn. Tenga presente el costo: esa capa agrega latencia a las llamadas y un servicio adicional que administrar y mantener, y hay que planear su escala.