Blog de Amazon Web Services (AWS)

Integrando aplicaciones durante la modernización

Por Carlos Balcázar C., Senior Solution Architect, WWPS.

A las compañías que están iniciando o en pleno proceso de modernización de sus aplicaciones principales hacia nuevas arquitecturas como microservicios o nuevas tendencias como serverless, se les presentan dos retos, ¿cómo mantener funcionando las aplicaciones actuales mientras se realiza el proceso de modernización? y ¿cómo integrarlas entre ellas y con los microservicios de manera versátil mientras controlan los costos?

Para afrontar estos retos es importante entender que las aplicaciones a modernizar son monolitos (CRM, ERP, Billing, etc.) e incluso algunas de ellas son tan antiguas que no poseen interfaces de integración estándar. Teniendo en cuenta que el proceso de modernización de un monolito puede tomar varios años, las compañías a seguir trabajando con los monolitos mientras coexisten con los nuevos microservicios.

La coexistencia genera un nuevo reto: la necesidad de integración, esta crece exponencialmente en relación a la cantidad de aplicaciones, mientras 4 aplicaciones necesitarían 12 integraciones, 50 aplicaciones podrían requerir 2401 integraciones, y el reto se hace más complejo al integrar una gran cantidad de microservicios.  Es apremiante algún tipo de “plataforma” que me permita a los monolitos intercambiar información entre ellos y al mismo tiempo intercambiar información con los microservicios a medida que sean desplegados.

Algunas compañías han tratado de simplificar las integraciones usando un Enterprise Service Bus (ESB), que se define como “una plataforma de integración basada en estándares que combina mensajería, servicios web, transformación de datos y enrutamiento inteligente para conectar y coordinar la interacción de un número significativo de diversas aplicaciones a través de empresas extendidas con integridad transaccional» (Chappel, D. Enterprise Service Bus. O’Reilly, 2004), pero las opciones disponibles en el mercado son muy costosas a nivel de licenciamiento y el desarrollo/configuración de las integraciones es complejo e incluso algunas usan lenguajes de programación propietarios limitando la cantidad de integraciones a implementar.

En este blog se aborda una solución diferente, consiste en llevar una arquitectura de integración de microservicios, a cumplir con los requerimientos tradicionales de integración de Monolitos, teniendo en cuenta que un monolito se puede dividir en cientos de micro-servicios esta solución debe ser simple de implementar y de bajo costo por integración (por contrato)

Solución

A continuación, se presenta un diagrama arquitectura como único punto de integración usando servicios de AWS, el cual se explicará con base en las necesidades de integración de microservicios y monolitos

Esta nueva arquitectura, a nivel de microservicios, permite:

  • Cortos tiempo de entrega al mercado (TTM)
  • Autonomía en el desarrollo de los microservicios
  • Desacople (a nivel de fallas y tiempos de respuesta)
  • Integraciones síncronas y asíncronas
  • Seguridad de la información (ej. encriptación en transito y descanso)
  • Alta flexibilidad
  • Orquestación de mensajes.

A nivel de integración de aplicaciones empresariales (monolitos), la arquitectura debe cumplir con los diferentes patrones “patterns” que definen las funcionalidades necesarias para lograr ser el centro de flujo de información entre las aplicaciones.  Tomando como referencia “Enterprise Integration Patterns (EIP)” https://www.enterpriseintegrationpatterns.com/patterns/messaging/,  para el propósito de este blog, se compara las capacidades de la arquitectura contra los patrones de integración empresarial:

Categoría / Pattern category

Patrón / Patterns Contempla en la arquitectura  Explicación corta

Messaging  Endpoints

Messaging Endpoint SI

En la arquitectura se plantean endpoint síncronos y asíncronos: 1) Amazon API Gateway (Expone Rest, https y websocket), 2) JMS con Amazon SQS (Simple Queue Service) y 3) Amazon SNS permite suscripción/publicación

Messaging Gateway SI

Todos los mensajes son enviados a Amazon EventBridge independiente del endPoint usado.  Cuando el EndPoint usado es Amazon API Gateway, es posible configurar algunas acciones por defecto, como publicar la estructura del API.

Messaging Mapper SI Amazon EventBridge puede seleccionar los mensajes que cumplan con ciertos criterios para luego iniciar un AWS step function y este puede mover datos entre dominios si el contenido del mensaje esta en formato JSON, en caso de ser otro formato, AWS StepFunctions deberá orquestar un Lambda para que haga este movimiento
Transactional Client NO

Polling Consumer SI Cuando una aplicación requiere consumir los mensajes vía REST y HTTPS se debe conectar al API Gateway e indicar que método necesita y recibirá el mensaje a demanda extraído de una de las colas de salida (Amazon SQS) por medio de una función de AWS Lambda.
Event-driven Consumer SI

Cuando la aplicación esta lista para recibir los mensajes, tiene 4 formas de hacerlo, vía JMS conectado a la cola de salida Amazon SQS, vía SDK de la cola de salida de Amazon SQS, vía Lambda se consume un Web Service publicado por la aplicación o se suscribe a un tema en Amazon SNS para recibir el mensaje cada vez que es publicado

Competing Consumers SI

Cuando la aplicación destino no puede procesar los mensajes tan rápido como los genera el origen, es posible crear múltiples colas FIFO de salida (Amazon SQS) para que el destino pueda procesar los mensajes en paralelo.  Si el destino no tiene la capacidad de procesar los mensajes en paralelo, es posible forzar la entrega del siguiente mensaje solo si el anterior fue completamente procesado usando AWS Stepfunctions

Message Dispatcher SI Cuando el mensaje tiene que ser procesado por varios destinos, en cierto orden o coordinación, Amazon EventBridge es capaz de iniciar un AWS Step Function, y este se encargará de orquestar el orden y condiciones de ejecución de las entregas de los mensajes por medio de múltiples colas de salida (Amazon SQS)
Selective Consumer PARCIAL

La aplicación que consume, no puede seleccionar los mensajes, pero si la cola de salida (Amazon SQS) de la cual obtiene los mensajes.  A partir del manejo de múltiples colas de salida, es posible segmentar los mensajes que el consumidor recibe

Durable Subscriber

SI

Cuando el suscriptor de mensajes no esta escuchando, él podrá cuando retorna extraer el mensaje de la cola de salida (Amazon SQS) en cualquier momento (hasta 14 días).   Tener en cuenta que existe una cola para mensajes no entregados “Amazon SQS dead letter queue» que permite reprocesar la información mas adelante.

Idempotent Receiver

SI

Si el mensaje se genera varias veces, pero se debe entregar solo una vez, es posible crear reglas de deduplicación de mensajes en AWS lambda, coordinadas por AWS Step Function y basadas en los históricos almacenados

Service Activator

NO

Message  Construction

Message

SI

El canal lo componen dos servicios: Amazon EventBridge (event bus) y Amazon SQS (administración de colas). El mensaje es enviado por el generador a alguno de los endpoint de entrada, luego ingresa a Amazon Event Bridge que de acuerdo a las reglas de enrutamiento lo envía a una cola de salida (Amazon SQS) de donde es entregado al receptor vía alguno de los endpoint de la arquitectura o enviado (vía AWS Lambda) al destinatario

Command Message

SI

En la arquitectura los mensajes de tipo comando se manejarán como un cualquier mensaje, dependerá del receptor interpretarlo como comando.

Document Message

SI

Nativamente Amazon Event Bridge solo puede transportar mensajes hasta 256 KB incluido estructura, en el caso de mensajes de mayor tamaño, serán almacenados de manera temporal en Amazon S3, y se trasportará vía Amazon EventBridge y Amazon SQS solamente los identificadores y el encabezado de los mensajes.

Event Message

SI

Cuando el mensaje tiene que ser procesado por uno o varios destinos, Amazon EventBridge es capaz de iniciar un AWS Step Function, y este se encargará de entregar el mensaje a varias colas (Amazon SQS) las cuales pueden ser “standard» o «FIFO»

Request-Reply

PARCIAL

Cuando la aplicación que genera el mensaje requiere una respuesta de la aplicación receptora (integración síncrona), vía HTTPS o REST, es posible que API Gateway entregue una respuesta genérica e indicando donde la aplicación generadora puede buscar la respuesta.   También es posible que vía AWS Lambda se consuma un WebService y se envía la respuesta directamente

Return Address

PARCIAL

Cuando hay varios generadores de mensajes con un mismo destino, el mensaje de respuesta se enrutará gracias al almacenamiento histórico en Amazon DynamoDB en donde se podrá identificar el origen del mensaje y enrutar la respuesta a la cola (Amazon SQS) correspondiente

Correlation Identifier SI

Para lograr la correlación entre mensajes y respuestas, se usarán dos identificadores, el primero es originID que debe ser parte del mensaje enviado por aplicación generador y el otro es “RequestID», es identificador único asignado al mensaje cuando este es recibido por el endPoint.  Estos dos IDs acompañaran al mensaje mientras viajen en la arquitectura

Message Sequence PARCIAL

Cuando la aplicación receptora no es capaz de procesar mensajes de gran tamaño, Amazon EventBridge puede iniciar un AWS Step Function que coordine funciones AWS Lambdas para dividir el mensaje en unos mas pequeños y entregarlos a la cola correspondiente (Amazon SQS).  Estos mensajes deberán conservar el «RequestID» y el originID del mensaje original, igualmente se deberá indicar que el mensaje fue dividido y un identificador de la secuencia de la cual esta compuesto.

Message Expiration

PARCIAL

Aunque el generador del mensaje no puede establecer el vencimiento (expiration) de cada mensaje, es posible configurar el vencimiento en la configuración de la cola de salida (Amazon SQS) de tal manera que, si el mensaje no es tomado/eliminado de la cola, se mueve a la cola «dead-letter queue»

Format Indicator

PARCIAL

Cuando el generador del mensaje requiere indicar cual es el formato con el cual debe ser tratado el mensaje.   Amazon EventBridge recibe todos los mensajes, existe unas reglas que permiten filtrar e iniciar un Amazon Step Function, este podría usar diferentes formatos para procesar el mensaje de pendiendo de un valor proveniente en el mensaje original

Messaging  Channels

Message Channel SI

El canal lo componen dos servicios Amazon EventBridge (event bus) y Amazon SQS (cola de salida). El mensaje es enviado por el generador a alguno de los endpoint de entrada, luego ingresa a Amazon Event Bridge que de acuerdo a las reglas de enrutamiento lo envía a una cola de salida (Amazon SQS) de donde es entregado al receptor vía alguno de los endpoint de la arquitectura o enviado (vía AWS Lambda) al destinatario directamente

Point to Point channel

SI

Es posible garantizar que solo un destinatario reciba el mensaje cuando Amazon EventBridge enruta el mensaje solo a una cola de tipo FIFO en Amazon SQS.

Publish-Subscribe Channel PARCIAL

Los receptores de los eventos pueden suscribirse a un tema «topic» en el servicio Amazon SNS de manera que reciban el mensaje cuando se realice una publicación.  En la arquitectura es posible realizar esto cuando la cola de salida (Amazon SQS) publica el mensaje en el tema “topic» de Amazon SNS.

Datatype Channel SI

Cuando el receptor recibe múltiples mensajes del mismo generador (origen) pero los mensajes (tipo / estructura) son diferentes, puede diferenciarlos gracias a la cola de salida (Amazon SQS) en la cual Amazon EventBridge lo envió.

Invalid messages channel SI

Cuando AWS Lambda envía un mensaje a un receptor, este puede decidir si el mensaje es valido o no, en la función sería necesario configurar un procedimiento para mover el mensaje a una cola de mensajes inválidos (Amazon SQS)

Dead letter channel SI

Cuando un mensaje no puede ser enviado o no es reclamado por el receptor desde la Cola (Amazon SQS), es movido a una cola llamada Dead letter queue.

Guaranteed Delivery PARCIAL

En la arquitectura es posible persistir en la entrega del mensaje solo cuando el mensaje ya se encuentra en Step Function.  La arquitectura basa la garantía de entrega en el compromiso de disponibilidad de SQS que es del 99,9%.

Channel adapter SI

En la arquitectura se plantean endpoint síncronos y asíncronos: 1) Amazon API Gateway (Expone Rest, https y websocket), 2) JMS con Amazon SQS (Simple Queue Service) y 3) Amazon SNS permite suscripción/publicación.   Si el mensaje debe ser entregado vía un API o WebService es posible enviarlo usando una función «AWS Lambda»

Messaging Bridge NO

Message Bus SI

En la arquitectura el servicio Amazon EventBridge se comporta como un bus, gracias a su componente “EventBus».  Es importante aclarar que se hace una analogía entre eventos y mensajes.

Message Routing

Pipes and Filters SI

Es posible ejecutar tareas complejas sobre el mensaje, cuando Amazon EventBridge inicia un AWS step function, es posible orquestar la ejecución de funciones AWS Lambda que realicen actividades complejas como desencripción, deduplicación, transformación, filtrados, etc.

Message Router SI

Usando las reglas de enrutamiento de Amazon Event Bridge es posible enviar mensajes a diferentes colas de salida o incluso a AWS StepFunction para su procesamiento.

Content-Based Router SI

Las reglas de enrutamiento de Amazon EventBridge puede filtrar los mensajes basados en la información de los mismos.  Si la información que permite decidir el destino esta en un formato diferente a JSON, será necesario realizar la conversión a JSON.

Message Filter SI La arquitectura presenta dos niveles de filtrado para los mensajes entrantes:
1. Amazon API Gateway filtrará los mensajes mal formados o con problemas de protocolo.
2. Amazon Event Bridge filtrará los mensajes que no cumplan con ninguna regla.
Dynamic Router NO

Recipient List PARCIAL

Una vez entregado el mensaje por Amazon EventBridge a AWS Step Function, se construye una lista de receptores a quienes se les envía el mensaje.  Si el numero de destinatarios es menor a 5, es posible que Amazon EventBridge envíe directamente el mensaje usando 5 colas (Amazon SQS)

Splitter SI Una vez Amazon EventBridge entrega el mensaje a AWS Step Function, se puede orquestar la división del mensaje original en unos mensajes que solo contengan un fragmento de la información original, para que finalmente cada uno sea a una cola diferente.  (Amazon SQS)
Aggregator PARCIAL

Usando AWS Step Functions es posible orquestar funciones AWS Lambda para unir la información del mensaje con información proveniente de otra fuente.  Cuando se desea unir la información de dos mensajes, se usará Amazon DynamoDB/ Amazon S3 para almacenar de manera temporal los eventos y así poder hacer operaciones entre varios mensajes

Resequencer NO
Composed Message Processor SI

Basado en el patrón “splitter» (dividir y enrutar) y el patrón «Aggregator” (unir varios mensajes), es posible procesar varios mensajes de manera compleja y paralela usando AWS Lambdas orquestados por AWS Step Functions, y finalmente unirlos para entregar un solo mensaje al destino.

Scatter-Gather SI Usando Amazon EventBridge, Amazon SQS y Amazon SNS es posible entregar un mensaje a múltiples destinos en paralelo, y en el caso de este patrón es opcional de cada destino dar respuesta.  Usando AWS Step Functions es posible esperar la respuesta de los destinos y agruparla en un solo mensaje de respuesta para el generador inicial.
Routing Slip PARCIAL

Usando las reglas de Amazon Event Bridge es posible enviar el mensaje a diferentes AWS StepFunctions quienes orquestarán AWS Lambdas de manera que el procesamiento del mensaje se asimile a los pasos en un flujo de trabajo.   El flujo se basa en condiciones de acuerdo a los datos del mensaje.

Process Manager SI En la arquitectura quien ejecuta el patrón de «Process Manager» es la combinación entre las reglas de Amazon EventBridge y las máquinas de estado de AWS Step Functions.
Message Broker SI

Usando las reglas de Amazon Event Bridge y las colas de Amazon SQS es posible manejar, enrutar y desacoplar la comunicación entre origen y destino (mensajes)

System Management

Control Bus SI AWS tiene una consola de administración unificada donde es posible configurar todos los servicios presentados en la arquitectura.  Para controlar y visualizar el estado de los mensajes, su procesamiento y las colas, es posible usar la consola de AWS Step Function y los servicios Amazon CloudWatch y AWS CloudTrail
Detour SI

Usando las reglas de Amazon  EventBridge es posible desviar los mensajes a una ruta alterna donde se  realiza el seguimiento o algún tipo de control, finalmente se puede enviar a  la cola de salida o alguna cola de prueba (Amazon SQS)

Wire Tap SI Para los mensajes que solo  pueden tener un destino y se debe entregar una sola vez, se pueden usar  Amazon Event Bridge y 2 colas FIFO (Amazon SQS) para garantizar una sola  entrega al destino y al mismo tiempo atrapar una copia de los mensajes para  tareas de depuración o análisis
Message History SI

Todos los mensajes deberán ser  almacenados en Amazon DynamoDB de manera temporal, se habilitarán las  funcionalidades de backup y se ejecutará   limpieza periódica.  En caso de  mensajes de gran tamaño, el contenido será almacenado en Amazon S3 y solo los  identificadores y el encabezado serán almacenados en Amazon DynamoDB

Message Store

SI

Todos los mensajes deberán ser  almacenados en Amazon DynamoDB de manera temporal, se habilitarán las  funcionalidades de backup y se ejecutará   limpieza periódica.  En caso de  mensajes de gran tamaño, el contenido será almacenado en Amazon S3 y solo los  identificadores y el encabezado serán almacenados en Amazon DynamoDB

Smart Proxy

PARCIAL

Una vez el mensaje llega a la  arquitectura, se obtiene la información del generador del mensaje y luego  usando AWS Step Función y AWS lambda se entrega la respuesta al mismo  origen.  De igual manera, es posible  que el mensaje de respuesta contenga la dirección a quien se desea entregar el  mensaje o cola de salida en la cual se debe dejar el mensaje.

Test message SI Es posible inyectar mensajes de  pruebas directamente en el endpoint de entrada (Amazon SQS o Amazon API  Gateway), se debe definir una marca (campo) en los mensajes para que estos  sean enviados a las colas de salida (después de procesamiento) especialmente  destinadas a monitoreo en lugar de las colas de salida de producción (Amazon  SQS)
Channel Purger PARCIAL

En la arquitectura se presenta  un canal como la combinación entre Amazon Event Bridge (Event Bus) y Amazon  SQS (Queue).  Vía AWS console o AWS CLI  es posible purgar las colas de Amazon SQS, en caso de ser necesario garantizar  que las colas estén vacías.

Message  Transformation

Message Translator SI

Amazon EventBridge puede filtrar  los mensajes que requieran algún tipo de transformación e iniciar un AWS StepFunction para que orqueste funciones AWS Lambda para transformar el mensaje  en el formato de destino, luego es colocado en la cola de salida (Amazon  SQS).  Las funciones AWS Lambda puede  ser desarrolladas por defecto en 7 lenguajes de programación.

Envelope Wrapper SI

Idealmente todos los mensajes  deben tener 2 secciones, un encabezado y el contenido.   Siendo el encabezado toda la información  necesaria para identificar y clasificar los mensajes y el contenido es la  carga útil del mensaje.  Usando AWS  KMS, se administra las llaves con las cuales se puede encriptar/desencriptar  el contenido del mensaje cuando sea necesario

Content Enricher

SI

En las reglas de Amazon  EventBridge se pueden filtrar los mensajes que requieran algún tipo de  enriquecimiento, estos mensajes inician un AWS Step Function, el cual  orquestará una función AWS Lambda para enriquecer los mensajes basados en  cualquier base de datos, como por ejemplo Amazon DynamoDB,

Content Filter

SI

Usando AWS Step Functions es  posible filtrar/seleccionar parcialmente el contenido del mensaje cuando está  en formato JSON, en caso que el contenido del mensaje tenga otro formato, AWS  Step Functions orquestará funciones AWS Lambda para filtrar/seleccionar  solamente la información del mensaje original que se requiere entregar a la  cola de salida (Amazon SQS)

Claim Check PARCIAL

Nativamente Amazon Event Bridge  solo puede transportar mensajes hasta 256 KB incluido estructura, en el caso  de mensajes de mayor tamaño, serán almacenados de manera temporal en Amazon  S3, y se trasportará vía Amazon EventBridge y Amazon SQS solamente los  identificadores y el encabezado de los mensajes.

Normalizer SI

Amazon EventBridge puede filtrar  los mensajes que requieren algún tipo de normalización e inicia un AWS Step  Function para que orqueste funciones AWS Lambda y finalmente el mensaje  normalizado es colocado en la cola de salida.   Las funciones AWS Lambda puede ser desarrolladas por defecto en 7  lenguajes de programación.

Canonical Data Model SI

En la arquitectura se plantea  que los mensajes sean convertidos a formato JSON, con dos secciones, encabezado y contenido.  Este formato  se usará como canónico cuando la información viaje entre los servicios de  AWS.

Conclusión

La arquitectura presentada puede ser el único punto de integración entre las aplicaciones monolíticas, los microservicios y entre aplicaciones y microservicios.    Es 100% serverless (sin administración de servidores), lo que permite manejar los costos orientados a la transacción, en este caso el mensaje, el cual puede ser alrededor de USD 0,0006 por mensaje, sin costos adicionales por licenciamiento.  Permitiendo a las compañías orientar sus costos a la unidad de venta con base en su modelo de negocio.

A nivel de los patrones de integración, de los 61 patrones, la arquitectura se alinea con 42 completamente, 14 patrones parcialmente y solo quedando por fuera 5 patrones, lo cual resulta muy útil durante la modernización de aplicaciones e incluso en el futuro cuando todas las aplicaciones sean microservicios.

Para mayor información de los servicios incluidos en la arquitectura, a continuación, se presentan algunos links de interés:

Amazon SQS: https://aws.amazon.com/sqs/

Amazon API Gateway: https://aws.amazon.com/api-gateway/

AWS Lambda: https://aws.amazon.com/lambda/

Amazon DynamoDB: https://aws.amazon.com/dynamodb/

Amazon EventBridge: https://aws.amazon.com/eventbridge/

Amazon S3: https://aws.amazon.com/s3/

AWS Step Functions: https://aws.amazon.com/step-functions/

Amazon SNS: https://aws.amazon.com/sns/

AWS Key Management Service (KMS): https://aws.amazon.com/kms/

Amazon CloudWatch: https://aws.amazon.com/cloudwatch/

AWS CloudTrail: https://aws.amazon.com/cloudtrail/


Sobre el autor

Carlos Balcazar es Arquitecto de Soluciones, ha apoyado a múltiples organizaciones de gobierno en su viaje a la nube.  Igualmente ha liderado empresas de tecnología en modelos ISV.

Revisores 

Ricardo Castañeda es consultor de Servicios Profesionales en AWS. Ingeniero de software, entusiasta del cómputo de la nube y practicante de jiujitsu.

Germán Ruiz es Arquitecto de Soluciones de Partners en Amazon Web Services para el Sector Público en Centro América y el Caribe, apoyándolos en su camino a la innovación y adopción tecnológica.