Introducción a Arquitectura Event Driven

Las Arquitecturas basadas en microservicios, se basan en una serie de patrones arquitecturales para lograr que una serie de servicios desacoplados funcionen de manera conjunta para lograr un objetivo común. Uno de esos patrones lo vamos a ver en este artículo sobre Introducción a Arquitectura Event Driven.

Cuando nos encontramos en una arquitectura de microservicios, búscamos que los microservicios que hemos desarrollado puedan funcionar de una manera totalmente independiente, lo más descoplados posible, que puedan ser fácilmente escalables y que además tengan una alta tolerancia a fallos. Es en estos casos en los que la arquitectura Event-driven coge una alta importancia.

¿Qué es un evento en Event-driven?

Podríamos definir un evento en una arquitectura Event-Driven como cualquier ocurrencia significativa o cualquier cambio de estado en nuestro sistema. No debemos confundir un evento con una notificación que puede ser enviada para informar de algún suceso.

Un evento puede ser generado por un usuario que realiza un click en el ratón, un sensor para abrir una puerta, un cambio en el carrito de una aplicación e-commerce … etc.

¿Cómo funciona una Arquitectura Event-Driven?

Una arquitectura Event-Driven está basada en productores y consumidores de eventos.

Cada vez que un cambio se produzca en nuestro sistema o algo suceda, será notificado a nuestro consumidor a través con un evento que deberá ser inmutable. Este productor no conocerá el consumidor ni el resultado de procesar el evento.

Cuando un cambio es detectado, un evento es generado para ser envíado desde el productor al consumidor. Estos eventos serán enviado a través de unos canales de manera asíncrona. De esta manera, el consumidor será consciente de que un evento ha sido procesado. Y una vez recibido, este evento será tratado y procesado convenientemente.

Para poder realizar estos envíos de mensajes o eventos entre servicios (productor y consumidor), se hará uso de un broker, el cual los dirigirá a los consumidores adecuados.

Este modelo o arquitectura también puede ser Publish/Subscribe o event stream.

Uno de los brokers que actualmente es de las más recomendados para utilizar en una arquitectura Event-Driven,es Apache Kafka. El cual es una plataforma que funciona en sistemas distribuidos y nos permite la transmisión streaming de datos. Kafka puede gestionar el modelo publish/subscribe, almacenar y procesar eventos en tiempo real.

Pros y contras del uso de Event Driven.

A continuación vamos a ver por qué deberíamos de usar el Patrón Event Driven y cuándo deberíamos evitarlo.

Beneficios de Event Driven

Entre los beneficios principales que vamos a encontrar a la hora de usar Event Driven se encuentran:

• Desacoplamiento: Va a permitir desacoplar diferentes componentes y aislarlos para mantener su independencia. El servicio A no va a necesitar conocer el servicio B.
• Inversión de dependencias: El principio de inversión de dependencias, es una manera específica de perder acoplamiento entre módulos y acoplar libremente entre diferentes módulos.
• Escalado: Al tener los servicios desacoplados y comunicados a través de eventos podemos realizar escalado de aquellos que lo necesiten.
• Tolerancia a fallos: Es un sistema más robusto a los fallos, ya que un fallo en uno de los componentes no tiene que porque hacer que falle todo el sistema.
• Flexibilidad: Nos permitirá aumentar nuestra arquitectura sin tener que realizar grandes modificaciones en nuestros servicios.

Contras de Event Driven

Entre los contras principales que podemos encontrar en una arquitectura Event-Driven se encuentran los siguientes:

• Rendimiento: Vamos a hacer uso de una pieza más, nuestro broker. Debido a esto, vamos a añadir un mayor tiempo de respuesta o de procesamiento de la información. Con una arquitectura por ejemplo, monolítica las llamadas son directas, por lo que en temas de velocidad, probablemente sea mejor.
• Consistencia Eventual: Se refiere a que si ningún elemento de datos sufre ninguna modificación, se devolverá el último dato. Pero al tener comunicación asíncrona, el evento se envía y no estamos seguros de cuando los diferentes servicios lo reciben, por lo que podríamos tener una desincronización.
• Complejidad: A parte de tener que incluir más piezas en la arquitectura. Va a ser más difícil de rastrear qué esta pasando, dónde y cómo. Para solucionar esto habrá que añadir más componentes en la arquitectura como sistemas de monitorización y logs. Cuando se tienen llamadas directas se sabe a quién se llama y en qué momento.

¿Cuándo usar una arquitectura Event-Driven?

Esta pregunta es clave para poder hacer un buen uso de una arquitectura dirigida a eventos. La respuesta, obviamente, dependerá de tus necesidades.

Cuando queremos que lo que prime en nuestra arquitectura sea el rendimiento sobre cualquier otro parámetro, por lo general el uso de Event-Driven no será la mejor opción.

Pero en cambio, cuando lo más importante es la escabilidad, el desacoplamiento para interactúar con otros sistemas o la replicación de datos en múltiples sistemas. El uso de Event-Driven será la mejor opción, ya que además al poder realizar procesamiento paralelo diferentes servicios podrán procesar y analizar los eventos.

Conclusión

En este artículo sobre introducción a Arquitectura Event Driven, hemos podido ver uno de los patrones a utilizar más recomendados y utilizados dentro de una arquitectura de microservicios.