Patrón Strangler, migrando sistemas legados a microservicios

En el entorno empresarial, las aplicaciones monolíticas a medida que el tiempo pasa se vuelven más grandes incluyendo un mayor número de funcionalidades y lógica de negocio. Unido a lo anterior, el creciente número de usuarios conectados a la red da lugar a que sea cada vez más costoso su mantenimiento y sobre todo lograr que ofrezcan altos niveles de calidad de servicio.

A partir de la evolución de las arquitecturas, y especialmente con la llegada de los microservicios muchas aplicaciones inician un proceso de migración; el tamaño de los monolitos hace que ese proceso sea lento y gradual, surgiendo la necesidad de lograr una convivencia entre el viejo sistema y los nuevos servicios que se van creando paulatinamente.

Para lograr que el sistema legado funcione y cada uno de los microservicios que se van creando realice su tarea particular es necesario definir un mecanismo que sirva de fachada para las aplicaciones clientes y dirija el tráfico de las operaciones al ente correspondiente.

La creación de este mecanismo puede incluir traducción de semántica y protocolos, por ejemplo, traducir una llamada SOAP a REST / gRPC / Cola de mensajes / u otros, para encaminarla a los servicios modernos.

La fachada que se crea implementa una capa transparente para los clientes, traduciendo las llamadas al servicio adecuado; a medida que se van creando nuevos servicios disminuye el flujo hacia la aplicación legada. Los nuevos microservicios van creciendo en uso “estrangulando” la aplicación legada. Esto se conoce como el Patrón Strangler (en la traducción al español se conoce como de estrangulación).

La forma en que se estrangula el sistema legado requiere tener en cuenta ciertas consideraciones en el proceso de transición:

1 – Debe existir consistencia en los sistemas de persistencia que emplea el sistema legado y los microservicios.

2 – El desarrollo de los nuevos microservicios no puede / debe estar atado a la semántica del sistema legado, la capa de fachada se encargará de realizar los cambios semánticos / protocolos necesarios.

3 – El equipo que desarrolla la capa de fachada debe estar al tanto de los contratos que exponen los nuevos microservicios, el desarrollo debe ser a la par.

4 – En dependencia del tamaño del sistema legado, y el grado de descomposición de los nuevos microservicios debe velarse porque la fachada no se convierta en un cuello de botella para la migración, debe velarse por su escalabilidad, alta disponibilidad y monitorización continua.

El patrón Strangler, abordado en este artículo, tiene una estrecha relación con el patrón de capa anticorrupción, puedes ver más sobre estos patrones en el libro de Patrones para la implementación de una arquitectura basada en microservicios.

Este patrón debe usarse siempre que se tenga un sistema legado complejo que se vaya a descomponer en microservicios.