Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Este patrón migra de forma incremental un sistema heredado mediante la sustitución gradual de piezas específicas de funcionalidad con 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 suprime el sistema antiguo para que pueda retirarlo.
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.
Reemplazar un sistema complejo completo es una tarea enorme. En su lugar, muchos equipos prefieren migrar a un nuevo sistema gradualmente y mantener el sistema anterior para manejar las características no migradas. Sin embargo, la ejecución de dos versiones independientes de una aplicación obliga a los clientes a realizar un seguimiento de qué versión tiene características individuales. Cada vez que los equipos migran una característica o servicio, deben dirigir a los clientes a la nueva ubicación. Para superar estos desafíos, puede adoptar un enfoque que admita la migración incremental y minimice las interrupciones para los clientes.
Solución
Utilice un proceso incremental para reemplazar partes específicas de la funcionalidad con nuevas aplicaciones y servicios. Los clientes pueden seguir usando la misma interfaz, sin saber que se está llevando a cabo esta migración.
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 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.
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 enruta la mayoría de las solicitudes al sistema heredado.
A medida que avanza la migración, la fachada cambia 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.
Después de migrar toda la funcionalidad y de que no haya dependencias en el sistema heredado, puede retirar el sistema heredado. La fachada dirige todas las solicitudes exclusivamente al nuevo sistema.
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.
Estructure nuevas aplicaciones y servicios para que pueda interceptarlos y reemplazarlos fácilmente en futuras migraciones de figs estranguladoras. Por ejemplo, intente tener demarcaciones claras entre partes de la solución para poder migrar cada parte individualmente.
Una vez completada la migración, normalmente se quita la fachada de la figa del estrangulador. Como alternativa, puede mantener la fachada como adaptador para que los clientes heredados lo usen mientras actualiza el sistema principal para los clientes más recientes.
Asegúrese de que la fachada se mantenga al día con 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.
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 back-end no se pueden interceptar.
Migra un sistema pequeño y reemplazar todo el sistema es simple.
Es necesario retirar completamente la solución original rápidamente.
Diseño de cargas de trabajo
Evalúe cómo usar el patrón Fig de Strangler en el diseño de una carga de trabajo para abordar los objetivos y principios de los pilares de 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.
| Fundamento | Cómo apoya este patrón los objetivos de los pilares |
|---|---|
| Las decisiones de diseño de la fiabilidad ayudan a que la carga de trabajo sea resistente a los errores y a garantizar que se recupere a un estado de pleno funcionamiento después de que se produzca un error. | El enfoque incremental de este patrón puede ayudar a mitigar los riesgos durante la transición de un componente en comparación con la realización de grandes cambios sistémicos de una sola vez. - RE:08 Pruebas |
| La optimización de costos se centra en mantener y mejorar el retorno de la inversión (ROI) de su carga de trabajo. | El objetivo de este enfoque es maximizar el uso de las inversiones existentes en el sistema que funciona actualmente mientras se moderniza de manera incremental. Le permite realizar reemplazos de alto retorno de la inversión antes que reemplazos de bajo retorno de la inversión. - CO:07 Costos de componentes - Co:08 Costos del entorno |
| La excelencia operativa ayuda a ofrecer calidad de carga de trabajo a través de procesos estandarizados y cohesión de equipos. | Este patrón proporciona un enfoque de mejora continua. Los reemplazos incrementales que realizan pequeños cambios a lo largo del tiempo son preferibles a los grandes cambios sistémicos que son más riesgosos de implementar. - OE:06 Cadena de suministro para el desarrollo de cargas de trabajo - OE:11 Procedimientos de implementación seguros |
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 centralizada. Con el tiempo, una base de datos centralizada puede resultar difícil de administrar y evolucionar debido a sus muchas dependencias. Para hacer frente a estos desafíos, varios patrones de bases de datos pueden facilitar la transición de estos sistemas heredados. El patrón de higuera estrangulador es uno de estos patrones. Aplique el patrón Strangler Fig como un enfoque por fases para realizar una transición gradual de un sistema heredado a un nuevo sistema y minimizar las interrupciones.
Introduce un nuevo sistema y el nuevo sistema comienza a manejar algunas solicitudes de la aplicación cliente. Sin embargo, el nuevo sistema sigue dependiendo de la base de datos heredada para todas las operaciones de lectura y escritura. El sistema heredado sigue funcionando, lo que facilita una transición fluida sin cambios estructurales inmediatos.
En la siguiente fase, se introduce una nueva base de datos. El historial de carga de datos se migra a la nueva base de datos mediante un proceso de extracción, transformación y carga (ETL). El proceso ETL sincroniza la nueva base de datos con la base de datos heredada. Durante esta fase, el nuevo sistema realiza escrituras en sombra. El nuevo sistema actualiza ambas bases de datos en paralelo. El nuevo sistema continúa leyendo de la base de datos heredada para validar la coherencia.
Finalmente, la nueva base de datos se convierte en el sistema de registro. La nueva base de datos se encarga de todas las operaciones de lectura y escritura. Puede empezar a dejar de usar la base de datos heredada y el sistema heredado. Después de validar la nueva base de datos, puede retirar la base de datos heredada. Esta retirada completa el proceso de migración con una interrupción mínima.
Paso siguiente
Lea la publicación del blog de Martin Fowler sobre la aplicación del patrón de higos estranguladores.