Implementando un Enterprise Service Bus con API Gateway y AWS Fargate

¿Cómo ahorrar costos de licenciamiento e infraestructura de un ambiente on-premises utilizando las mejores prácticas de DevOps?

Es común que las empresas estén en una constante búsqueda de alternativas que les permitan reducir sus costos de licenciamiento y de operación. Y en esta búsqueda resulta interesante tener opciones para cubrir funcionalidades de integración de un Bus Empresarial con servicios serverless de AWS.

En este post, vamos a ilustrar brevemente una solución que el equipo de Escala 24×7 ha implementado con los servicios de AWS para ayudar no solo a reducir los costos en el uso de licencias y de infraestructura on-premises, sino también a transformar una solución actual en una novedosa arquitectura de micro-servicios completamente libre de servidores usando Amazon API Gateway y AWS Fargate.

Visión general

A simple vista, un Enterprise Service Bus (ESB) no es más que una herramienta que facilita la integración de diferentes aplicaciones a través de un canal (bus) y que permite desacoplar los sistemas unos de otros.

Hace ya varios años, cuando surgió este tipo de arquitectura, se vendió como la solución a muchos desafíos. Sin embargo, en la actualidad, hablar de ESB conlleva a hablar de una cantidad significativa de recursos de hardware y de licenciamiento, además implica contratar especialistas con experiencia que son cada vez más difíciles de encontrar, haciendo que el costo de mantener un ESB sea sumamente alto y que no cualquier compañía pueda asumirlo.

Basado en lo anterior, las compañías que cuentan con un ESB en su infraestructura, tarde o temprano se enfrentarán a la necesidad de reducir sus costos de mantenimiento, ya sea simplemente para generar ahorros o para re-direccionar esos gastos e invertirlos en otros proyectos.

Primeros pasos

Supongamos un escenario en el que todos los servicios están alojados en un centro de datos on-premises y sus consumidores acceden a estos servicios a través de un firewall que se encarga de redirigir las solicitudes a los servicios web SOAP. Previa autenticación y autorización, ESB valida, procesa, transforma y orquesta las operaciones necesarias para devolver una respuesta al consumidor del servicio.

Dependiendo de la solicitud, el ESB se apoyaba en diferentes servicios locales para crear una respuesta y devolverla al consumidor.

El reto en este escenario, consiste en mover todos los servicios SOAP a la nube de AWS con el mínimo impacto para sus consumidores, tomando en cuenta que se deben mantener características como las siguientes:

• Conformidad con PCI DSS
• Confidencialidad
• Alta disponibilidad
• Escalabilidad
• Trazabilidad
• Flexibilidad
• Eficiencia

Una arquitectura completamente serverless

En este diseño, una decisión fundamental es que toda la arquitectura sea lo más serverless posible, no solo porque con una arquitectura de este tipo se reducen los costos de hardware y licenciamiento, sino también porque ya no es necesario preocuparse por aprovisionar y operar servidores.

Adicionalmente, en un escenario como este es normal que la seguridad sea un aspecto fundamental dentro de la arquitectura, por lo que se plantea mantener toda la comunicación de manera privada sin que la información viaje públicamente a través de internet. Es por esto que se involucran algunos servicios de AWS, como AWS VPN, Amazon Route 53 Resolver, VPC Endpoints y AWS Application Load Balancer, que permiten cumplir con esta necesidad.

En este sentido hay que tener presente también que los consumidores deben acceder a los servicios haciendo uso de nombres de dominio (en lugar de IPs), para ello es necesario hacer uso de Amazon Route53 Resolver. Este servicio se encarga de responder a los consumidores que están on-premises las consultas de nombres de dominio correspondientes a recursos desplegados dentro de AWS.

Adicionalmente, para poder acceder los servicios por medio de nombres de dominio se hace necesario configurar un Application Load Balancer al frente de API Gateway, dado que a la fecha no es posible usar nombres de dominio personalizados (custom domains) en API Gateways privados.

Por otra parte, para que API Gateway sea visible en un ambiente privado dentro de una VPC, es necesario configurar unos VPC Endpoints. Estos endpoints proveen IPs privadas por medio de las cuales se accede al servicio de API Gateway sin salir a internet.

Para lograr lo mencionado anteriormente e integrar el ALB con los VPC endpoints de API Gateway se debe hacer lo siguiente:

1. Crear un ALB para colocarlo frente a API Gateway;
2. Crear un Target Group conteniendo las IP privadas de las ENI del VPC endpoint de API Gateway;
3. Configurar el custom domain en API Gateway utilizando el dominio deseado;
4. Crear el dominio en una zona privada de Route53;
5. Apuntar el dominio recién creado al ALB mediante un registro de tipo Alias;
6. Crear certificados en ACM para el dominio creado y utilizarlos en la configuración del ALB y API Gateway.

Finalmente, el flujo de una petición a lo largo de esta arquitectura se puede ver en la figura 2 y se lleva a cabo de la siguiente manera:

1. El tráfico inicia desde la infraestructura on-premise y viaja a través de un túnel VPN que garantiza que la información se transmita de manera cifrada.
2. Amazon Route53 Resolver resuelve el nombre de dominio de los servicios hacia el Application Load Balancer (ALB).
3. El Application Load Balancer (ALB) recibe el request y lo envía a Amazon API Gateway usando comunicación cifrada en todo el camino mediante certificados TLS.
4. Por su parte API Gateway se encarga de controlar la demanda de las peticiones sobre los servicios, registrar logs y resolver la integración con las tareas de Fargate. Para garantizar que esta integración fuera privada se configuró un VpcLink que se conecta a un Network Load Balancer (NLB) encapsulando la comunicación dentro de la VPC.
5. Nuevamente Amazon Route53 permite la resolución de nombres hacia el NLB.
6. El NLB, envía la solicitud a un target group en donde finalmente es recibida por una tarea de Fargate en ECS. Esta tarea incluye funcionalidades de trazabilidad utilizando AWS X-Ray.
7. La tarea de AWS Fargate procesa la información y si necesita comunicarse con un servicio de backend, le envía el request apropiado, recibe la respuesta del backend, la procesa, crea la respuesta y la envía al cliente de vuelta por el mismo camino de la petición original.

Infraestructura como código

En AWS, la automatización, la escalabilidad y la re-usabilidad están directamente ligadas al uso de infraestructura como código, en donde el aprovisionamiento de la arquitectura se realiza a través de AWS CloudFormation y funciones AWS Lambda. En este sentido, uno de los retos más grandes está en diseñar una estrategia de aprovisionamiento de infraestructura que permitiera estandarizar y automatizar despliegues de recursos en AWS, según el ámbito de acción de los diferentes equipos de IT.

En la figura 3 se puede evidenciar un ejemplo de estructura que le permite a los equipos de infraestructura realizar sus ajustes sin afectar a los equipos de desarrollo y viceversa.

CI/CD

Desde un inicio es importante diseñar y desarrollar los servicios y aplicaciones siguiendo una estrategia que se acople a la integración y despliegue continuo (CI/CD). Para ello se puede tomar ventaja de las herramientas CI/CD provistas por AWS, usando AWS CodeCommit para manejar los repositorios de código, AWS CodeBuild para construir los contenedores Docker y almacenarlos en ECR, y finalmente AWS CodeDeploy para automatizar el despliegue de las aplicaciones. Todo esto orquestado a través de CodePipeline.

Para reducir el tiempo fuera de línea durante los despliegues, se pueden usar las técnicas suministradas por AWS, como despliegues Blue/Green que permiten el despliegue controlado de nuevas versiones sin afectar la disponibilidad de los servicios y teniendo la posibilidad de hacer roll-backs en caso de identificar una falla.

Independencia de servicios usando AWS Fargate

Para poder proveer una independencia de servicios, se debe desplegar cada servicio como una tarea de ECS sobre AWS Fargate. De esta forma un cluster ECS es el encargado de proveer la escalabilidad y la alta disponibilidad de tal manera que, si un servicio en particular requiere más recursos, el cluster se encargará de adicionarlos.

En esta tarea, un NLB trabaja en conjunto con el cluster ECS y ambos son los responsables de orquestar la escalabilidad sobre las diferentes zonas de disponibilidad habilitadas

‍Seguridad

La seguridad en estos escenarios siempre es primordial, por lo cual se deben seleccionar las herramientas y el diseño apropiado que ayude a cumplir con el reto de desarrollar un ambiente totalmente privado, donde solo el cliente tenga acceso a los recursos de AWS y donde toda la comunicación entre el cliente y los recursos de AWS esté cifrada.

Debido a esto, se propone una arquitectura de conformidad con PCI DSS, usando certificados TLS para garantizar una comunicación cifrada todo el camino desde el request hasta el response. Así mismo se utiliza AWS Cognito para administrar y manejar los controles de acceso a los servicios; Adicionalmente se incorpora AWS Parameter Store para almacenar en forma segura los parámetros de las aplicaciones, evitando así almacenar secretos en los contenedores.

Finalmente, es importante adoptar un entorno multi-cuenta que permita aislar los accesos de los diferentes equipos a los diversos ambientes existentes dentro de la organización, asegurando que solo las personas apropiadas tuviesen acceso a información sensitiva. Esto puede reforzarse con la creación de AWS Identities con accesos reducidos de tal forma que por ejemplo usuarios que tienen acceso total a la cuenta de desarrollo no tengan acceso a la cuenta de producción.

Resumen

En este post, hemos descrito brevemente una arquitectura para evolucionar unos servicios web desplegados en un bus empresarial on-premise hacia una arquitectura de microservicios completamente libre de servidores y sobre todo de conformidad con PCI DSS, haciendo uso de infraestructura como código, Amazon API Gateway, AWS Fargate y una serie de estrategias claves.