Un Modelo de EDA: Event Driven Architectures

Personalmente tuve la fortuna de estar presente en el ltimo evento de AWS re:invent 2022, y una de las cosas que ms me gust fu la Keynote del Dr. Werner Vogels. Es cierto que este es uno de los momentos ms esperados del evento, y uno de los favoritos de muchos... entre los que me incluyo...

The World is Asynchronous

Pero la particularidad de esta Keynote, para m, es que en un tiempo en que se resaltan los diferentes avances de la Inteligencia Artificial, o las Economas Desentralizadas con la Blockchain... El mensaje del Dr. Vogel en su Keynote fu como "volver a las bases" e inaugurar un nuevo tiempo, o un nuevo ciclo: en pleno 2022, afirmando que "The World is Asynchronous" y marcando el resurgimiento de las EDA: las Event-Driven Architectures

Y cuando pensamos en el "Asincronismo" y las "Arquitecturas Orientadas a Eventos" no solamente visualizamos a los a los microservicios y sus orquestaciones, o a las SOA, sino que fcilmente podemos seguir retrocediendo a ms de 20 aos atrs cuando en los lbros de Arquitectura de Software nos presentaban a patrones para desacoplar como el de "Publicacin/Subscripcin"

Patrones de Comunicacin en nuestro mundo

A veces me gusta pensar en nuestro patrn de comunicacin como personas, que, cuando hablamos, adems de comunicarnos con la persona a la que nos estamos dirigiendo, tambin estn todos los que nos escuchan. Y que depende de cada persona que pueda recibir al mensaje, el "prestar atencin" o "suscribirse", incluso alguien que podramos no querer que participe de la comunicacin...

Ese modelo de comunicacin de "publisher and subscriber", como refuerza Werner Vogels, es el predominante en nuestro mundo asyncrnico...

Dilemas de Comunicacin en el mundo de EDA

Pero Cmo implementar la comunicacin en un EDA?

Es decir, Que decisiones de diseo debemos tomar?. A la hora de publicar un evento, En dnde lo publico?En n nico Event-Bus para todo el sistema al que todos estn suscriptos?O en diferentes Event-Bus con alguna identidad funcional o tcnica que solamente algunos servicios se suscriben?Cmo se define el lmite de cada identidad funcional?, que seguramente, a medida que el sistema crezca se puede ir tornando ms difuso..

Y la siguiente pregunta derivada, sera: Que reglas debera establecer para gobernar a ese modelo de comunicacin asyncrnica? Y ah podemos estar en el dilema de elegir entre dos grandes aproximaciones para la comunicacin entre (micro)servicios: la Orquestacin y la Coreografa que vamos a repasar a continuacin:

Orquestacin vs Coreografa

Supongamos que en nuestro sistema cada (micro)servicio tiene su propia base datos y necesitamos un mecanismo para lograr la consistenacia entre las distintas bses de datos cuando en el sistema se realiza una transaccin, que por definicin, debe verse reflejada de forma completa en todos los (micro)servicios, o en su defecto, se cancelada o revierte para evitar problemas de inconsitencia.

En la aproximacin de "orquestacin" hay un servicio dedicado, como un director de orquesta, que dirige cmo debera cada servicio actualizar su estado.

En la aproximacin de "coreografa", no existe la figura de un director, pero todos los servicios conocen cmo deben _actualizar _a su estado interno al recibir el evento, de, por ejemplo, la ejecucin de una transaccin.

Dicho sea de paso, estas son dos posibles aproximaciones del patrn SAGA para micro servicios, y estn muy bien explicados en el sitio de "Microservice Architecture" de Chris Richardson

Cmo implementar un EDA?

Y en este punto, me gustara compartir mi experiencia en la implementacin de un EDA en un entorno acadmico, con la consigna de coordinar la integracin de ocho mdulos autnomos con su propio medio de persistencia.

A simple vista, un diagrama similar al siguiente:

Y se aplicaron las siguientes decisiones de diseo:

• Primero, la comunicacin se realiz a travs de un componente centralizado "EDA" que implementaba el patrn de "Publisher and Subscriber"

• Segundo, para la lgica de negocio que implicaba transaccionalidad entre distintos mdulos, se seleccion una estrategia "coreogrfica": es decir, la lgica de coordinacin para ejecutar una transaccin no est centralizada en un componente director, sino que cada interviniente de la transaccin conoce de qu manera deber actualizar a su estado interno ante la llegada del evento de la transaccin.

• En este punto, entedimos que se reduca el acoplamiento al no depender de un componente centralizado y que se fortalezca la independencia entre los mdulos al actuar siguiendo la filosofa de coreografa.

• Tambin, en este punto, entendimos que el sistema escalaba mejor, porque en el caso que un nuevo mdulo se incorpore al sistema, podra integrarse sin afectar a los dems e implementando su lgica de comportamiento en la coreografa, al estar cada componente actual y nuevo debilmente acoplado al sistema.

• Tercero, la publicacin de mensajes: para reducir al acoplamiento an mas entre los mdulos, se mantuvo la decision que cada cmponente publique sus mensajes y eventos en un tpico propio. Es decir, lo que un componente tiene que notificar hacia el resto de los sistemas, lo deja publicado en su propio tpico y no es su responsabilidad enviarle ese mensaje a otro mdulo que est interesado o necesitando recibirlo. Es responsabilidad del mdulo que necesita a los mensajes suscribirse a los tpicos de cada uno de los emisores con los que necesita interactuar.
  La responsabilidad de un emisor, por ejemplo, la aplicacin call-center, es solo de publicar sus mensajes en l topico que lleva su nombre "call-center". Luego, el mdulo que necesite, por ejemplo, reportar un ticket, o conocer su resolucin, ser el que se suscriba al tpio "call-center"

• Esa decicin reduce el acoplamiento, y permite que si, por ejemplo, se incorpora un nuevo mdulo de analtica de reclamos simplemente se incorpora como nuevo mdulo al sistema y se suscribe al tpico de "call-center" para hacer su lgica y generar sus resultados. Y el resto de los mdulos no se vieron afectados por su incorporacin.

En esta aproximacin, con estos tres pilares para organizar la comunicacin entre los servicios de una arquitectura orientada a eventos, con decisiones de integracin de componentes que favorecen el desacoplamiento (ej, elegir coreografa como medio de transaccionalidad entre servicios, y publicar los mensajes en solo el canal del propio mdulo) llev el proyecto a feliz trmino y permiti la integracin del ecsitema de los mdulos demostrando que las decisiones de diseo que se tomaron hacen posible la implamentacin de una EDA sin incrementar la complejidad en la forma de comunicacin de los servicios que integra.

Bueno, espero que nuestra experiencia a travs de un ejercicio acadmico de integracin en un arquitectura orientada a eventos, puede ser como referencia para identificar a un camino exitos, aunque segurametne existen otras alternativas de hacer las cosas de forma ms eficiente.

Muchos xitos!
Pablo

Referencias

• AWS re:Invent 2022 - Keynote with Dr. Werner Vogels
• Imagen Orquesta pixabay CC0
• Imagen Ballet Teatro Imperial pixabay CC0
• Microservices Patterns - SAGA
• Pattern-Oriented Software Architecture Volume 1: A System of Patterns
• Universidad UADE - FAIN