Patrón Strangler Fig para cargas modernas

El patrón Strangler Fig (traducido al español de múltiples formas como: patrón estrangulador, patrón de ficus estrangulador, o patrón del higo estrangulador) se le atribuye a Martin Fowler como una estrategia para modernizar originalmente monolitos. Aunque puede ser aplicado para aplicaciones legadas, servicios de alta complejidad, o desarrollos poco mantenibles. En este blog hablaremos de estrategias y recomendaciones para llevar a cabo este patrón de modernización.El nombre peculiar de este patrón de diseño está inspirado en el árbol del mismo nombre. En un viaje a Australia de Martin Fowler vio un espécimen de este tipo. El cual consiste en una planta (ficus o higo) que germina muy cerca de otra, utilizando a su anfitrión como protección y como apoyo para continuar creciendo alrededor de él. Con forme el higo sigue creciendo empieza a estrangular al anfitrión, en una carrera por obtener más nutrientes del suelo y luz solar. Este proceso es gradual, hasta que el higo es suficientemente fuerte para reemplazar a su anfitrión.

Concepto en el mundo de la tecnología

Con esta idea, un tanto radical del mundo natural en el que vivimos, Martin comprende que este comportamiento se puede aplicar para la migración de grandes monolitos o servicios extensos. Donde, por la complejidad de los mismos, pudiera darse el escenario que el equipo de negocio o de TI no tiene los suficientes recursos (personal, tiempo, y/o presupuesto) para efectuar una migración a gran escala. O pudiera ser porque no se quiere impactar la experiencia a los usuarios, mientras se buscan mejores alternativas para satisfacer los requerimientos.

Similar al higo, las nuevas aplicaciones o servicios, que se van a desarrollar, usarán al monolito o aplicación original como base. La aplicación original seguirá teniendo gran parte de las solicitudes de los clientes en un inicio, creando a la par nuevos desarrollos que la irán reemplazando poco a poco. Estos últimos pudieran ser microservicios buscando desacoplar la aplicación en elementos más pequeños que puedan ser actualizados más rápidamente por los equipos de TI, e incluso involucrar nuevas tecnologías que les permitan tener una mayor elasticidad en el rendimiento, ser más resilientes y más costo eficiente.

Ejecución

Iniciamos con una aplicación legada:

Este patrón de diseño al implementarlo se puede dividir en tres fases:

Transformación: Se identifican los componentes o elementos de la aplicación original a reescribir. Definiendo las estrategias de distribución de los micro-servicios por ejemplo: número de ambientes a usar o las consideraciones de conectividad a nivel red privada y pública. Posteriormente, se crean nuevas versiones de ellos cubriendo por lo menos los requerimientos iniciales:
Coexistir: La existencia del desarrollo inicial nos permite tener una experiencia más fluida hacia los usuarios finales cuando se implementan los nuevos modelos. Además, de darnos una posibilidad de regresar al original en caso de existir fallas (rollback). Para lograr esta coexistencia comúnmente se incorpora un proxy que permita distribuir la carga de información entre los desarrollos de forma incremental. Por ejemplo: un HTTP proxy. En el caso de AWS se cuenta con Amazon API Gateway, que nos permitirá apificar y distribuir las peticiones entre la aplicación legada y sus nuevos micro-servicios. Permitiendo la incorporación de múltiples módulos a lo largo del tiempo.
Eliminar: Con ayuda del proxy paulatinamente se envía el tráfico a todos los nuevos desarrollos, validando la eficiencia de ellos. Hasta detener y eliminar la aplicación legada.

Consideraciones del patrón

Comúnmente se comenta que no existe una sola solución para todos los problemas, y este patrón no es la excepción. Algunos escenarios donde no se recomienda implementar el Strangler Fig:

Si el sistema monolítico tiene módulos pequeños o muy pocos, y no hay transformaciones complejas; la implementación de la estrategia puede generar más procesos administrativos que beneficios tecnológicos.
Si las peticiones al sistema no pueden interceptarse, distribuirse, o al manejarse la petición esta no pudiera cambiar el estado de alguno de los componentes. En ocasiones los sistemas tienen elementos fuertemente acoplados, de tal forma que la llegada de un mensaje detona procesos secuenciales dependientes del anterior. En este escenario el patrón Strangler Fig no daría una ventaja sustancial a su migración, dado que se tendría que cambiar varios elementos del flujo para que funcione adecuadamente.

Recomendaciones Generales para iniciar

Seleccione un componente que tenga una buena cobertura de prueba. Comience con este componente puede dar mucha confianza a los equipos durante el proceso de modernización.
Seleccione componentes que tengan requisitos de escalabilidad y comience con uno de estos componentes.
Seleccione un componente que tenga cambios de requisitos comerciales frecuentes e implementaciones frecuentes.
Evaluar las diferentes herramientas en las cuales desplegará los nuevos micro-servicios. En este blog se comenta el uso de tecnologías serverless (por ejemplo, microservicios montados como funciones en AWS Lambda), ya que se busca tener mayor agilidad e innovación en los nuevos despliegues porque los desarrolladores se enfocan en darle valor al negocio y no pensar tanto en administrar la infraestructura. Sin embargo, cada carga tiene sus particularidades, deberán revisarse, y dependiendo su caso se pueden involucrar diferentes tecnologías que beneficien al negocio.

Recursos complementarios

Blog de Martin Fowler: https://martinfowler.com/bliki/StranglerFigApplication.html
Guía prescriptiva de AWS para aplicaciones de ASP.NET (ASMX): https://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-aspnet-web-services/fig-pattern.html
AWS Migration Hub Refactor Spaces es un servicio de AWS que apoya a los clientes en implementar el patrón de Strangler Fig en configuración de elementos de infraestructura: https://docs.aws.amazon.com/es_es/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html

Acerca del autor

Servio Tulio Reyes Castillo es arquitecto de soluciones en AWS México. Le interesan las ciencias de la computación y las tecnologías aeroespaciales.

Revisores

Rodrigo Cabrera es Sr. Solutions Architect en AWS México enfocado en ayudar a los clientes a modernizar sus aplicaciones enfocándolos a ser disruptivos en lo que da valor al negocio, apasionado de Serverless, con 20 años de experiencia en desarrollo, patrones de diseño, y T.I.

Iván González es arquitecto de soluciones en AWS México.

Blog de Amazon Web Services (AWS)