Patrón de la higuera estranguladora

Migre incrementalmente un sistema heredado reemplazando gradualmente partes específicas de la funcionalidad por nuevas aplicaciones y servicios. A medida que reemplaza las características del sistema heredado, el nuevo sistema finalmente comprende todas las características del sistema anterior. Este enfoque desactiva el sistema antiguo para que pueda retirarlo del servicio.

Contexto y problema

A medida que los sistemas envejecen, las herramientas de desarrollo, la tecnología de alojamiento y las arquitecturas de sistemas en las que se basan pueden quedar obsoletas. A medida que se agregan nuevas características y funcionalidades, estas aplicaciones se vuelven más complejas, lo que puede dificultar su mantenimiento o ampliación.

Es difícil reemplazar un sistema complejo completo. En su lugar, puede migrar a un nuevo sistema gradualmente y usar el sistema antiguo para las características no migradas. Sin embargo, si ejecuta versiones paralelas de una aplicación, los clientes deben realizar un seguimiento de la versión que contiene cada característica. Al migrar una característica o servicio, debe dirigir los clientes a la nueva ubicación. Para abordar estos desafíos, adopte un enfoque que admita la migración incremental y minimice las interrupciones en los clientes.

Solución

Después de identificar nuevos límites de servicio, use un proceso incremental para reemplazar partes específicas de la funcionalidad por nuevas aplicaciones y servicios. Los clientes siguen usando la misma interfaz y no saben que hay una migración en curso.

Descargue un archivo de Visio de esta arquitectura.

El patrón Strangler Fig proporciona un enfoque controlado y por fases para la modernización. Permite que la aplicación existente siga funcionando durante el esfuerzo de modernización. Una fachada (proxy) intercepta las solicitudes que van al sistema heredado de back-end. La fachada enruta estas solicitudes a la aplicación heredada o a los nuevos servicios.

Este patrón reduce los riesgos en la migración al permitir que sus equipos avancen a un ritmo que se adapte a la complejidad del proyecto. A medida que migra la funcionalidad al nuevo sistema, el sistema heredado se vuelve obsoleto y se retira el sistema heredado.

1. El patrón Strangler Fig comienza con la introducción de una fachada (proxy) entre la aplicación cliente, el sistema heredado y el nuevo sistema. La fachada actúa como intermediaria. Permite que la aplicación cliente interactúe con el sistema heredado y el nuevo sistema. Inicialmente, la fachada dirige la mayoría de las solicitudes al sistema heredado.

2. A medida que avanza la migración, la fachada redirige gradualmente las solicitudes del sistema heredado al nuevo sistema. Con cada iteración, se implementan más piezas de funcionalidad en el nuevo sistema.

   Este enfoque incremental reduce gradualmente las responsabilidades del sistema heredado y amplía el alcance del nuevo sistema. El proceso es iterativo. Permite al equipo abordar las complejidades y las dependencias en etapas manejables. Estas etapas ayudan a que el sistema permanezca estable y funcional.

3. Después de migrar toda la funcionalidad y de que ya no haya dependencias del sistema heredado, puede retirar de servicio el sistema heredado. La fachada dirige todas las solicitudes exclusivamente al nuevo sistema.

4. Quite la fachada y vuelva a configurar la aplicación cliente para que se comunique directamente con el nuevo sistema. Este paso marca la finalización de la migración.

Problemas y consideraciones

Tenga en cuenta los siguientes puntos a medida que decida cómo implementar este patrón:

• Considere cómo manejar los servicios y almacenes de datos que podrían usar tanto el nuevo sistema como el sistema heredado. Asegúrese de que ambos sistemas puedan acceder a estos recursos al mismo tiempo.

• Diseñe nuevas aplicaciones y servicios de modo que pueda interceptarlos y sustituirlos fácilmente en futuras migraciones de tipo strangler fig. Por ejemplo, intente tener demarcaciones claras entre partes de la solución para poder migrar cada parte individualmente.

• Una vez completada la migración, se suele retirar la fachada de higuera estranguladora. Como alternativa, puede mantener la fachada como adaptador para que los clientes heredados la usen mientras actualiza el sistema central para clientes más nuevos.

  Conceptualice esto como arquitectura de transición y equilibre las ventajas de mitigación de riesgos de esta arquitectura frente a sus costos de infraestructura temporales.

• Asegúrese de que la fachada siga el ritmo de la migración.

• Asegúrese de que la fachada no se convierta en un único punto de fallo o en un cuello de botella en el rendimiento.

• Planee las dependencias entre sistemas. Durante la migración, ambos sistemas deben coexistir y comunicarse. Por ejemplo, el nuevo sistema podría necesitar llamar a la funcionalidad no migrada desde el sistema heredado y los componentes heredados no migrados podrían necesitar llamar a la funcionalidad migrada desde el nuevo sistema. Para gestionar estas llamadas, use el patrón de capa anticorrupción. Una capa contra daños actúa como un adaptador que traduce las solicitudes entre los dos sistemas. Esta capa protege el diseño del nuevo sistema de la semántica heredada para que el sistema heredado pueda llegar a nuevos servicios sin cambios significativos en el código. Sin este adaptador, las dependencias entre sistemas pueden interrumpir los componentes o forzar al nuevo sistema a adoptar convenciones heredadas.

Cuándo usar este patrón

Use este patrón en los siguientes supuestos:

• Se migra gradualmente una aplicación de back-end a una nueva arquitectura, especialmente cuando la sustitución de sistemas grandes, componentes clave o características complejas introduce riesgos.

• El sistema original puede seguir existiendo durante un período prolongado de tiempo durante el esfuerzo de migración.

Este patrón podría no ser adecuado cuando:

• Las solicitudes al sistema de backend no pueden ser interceptadas.

• No se puede acceder al código fuente del sistema heredado. Para deshabilitar las características migradas y redirigir las llamadas internas, debe poder modificar el código fuente del sistema heredado.

• Estás migrando un sistema pequeño y sustituir todo el sistema es sencillo.

• Es necesario retirar completamente la solución original rápidamente.

Diseño de cargas de trabajo

Evalúe cómo utilizar el patrón Strangler Fig en el diseño de una carga de trabajo para cumplir los objetivos y principios de los pilares del Azure Well-Architected Framework. En la tabla siguiente se proporciona una guía sobre cómo este patrón apoya los objetivos de cada pilar.

Considere las ventajas y desventajas de los objetivos de los otros pilares que este patrón podría introducir.

Ejemplo

Los sistemas heredados suelen depender de una base de datos monolítica centralizada que atiende varios dominios. Con el tiempo, esta base de datos compartida resulta difícil de administrar y mejorar debido a sus dependencias entre dominios. Para abordar este desafío, el patrón Strangler Fig extrae incrementalmente tablas específicas del dominio, procedimientos almacenados y datos relacionados de la base de datos monolítica en bases de datos de dominio aisladas. Cada base de datos contiene solo un dominio. Repita el proceso de extracción hasta que la base de datos monolítica esté completamente descomponida.

1. Introduce un nuevo servicio del sistema, que comienza a administrar las solicitudes de su dominio. El nuevo servicio del sistema sigue leyendo y escribe en la base de datos monolítica para sus tablas de dominio. El sistema heredado sigue sirviendo a todos los demás dominios.

2. Introducir una base de datos de dominio aislada para el nuevo sistema. Migre las tablas de dominio pertinentes y sus datos históricos a la nueva base de datos mediante un proceso de extracción, transformación y carga (ETL). Un proceso de captura de datos modificados (CDC) sincroniza los datos de dominio de la base de datos monolítica con la nueva base de datos de dominio. Durante esta fase, el sistema heredado continúa leyendo y escribiendo en la base de datos monolítica y el nuevo sistema escribe en la nueva base de datos de dominio. Valide la coherencia entre ambas bases de datos antes de la migración total.

3. Después de la validación, la nueva base de datos de dominio es el sistema de registro de ese dominio. El nuevo sistema realiza todas las operaciones de lectura y escritura en la base de datos de dominio. Quite las tablas de dominio, los procedimientos almacenados y las dependencias correspondientes de la base de datos monolítica. Repita este proceso para cada dominio hasta que la base de datos monolítica esté completamente descomponida.

   Puede revertir a la base de datos monolítica durante la fase 2 y al principio de la fase 3, cuando las tablas de dominio y los procesos de sincronización siguen existiendo en la base de datos monolítica. Para revertir a la base de datos monolítica después de quitar las tablas de dominio, los procedimientos almacenados y los procesos de sincronización de la base de datos monolítica, debe restaurar esos objetos y reproducir los cambios de datos. Sin embargo, este proceso aumenta significativamente el esfuerzo y el riesgo. Trate la eliminación de objetos heredados como un paso final deliberado para cada dominio. Quite los objetos heredados solo después de validar el nuevo sistema.

Colaboradores

Microsoft mantiene este artículo. Los siguientes colaboradores escribieron este artículo.

Autores principales:

• Adnan Khan | Arquitecto sénior de soluciones en la nube
• Ovais Mehboob Ahmed Khan | Arquitecto sénior de soluciones en la nube

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Paso siguiente

• Lea la entrada de blog de Martin Fowler sobre la aplicación de patrones Strangler Fig.

Recursos relacionados

• Patrón de puente de mensajes
• Planar la migración de la carga de trabajo de Amazon Web Services a Azure