Arquitectura orientada por eventos, una breve introducción

Este post da una breve introducción a la arquitectura de software orientada por eventos y su finalidad presentando tres conceptos claves a tener en cuenta: Contratos, Message Brokers y maquinas de estado; los ejemplos se dan hablando sobre micro servicios pensando en la implementación de la arquitectura para aplicaciones de Backend.

Empecemos con una definición formal:

“Una arquitectura orientada por eventos es un patrón de diseño el cual permite a un conjunto de sistemas comunicarse entre si de forma reactiva mediante la publicación y el consumo de eventos, los cuales se pueden interpretar como cambios de estado de objetos.”

Ahora veamos como los contratos, message brokers y maquinas de estado trabajan con esta definición.

Contratos de Servicios

… Permite a un conjunto de sistemas comunicarse entre si …

Un contrato es una definición o documento que permite a otro ente, ya sea otro micro servicio, trabajo programado o cliente(app) conocer la información a enviar para comunicarse con él y lo que recibirá a cambio, como su nombre lo indica el contrato es el acuerdo entre el servicio y sus suscriptores

Los sistemas pueden ser de diferentes tamaños y categorías según sus funciones, sus dominios, etc, es importante definir una categoría con la cual dividirlos y definir un alcance claro para cada uno, un sistema puede ir desde una clase con una tarea especifica compartiendo una base de código con otros pequeños sistemas, hasta un gran sistema el cual en su interior puede estar compuesto por varios servicios que al realizar el trabajo en conjunto cumplen su función.

Para nuestro caso de uso vamos a entrar en detalle hablando de micro servicios, por lo tanto para nuestra definición y posteriores ejemplos hablaremos de un grupo de micro servicios los cuales se comunican entre si, cada micro servicio cumple una tarea particular y debe tener una entrada y una salida clara, esta información es conocida como el contrato.

Message Broker y el Patrón Observador

… De forma reactiva mediante la publicación y el consumo de eventos …

Teniendo claro los micro servicios y los contratos, nace la necesidad de que los servicios se comuniquen entre si ya que los micro servicios no siempre se exponen de cara al usuario, es muy común que los sistemas se comuniquen para mantener la integridad ya sea en datos o en ejecución de procesos determinados, hay diferentes estrategias para comunicar sistemas como lo son:

• Rest
• RestFull
• Web Sockets
• Long Polling
• Event Driven
• Soap
• ETC …

Se busca elegir la estrategia adecuada para solucionar el problema de negocio, como este post se trata de arquitecturas orientadas por eventos entonces nos enfocaremos en los tipos de problemas que puede resolver una arquitectura con eventos como por ejemplo lo seria la actualización de marcadores y de posiciones en tiempo real de la tabla de posiciones de SOME GAME, este problema es ideal para una arquitectura orientada por eventos ya que el puntaje se modifica ante algún evento remoto lanzado por un sistema que maneje el juego como tal, además la ubicación de un jugador en la tabla de posiciones puede cambiar ante el evento de modificación de puntaje de X(mínimo uno) jugadores.

Un sistema diseñado para reaccionar a eventos se ejecutará independiente del tiempo de ejecución de quien haya desencadenado el evento, del mismo modo el sistema que haya desencadenado el evento está en la facultad de continuar su ejecución sin esperar por el resultado de la ejecución del sistema que corre en otro plano(no confundir con ejecución en segundo plano de sistemas operativos).

La capacidad de ser reactivo se da gracias al patrón de diseño observador el cual es un patrón de comportamiento, encargándose de la comunicación de mensajes de uno a muchos ante un cambio de estado.

Para términos prácticos, el patrón observador se ve implementado en los Messages Brokers, los cuales son sistemas intermedios que se encargan de la traducción y el broadcasting de los mensajes hacia sus suscriptores, estos sistemas se pueden ver como el medio de comunicación entre los sub sistemas dando la habilidad de publicar eventos a toda la red de sistemas ante algún cambio de estado sin afectar su flujo natural y también de registrarse en los eventos que realmente necesiten los cuales funcionarían como disparadores para la ejecución del sistema suscriptor.

Maquinas de estados finitos

… Los cuales se pueden interpretar como cambios de estado de objetos. …

En las secciones anteriores se habla de que un evento se dispara ante el cambio de estado de un objeto, los objetos tienen atributos y habilidades, entre sus atributos dependiendo del objeto se puede tener una lista de estados entre los cuales siempre tendrá un estado actual (Current) y la habilidad de cambiar a otro estado listado, el estado puede tener uno o varios estados siguientes(Next) dependiendo de la lógica de negocio y parámetros recibidos y un estado anterior(Prev), Los eventos son publicados en el Message Broker en el momento que ocurre un cambio de estado desde Current hacia cualquier otro estado posible del objeto, a esta facultad se le conoce como maquina de estados finitos.

Una maquina de estados finitos tiene un número predeterminado de estados posibles, siempre tiene un estado inicial y el estado siguiente puede variar dependiendo de los parámetros que reciba la maquina.

Pasos a seguir

• Si estás aquí por que estas pensando en un problema especifico primero debes decidir si una arquitectura orientada por eventos es la mejor solución al problema de negocio que tienes en mente
• Por otro lado si estás por curiosidad técnica encuentra un problema pequeño que con el cual puedas poner en práctica esta arquitectura.
• Elige una infraestructura sobre la cual desarrollar el proyecto, puede ser en la nube obteniendo provecho de los trials de AWS, Azure, Google Cloud, Digital Ocean, Etc; o en su lugar configurar entornos locales para emular varios micro servicios y configurar un message broker para su comunicación, lo importante es documentarse de la mejor manera y en lo posible para iniciar trabajando con infraestructuras conocidas.
• Y como paso final Iterar, sufrir, aprender, corregir y volver a iterar :)

Conclusiones

Los sistemas orientados por eventos tienen una gran cantidad de casos de usos y pueden entrar como complemento de un sistema existente, un sistema no tiene que ser diseñado desde el principio orientado por eventos, puede diseñarse una solución paralela para quitar procesamiento adicional o desarrollar nuevas funcionalidades sin afectar el core del sistema existente.

Esta arquitectura es muy útil en el desacoplamiento de sistemas monolíticos y en la creación de sistemas basados en micro servicios.

Es muy importante trabajar ordenadamente en el diseño de la arquitectura a levantar antes de comenzar la implementación ya que permite la definición concreta de los participantes del sistema, sus comunicaciones, sus posibles estados y suscripciones además de prevenir caer en el anti patrón Gran bola de lodo (big ball of mud) ya que como se puede observar esta arquitectura tiene como eje central el patrón de diseño Observador y durante su desarrollo se encuentran otros patrones de diseño y definiciones de diseño de software lo cual asegura estabilidad y estructura al desarrollarse correctamente.

Gracias a la infraestructura en la nube, algunos proveedores tienen soluciones estructuradas para manejar infraestructuras de diferentes tamaños de forma fácil como lo hace Amazon con sus productos SNS y Kinesis además de que ya existen en el mercado varias soluciones de fácil acceso de las cuales podemos sacar provecho como RabbitMQ y Apache Kafka entre otras.

https://cardona.dev/blog/software%20architecture/events/event-driven-architecture/