Importancia de arquitecturas asíncronas en los sistemas distribuidos.

Por Rodrigo Cabrera, Sr. Solutions Architect en AWS.

Este blog forma parte de una serie donde hablaremos de temas distintos sobre arquitecturas basadas en eventos, Domain Driven Design y patrones que se utilizan en este estilo de arquitectura.

“The world is asynchronous” así comenzaba su Keynote Werner Vogels en el re:invent 2022, y vaya que tiene razón. La necesidad de que todos los aplicativos sean síncronos, muchas veces ocasionan sistemas altamente acoplados, costosos y poco escalables. Al mismo tiempo genera que no podamos innovar y ser ágiles como el negocio lo necesita.

Pongamos el siguiente escenario en la mesa, Any Company es una empresa dedicada a la creación de campañas de donación para distintas causas de beneficencia. El proceso es sencillo: Creas una causa, se genera una cuenta bancaría, y una liga para poder donar a esta causa. Existen varias validaciones que se tienen que hacer antes de activar la campaña. Que incluyen llamados a APIs externos, validación de documentos y de datos. El problema actual de Any Company es que 30% de las creaciones de cuenta mandan time out por alguno de los sistemas que consume al hacer el alta de la causa. Haciendo que pierdan varios millones de dólares a causa de esto.

En este escenario vemos que no hay una necesidad que los sistemas se comporten de manera síncrona. Ya que el tiempo que tome en crearse la campaña, los llamados a los APIs y las validaciones, pueden correr sin que el usuario final tenga que esperar a que terminen estos. Así podemos implementar elementos arquitectónicos para transformar de un flujo de trabajo síncrono a uno asíncrono, y poder traer valor al negocio (ya no perder 30% de la creación de las campañas).

A continuación, mostraremos 3 arquitecturas: La actual, donde un sistema de 3 capas con aplicación actualmente síncrona. Una temporal, donde reduciremos el ratio de errores al volver el sistema asíncrono agregando una cola de mensajes y un servicio que nos ayuda a enviar notificaciones a los clientes. Por último, una arquitectura mucho más desacoplada con servicios que pueden escalar de manera independiente.

Arquitectura actual:

Arquitectura temporal:

La arquitectura temporal nos ayudará a ya no perder clientes por tener un diseño altamente acoplado, con elementos como Amazon Simple Queue Service (SQS) y Amazon Simple Notification Service (Amazon SNS) podemos transformar a una arquitectura asíncrona y darle valor al negocio de manera rápida. Sin embargo esta arquitectura aún tiene varios retos como poca escalabilidad, dificultad en implementar nuevos sistemas, y una difícil estructura que no permite innovar al negocio si así lo quisieran. Para esto podemos trabajar en implementar una arquitectura basada en eventos, la cuál hablaremos en otra serie de blogs más adelante, y que nos ayudará a tener elementos desacoplados entre sí que permitirán crecer al negocio, innovar y tener equipos independientes, a continuación vemos una imagen con la arquitectura propuesta y más adelante hablamos de los servicios utilizados en esta.

Amazon API Gateway:

Amazon API Gateway es un servicio completamente administrado que facilita a los desarrolladores la creación, la publicación, el mantenimiento, el monitoreo y la protección de API a cualquier escala. Con API Gateway, puede crear API RESTful y API WebSocket que permiten aplicaciones de comunicación bidireccional en tiempo real. En este caso nos ayuda como primer paso para desacoplar nuestra aplicación del backend y poder inyectar directamente a la cola de mensajes o SQS.

Amazon Simple Queue Service (SQS):

SQS es una cola de mensajería totalmente serverless que ayuda en el desacoplamiento de los servicios. Además, de ayudar a quitarle carga al backend, ya que tu puedes controlar la velocidad en que se procesa la cola de mensajes. Evitando causar una sobrecarga de los servicios lo que puede llevar a lentitud, errores o la caída completa del sistema.

Amazon Simple Notification Service (SNS):

SNS es un servicio completamente serverless que te ayuda a implementar arquitecturas Pub/Sub de manera fácil y ayuda a hacer fan-out (dispersión) de tus notificaciones desde tus aplicaciones por medio de SMS, correos electrónicos, push notifications o directamente a otros servicios de AWS. En esta arquitectura este servicio nos ayuda a avisarle al usuario final que su campaña fue creada con éxito, o en caso de que fuera rechazada, por alguna validación o fallo en algún servicio después de N re-intentos, el cliente reciba una notificación.

Arquitectura final:

En la arquitectura final, tomamos otros elementos que nos ayudan a tener una arquitectura poco desacoplada, como un orquestador y un coreógrafo, la imagen contiene los servicios de AWS usados y más adelante una breve explicación de estos. Lo que nos permite agregar nuevas funcionalidades e innovar con mayor rapidez enfocándose a lo que realmente le da valor al negocio, de la misma forma cada uno de sus elementos pueden escalar de manera independiente. En este blog solo vemos la arquitectura. Sin embargo, no estamos hablando de los diferentes sub-dominios del negocio y aún no limitamos los diferentes contextos del sistema ni la forma en que estos interactúan, todo esto lo hablaremos en el siguiente blog. Otro elemento importante que mencionar es que esta arquitectura no tiene que ser la arquitectura “definitiva”, existen múltiples servicios, frameworks, herramientas, etc. que harán que nuestra arquitectura tenga que evolucionar. Lo importante es que mientras el sistema de valor al negocio, este tiene que poder tener pequeñas liberaciones incrementales, donde sea un proceso de despliegue automatizado, sin fricción y sin dolor, más adelante platicaremos sobre arquitecturas evolutivas, que son y como pueden ayudarnos a conseguir esto.

AWS Step Functions:

Generalmente los flujos de negocio no son de un sólo paso, existen múltiples pasos que generalmente llevan un orden para ser ejecutados, y así poder generar acciones como “creaCampaña”, “actualizaCampaña”, entre otros.

Nuestro servicio serverless que ayuda a orquestar microservicios, o múltiples servicios de AWS para poder generar estas cargas de trabajo es Step Functions, Step Functions usa ASL (Amazon State Language) o una interfaz sencilla de usar conocida como workflow studio, donde puedes generar tus flujos con un simple drag&drop.

Amazon Event Bridge

Amazon Event Bridge es un ruteador de eventos serverless, este te permite generar buses de eventos que serán usados en tu aplicación para poder mapear tus múltiples eventos basados en reglas que se pueden configurar con formato JSON, y estas pueden ser tan específicas como tu negocio lo requiere. Con este servicio podemos desacoplar los productores de eventos (puede ser el B2C o B2B) y los consumidores de esto (los múltiples sub-dominios que interactúan con este evento).

Amazon DynamoDB

DynamoDB es una base de datos NoSQL de clave-valor sin servidor y completamente administrada que está diseñada para ejecutar aplicaciones de alto rendimiento a cualquier escala. Usando una base de datos como DynamoDB también estamos desacoplando nuestra capa de datos con la aplicación, lo cual nos permite seguir las mejores prácticas, y no tener un cuello de botella que sería con una base de datos transaccional.

Amazon Route 53

Amazon Route 53 es un servicio web de sistema de nombres de dominio (DNS) escalable y de alta disponibilidad.

Amazon CloudFront

Amazon CloudFront es un servicio de red de entrega de contenido (CDN) creado para ofrecer un alto rendimiento, seguridad y comodidad para los desarrolladores.

Conclusión:

Como aprendimos en este blog, las aplicaciones modernas dan agilidad a las áreas de T.I. para poder generar despliegues incrementales de manera rápida y constante, ayudando a que el negocio no se detenga a generar nuevas oportunidades que generen ingresos para la empresa. De la misma forma vimos que podemos atacar el problema de manera más rápida sin necesidad de tener un “producto final” para liberarlo, lo cual nos podría llevar varios meses mientras la compañía sigue perdiendo dinero, clientes y lealtad de estos.

Acerca del autor:

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.

Revisores

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.

Armando Barrales es arquitecto de soluciones especialista en modernización en AWS México, ha trabajado en áreas de TI por más de 15 años con clientes de industrias, como FSI, CPG, Manufactura, Medios y Entretenimiento, Salud entre otros. Actualmente ayuda a clientes de Latinoamérica a modernizar sus soluciones para dar valor al negocio y a sus clientes a corto, mediano y largo plazo.