Migra de forma incremental un sistema heredado reemplazando gradualmente funciones específicas por los servicios y aplicaciones nuevas. A medida que se reemplaza el sistema heredado, el nuevo sistema sustituye eventualmente todas las características del sistema anterior, suprimiéndolo y permitiéndole su desmantelamiento.
Contexto y problema
Los sistemas envejecen y, simultáneamente, las herramientas de desarrollo, la tecnología de hospedaje e incluso las arquitecturas de sistema donde estaban construidos pueden quedarse también poco a poco obsoletas. A medida que se agregan características y funcionalidades, la complejidad de estas aplicaciones aumenta considerablemente,dificultando su mantenimiento o la incorporación de nuevas características.
La sustitución completa de un sistema puede ser una tarea enorme. A menudo, requerirá la migración gradual a un nuevo sistema mientras conserva el sistema antiguo para controlar las características que aún no se hayan migrado. Sin embargo, la ejecución de dos versiones distintas de una aplicación implica que los clientes deben conocer dónde se encuentra una característica determinada. Cada vez que se migra una característica o un servicio, los clientes deben actualizarse para apuntar a la nueva ubicación.
Solución
Reemplace de forma incremental elementos específicos de funcionalidad por las aplicaciones y los servicios nuevos. Cree una fachada que intercepte 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. Las características existentes se pueden migrar al nuevo sistema gradualmente, y los consumidores pueden seguir usando la misma interfaz sin ser conscientes de que se ha producido una migración.
Este patrón ayuda a minimizar el riesgo de la migración y distribuir el esfuerzo de desarrollo a lo largo del tiempo. Dado que la fachada enruta de manera segura a los usuarios a la aplicación correcta, puede agregar funcionalidad al nuevo sistema al ritmo que desee, asegurándose al mismo tiempo de que la aplicación heredada sigue funcionando. Con el tiempo, a medida que las características se migren al nuevo sistema, el sistema heredado acabará siendo "suprimido" y dejará de ser necesario. Una vez completado este proceso, el sistema se puede retirar sin riesgo alguno.
Problemas y consideraciones
- Piense en cómo administrar los servicios y los almacenes de datos que potencialmente pueden utilizar tanto los sistemas nuevos como los heredados. Asegúrese de que ambos pueden tener acceso a estos recursos en paralelo.
- Construya nuevas aplicaciones y servicios de forma que se puedan interceptar y reemplazar fácilmente en futuras migraciones de Strangler.
- En algún momento, una vez completada la migración, la fachada de Strangler desaparecerá o se convertirá en un adaptador para los clientes heredados.
- Asegúrese de que la fachada se mantiene al día con la migración.
- Asegúrese de que la fachada no se convierte en un único punto de error o un cuello de botella para el rendimiento.
Cuándo usar este patrón
Utilice este patrón cuando migre gradualmente una aplicación de back-end a una nueva arquitectura.
Este patrón puede no ser adecuado:
- Cuando no se pueden interceptar las solicitudes dirigidas al sistema de back-end.
- En sistemas más pequeños donde la complejidad de reemplazar todo el conjunto es limitada.
Diseño de cargas de trabajo
Un arquitecto debe evaluar cómo se puede usar el patrón Strangler Fig en el diseño de su carga de trabajo para abordar los objetivos y principios descritos en los pilares del Marco de buena arquitectura de Azure. Por ejemplo:
| 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 una transición de componente frente a cambios sistémicos grandes. - RE:08 Pruebas |
| La optimización de costos se centra en mantener y mejorar el retorno de la inversión de la carga de trabajo. | El objetivo de este enfoque es maximizar el uso de las inversiones existentes en el sistema actualmente en ejecución, al tiempo que se moderniza incrementalmente; como tal, le permite realizar reemplazos de ROI alto antes de reemplazos de ROI bajo. - 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, en el que se prefiere el reemplazo incremental con pequeños cambios a lo largo del tiempo en lugar de grandes cambios sistémicos que son más arriesgados para implementar. - OE:06 Desarrollo de carga de trabajo - OE:11 Procedimientos de implementación seguros |
Al igual que con cualquier decisión de diseño, hay que tener en cuenta las ventajas y desventajas con respecto a los objetivos de los otros pilares que podrían introducirse con este patrón.
Pasos siguientes
- Entrada de blog de Martin Fowler en StranglerFigApplication