Patrón: Capa anticorrupción en la arquitectura µServicios
La interacción con aplicaciones/servicios externos es común en todas las aplicaciones, cada día se consumen más servicios externos que ofrecen valor al negocio, por ejemplo: pasarelas de pago, tasas de cambio, capas de servicio de productos legados, apis de productos de terceros como wordpress, prestashop u otros . El número de servicios posibles a consultar es diverso y depende de cada negocio en particular.
En el caso particular de los microservicios debemos recordar que uno de sus principales características deseables es que cumplan con el Principio de Responsabilidad Única (SRP). Un microservicio (y una aplicación general) no debe estar atado a los cambios que pueda experimentar un tercero, o al menos debe implementarse un mecanismo adecuado que ayude a disminuir el impacto ante una variación del sistema de terceros con el que se comunica. El desacomplamiento es parte en sí del origen de los microservicios.
Otro punto a considerar es el proceso de transición desde una aplicación monolítica hacia microservicios. Es común en las grandes empresas que exista un producto central, con un API gigante (en ocasiones con tecnologías obsoletas que degradan el rendimiento), y se comienza a migrar esta aplicación a pequeños microservicios.
En el proceso de migración van entrando a producción los pequeños microservicios pero aún se usan funcionalidades del monolito que se van sustituyendo a medidas que transcurre la migración.
En este proceso ¿vale la pena que los nuevos microservicios se comuniquen directamente con la API del sistema monolítico cuando sabemos que desaparecerá ? La respuesta es evidente. Se requiere entonces crear un mecanismo que posibilite actuar como intermediario en la comunicación con la API externa y que las llamadas a la misma no corrompan el diseño del microservicio agregando código específico que dejará de estar operativo en poco tiempo cuando se deje de usar definitivamente el monolito.
Para resolver este problema, debemos aplicar el patrón “Capa de anticorrupción”.
La capa de anticorrupción puede implementarse en dos enfoques principales:
- Librería externa: Es una librería que incluimos en los proyectos y que tiene la lógica necesaria para realizar las llamadas a los sistemas externos.
- API especializada: Es un microservicio más que implementa un mecanismo de traducción de llamadas desde los microservicios que desean consultar la API y la API externa a llamar en sí.
El enfoque de librería externa tiene varios problemas:
- No es escalable cuando tenemos microservicios en diversas tecnologías (pues debemos implementar una librería por tecnología, lenguaje, etc).
- Aunque mejora y permite complejizar menos el código de los microservicios crea dependencia, pues serán necesarios cambios en algún momento.
La creación de un microservicio externo, que se encargue de la traducción de llamadas e invocación de las APIs de terceros, es una opción más recomendable. En esta variante la capa anticorrupción puede ser reemplazada a futuro (o de a poco) según estén disponibles nuevos microservicios que implementen las funcionalidades que aún se usan del monolito.
Algunas de las operaciones que se realizan en la capa anticorrupción pueden ser pasadas a un orquestador (En nuestro libro de patrones de una arquitectura microservicios abordamos este tema).
Consideraciones sobre la implementación de una capa anticorrupción
Existen algunos elementos que deben considerarse al llevar adelante la implementación de este patrón.
- La capa anticorrupción puede añadir latencia a las llamadas entre sistemas.
- Si el flujo de llamadas es alto, deben tenerse en cuenta mecanismos de escalabilidad en la capa y balanceo de carga entre múltiples instancias.
- Se debe valorar si crear una o varias capas de anticorrupción, en dependencia de los sistemas externos a interactuar, volumen de datos y tecnologías más adecuadas. La capa anticorrupción no solo debe pensarse en términos de HTTP REST, otros protocolos como colas de mensajes, gRPC, pueden ser parte.
- Se debe tener en cuenta el tema de la consistencia y la transaccionalidad en las operaciones.
- Si la capa anticorrupción servirá de fachada a un servicio en migración y a servicios de terceros que no variarán en el corto tiempo previsto, evalue crear dos o más sistemas independientes.
Hemos abordado en el artículo sobre los posibles escenarios de este patrón, sin embargo antes de concluir quería recomendarte el Patrón Strangler, que tiene ciertos puntos de contacto con este en particular.
