¿Para qué sirve la malla de eventos?

Después de contar cuál es el papel de las mallas/mesh en las arquitecturas de microservicios y cómo nos ayudan las mallas de servicio (services mesh), ahora en este nuevo post nos toca hablar de Event Mesh o malla de eventos.

Event Mesh y Service Mesh no son lo mismo, pero ambos pueden complementarse. Sin embargo, para los microservicios basados ​​en eventos, los problemas que aborda una malla de servicios aún no se resuelven con una malla de eventos. Si bien los sidecars son el aspecto central de Service Mesh no juegan un papel en Event Mesh.

Como hemos visto anteriormente, la malla de servicios proporciona lo que podría parecer una solución completa para descargar los problemas centrados en la red de las aplicaciones de microservicios, pero está sujeta a algunas restricciones importantes:

• No hay soporte para el procesamiento asíncrono de eventos o flujos.
• La mayoría de los servicios de red y conformación del tráfico solo se aplican a los patrones de intercambio de mensajes sincrónicos de solicitud/respuesta y al transporte HTTP.
• Se limita al enrutamiento orientado a la conexión y a la orientación de las conexiones de transporte, no al enrutamiento de los datos reales.
• Actualmente, la malla de servicios está disponible en los clústeres de Kubernetes (incluyendo variantes como OpenShift, GKE, etc.) porque son las abstracciones de red de Kubernetes las que hacen factible la implementación del enrutamiento entre servicios internos de la aplicación.
• Los microservicios que utilizan conexiones de red TCP en bruto solo se beneficiarán de TLS entre los sidecars y los datos de telemetría recogidos por los sidecars.

Algunas aplicaciones necesitan un mayor rendimiento, una menor latencia. Para ello, se utiliza la coreografía de microservicios en vez la orquestación de estos a través de comunicaciones asíncronas y eventos que hace que el acoplamiento de los microservicios sea débil.

¿Qué es la malla de eventos (Event Mesh)?

Muchos despliegues de microservicios heredados funcionarán muy bien dentro de las limitaciones de una malla de servicios. Sin embargo, muchos microservicios modernos necesitan ser impulsados por eventos porque requieren más rendimiento, desacoplamiento y respuesta en tiempo real, extendiéndose más allá de un clúster Kubernetes. Para ayudar a disfrutar de las ventajas de la agilidad de desarrollo que ofrece una arquitectura de microservicios basada en EDA (Event Driven Architecture), ha surgido un tipo diferente de malla:

"Event Mesh proporciona optimización y gobernanza para eventos distribuidos e interacciones. La computación basada en eventos es fundamental para la agilidad continua de los negocios digitales. La red distribuida y optimizada de intermediarios de eventos facilitada por la infraestructura de malla de eventos tiene como objetivo permitir un negocio digital continuo con experiencia nativa", definición de Gartner en Identifies Key Trends in PaaS and Platform Architecture for 2019.

¿Nos podemos imaginar una foto como esta?

Características de la malla de eventos

Los microservicios empujan los límites de las aplicaciones tradicionales, pero a veces para comprobar posteriormente que existen otros adicionales que son difíciles de superar. Las comunicaciones síncronas utilizadas tradicionalmente con los microservicios (como REST) se vuelven problemáticas debido al acoplamiento inherente, aunque es mucho más seguro que en un monolito que son sistemas fuertemente acoplados en todos los sentidos, estático, temporal, deployment. No obstante, en el mundo de los microservicios los cambios en los servicios que se exponen podrían seguir afectando al sistema subyacente de forma inadvertida.

La creación y cooperación de servicios tiene un fuerte acoplamiento temporal (tiempo de ejecución), lo que implica que el fallo de un servicio por diferentes causas funcionales, rendimiento… puede suponer que toda la aplicación o parte de la aplicación deje de tener respuesta o respuestas incontroladas. Una de las formas más sostenibles de abordar el reto de tener acoplamiento lo más débil posible es mediante una arquitectura basada en eventos (EDA), en lugar de llamadas síncronas entre servicios, se consumen eventos y, de esta forma, los servicios hacen su trabajo de forma asíncrona. Los servicios pueden consumir eventos (consumidores) reaccionando a los eventos producidos por otros servicios (productores).

Un evento es un cambio, acción u observación en un sistema que produce una notificación. Los eventos se desencadenan por cambios, como la actualización de entidades de datos maestros, el cambio de dirección de facturación de un cliente, un nuevo pedido o la aprobación de una operación. Otros desencadenantes son más básicos, como el cumplimiento de un umbral de nivel de carga de la batería o la lectura periódica de la temperatura de un sensor. Es habitual referirse a la notificación como "evento".

En un sistema basado en eventos, un componente produce un evento sin esperar ni controlar necesariamente el consumo de ese evento. Existe un acoplamiento débil entre el productor y el consumidor de eventos. Desde el punto de vista del desarrollo, el desacoplamiento de la producción y el consumo de eventos simplifica enormemente las cosas. Un desarrollador puede crear un evento sin necesidad de conocer los detalles del entorno en el que se consumirá.

Una arquitectura de microservicios basada en eventos comparte muchos de los principios de las arquitecturas de microservicios, pero la interacción entre servicios se centra en el uso de eventos. Los servicios realizan su trabajo reaccionando a los acontecimientos. Esto contrasta con un sistema que se basa en la invocación de servicios mediante un patrón de interacción petición-respuesta. Los roles en las arquitecturas orientadas a servicios (SOA) y el estilo de arquitectura REST se basan en el acoplamiento estrecho síncrono entre el cliente y el servidor. El estrecho acoplamiento de los componentes conlleva algunas limitaciones, que pueden superarse en una arquitectura basada en eventos.

Sin embargo, la naturaleza asíncrona y distribuida de la arquitectura basada en eventos plantea retos difíciles que a menudo se dan por sentados en llamadas síncronas, secuencialidad, orden en el tiempo, etc. El ordenamiento temporal (también denominado preservación de la secuencia) es una característica importante que garantiza que el flujo de eventos conserve la integridad del estado del negocio. Por ejemplo, un evento instantáneo representa el estado de una entidad en un momento dado. Si se procesa fuera de la secuencia, se obtendría una representación no válida de la entidad. Un flujo de eventos es un conjunto de eventos ordenados en el tiempo que no pueden ser modificados una vez producido. Esta propiedad se describe como inmutable.

Las arquitecturas basadas en eventos proporcionan un mayor nivel de desacoplamiento y permiten una arquitectura genuinamente evolutiva desde el principio. Los nuevos consumidores pueden incorporarse sin afectar a los servicios existentes. Los servicios antiguos pueden ser retirados sin afectar a sus dependencias.

En una arquitectura de microservicios basada en eventos, varios servicios desacoplados reaccionan entre sí y se coreografían para cumplir un objetivo empresarial. Proporcionan una secuencia inmutable de eventos que permiten entender el propósito y la evolución de los datos e interpretar sus procesos de negocio. El potencial de las arquitecturas basadas en eventos es la capacidad de proporcionar un flujo de datos con historia y significado, lo que permite a cada consumidor tomar la visión que más se ajusta a su contexto y construir valor sobre ella.

Al gestionar la comunicación entre los servicios con broker de eventos, se desacoplan aún más los servicios. Los servicios no se conocen entre sí gracias a la intermediación del broker. También es fácil añadir nuevos consumidores: solo tiene que conectarlos a la cola de eventos. Esto aumenta aún más la capacidad de cambiar cada microservicio y hacer evolucionar su dominio sin afectar a otros.

El diseño de la composición/cooperación de microservicios tiene que aprovechar lo mejor de los dos mundos, sincronía y asincronía, planteando retos que necesitan estrategias y patrones para afrontarla y sobre todo para centrar los desarrollos solo en el negocio y no en aspectos de comunicaciones, la gestión de estas y protocolos en la interacción entre los microservicios.

La mayoría de las arquitecturas del mundo real son una mezcla de servicios asíncronos y síncronos. Algunos casos de uso requieren funcionalidades síncronas o simplemente no se benefician de la complejidad de una cola asíncrona, y una API será suficiente. La capacidad de proporcionar altos volúmenes de mensajes a los componentes distribuidos de forma sostenible y en tiempo real sí es nueva. Sin duda, para la mayoría de los casos de uso, los datos más valiosos son los más recientes, pero poder ofrecer un flujo accesible con el historial de los datos desbloquea soluciones sólidas a problemas difíciles, por ejemplo, la migración de datos. En lugar de complejas soluciones de sincronización que tienen que lidiar con los datos que se modifican mientras se ejecuta la migración, hacerlo con flujos de eventos se vuelve trivial y orgánico (Change Data Capture). Mover un gran conjunto de datos es difícil y puede tener impactos en el servicio y su base de datos. No se comparten bases de datos debido al acoplamiento de esquemas o al impacto que una aplicación puede tener sobre otra. Las peticiones HTTP síncronas pueden tener el mismo efecto que se intenta evitar al deconstruir una base de datos monolítica.

En una arquitectura basada en eventos, también es posible comprender la evolución de los datos. A menudo, los datos más críticos son los más recientes. La mensajería típica produce un evento y desaparece una vez que el servicio lo consume. Sin embargo, la capacidad de conservar el evento y mantenerlo para que sea consumido de nuevo libremente por la misma aplicación o por aplicaciones futuras desbloquea poderosas posibilidades. El flujo de eventos se convierte en un medio para compartir todos los datos relevantes que se producen en tiempo real y proporciona una forma de entender que ocurrió en el pasado. Cada consumidor puede conectarse al flujo y crear una vista personalizada del estado. Esta propiedad permite que el servicio combine datos de diferentes fuentes y los modele de la mejor manera para su dominio y necesidades de consulta (Event Sourcing).

Las grandes empresas tienen topologías de red y aplicaciones muy distribuidas. Necesitan suministrar de forma fiable un gran volumen de eventos a través de redes globales, atravesando nubes híbridas y aplicaciones on-prem y evitando cuellos de botella. Para abordar esta problemática, especialmente Solace, Redhat, MuleSoft, Apache Event Mesh y otras, están usando el concepto Event Mesh.

Una malla de eventos es una capa arquitectónica que dirige eventos de los productores a los consumidores de una manera flexible, fiable y gobernada, sin importar dónde las aplicaciones estén desplegadas. Es un concepto arquitectónico emergente que proporciona una funcionalidad similar a la malla de servicios, pero está orientada a patrones de interacción asíncrona. Esto elimina las complejidades descritas anteriormente al permitir que los productores y consumidores intercambien eventos independientemente de dónde estén desplegados físicamente, todo ello manteniendo las cualidades de entrega de eventos del servicio. Es una infraestructura dinámica que propaga eventos a través de plataformas de nube dispares y realiza la traducción de protocolos.

Los eventos pueden fluir bidireccionalmente a través de la topología multi-nube. A medida que más aplicaciones producen y consumen eventos, una característica clave de la malla de eventos es que los eventos publicados por cualquier aplicación en cualquier entorno de programación (un evento Java JMS) en una nube pueden ser consumidos por una aplicación en otra nube utilizando una API diferente (una suscripción a un evento Kafka en una aplicación Python). Esto libera a los desarrolladores de aplicaciones de la complejidad de diseñar y gestionar redes de distribución de eventos, permitiendo a los equipos de desarrollo de aplicaciones elegir el entorno de desarrollo de su elección sin ninguna restricción de la plataforma de mensajería. Además, el modelo de despliegue de aplicaciones sin servidor reduce los requisitos de infraestructura para los distintos entornos de aplicación.

Un malla de eventos debe facilitar para nuestras aplicaciones:

• Soporte para la entrada y salida de eventos en varios transportes, como Kafka, Knative, HTTP, AMQP y otros.
• Tolerancia a los fallos para una entrega de mensajes de alta fiabilidad, incluida la recuperación automática de los fallos de la red y los destinos alternativos para los mensajes que no se pueden entregar.
• Soporte para puentes multiprotocolo entre eventos, aplicaciones y plataformas de mensajería dispares.
• Compatibilidad con el despliegue en las instalaciones y en varias nubes para proporcionar una infraestructura uniforme en toda la empresa.
• Múltiples API de cliente para una amplia gama de lenguajes y entornos de programación.
• Consola de gestión para la administración de la malla y la supervisión de la actividad.
• Transmisión segura de mensajes de eventos.

Hay un gap tecnologías en interacciones síncronas, cada vez menor, que a diferencia de las interacciones síncronas se tienen con los diferentes API Portal, Istio… tanto productos propietarios como Open Source. Actualmente, la maduración de los estándares de Async API y los pocos productos implementando malla de eventos lleva a que en los desarrollos todavía se tengan que desarrollar en los proyectos funcionalidades de esta capa arquitectónica para lograr gestión del ciclo de vida de los eventos o gobierno.

Arquitectura

Los brokers de eventos ofrecen una distribución de eventos eficiente y escalable, basada en el enrutamiento de eventos etiquetados y no solo de mensajes a una cola (los brokers de eventos también admiten la puesta en cola de mensajes). Se han hecho aún más populares con el desarrollo de APIs estandarizadas (y de código abierto), protocolos y formatos, y soportan las siguientes capacidades:

• Desacoplar qué datos enviar a qué aplicaciones consumidoras, hacerlos llegar de forma fiable y gestionar los cambios en este conjunto de consumidores a lo largo del tiempo.
• Tratar con consumidores demasiado lentos o desconectados gestionando el estado de los eventos en vuelo
• Ofrece servicios como la entrega prioritaria, la gestión del "mensaje de la muerte", el equilibrio de la carga para los consumidores y muchas más características de las que se benefician las aplicaciones de "mensajería".

Los brokers de eventos simplifican las aplicaciones y permiten un sistema en tiempo real, con mayor capacidad de respuesta, escalable, eficiente y tolerante a fallos. También ofrecen a los desarrolladores más capacidades, arquitecturas y patrones de diseño que los disponibles con una malla de servicios. Por ejemplo, permiten el enrutamiento entre microservicios, de modo que los clientes pueden participar en la definición del enrutamiento de los eventos. Los brokers de eventos hacen el trabajo pesado de lidiar con los problemas de la red y proporcionan una API sencilla en los clientes y microservicios.

Un único broker solo puede gestionar un determinado número de peticiones de clientes y microservicios. Hay diferentes formas de escalar los Event Brokers, algunas de las cuales conducen a lo que se conoce como una malla de eventos.

Una malla de eventos amplía el procesamiento entre múltiples sitios y dominios administrativos. A diferencia de las mallas de servicios, permiten la integración entre entornos locales y en la nube. Cada dominio de procesamiento puede interconectarse para que parezca un único broker de eventos virtual, desvinculando por completo a productores y consumidores desde un punto de vista lógico, geográfico y de dominio administrativo/plataforma.

Algunas características de la arquitectura de una malla de eventos:

• Consiste en un grupo de brokers de eventos que almacenan los eventos de forma duradera. Así, los eventos se pueden procesar a medida que ocurren o retrospectivamente.
• Conecta y admite diversos entornos de implementación: nube, no nube, multi-nube y nube híbrida.
• Permite una pila de tecnología independiente: compatibilidad y traducción de protocolos y varias API de cliente.
• Cumple con los requisitos básicos: escalabilidad, confiabilidad y seguridad.

La arquitectura la vemos ilustrada en la siguiente figura:

El único aspecto crítico es la compatibilidad y la traducción del protocolo. Sin embargo, es posible crear soluciones de traducción de protocolos personalizadas. Además de eso, hay otros brokers de eventos que admiten de forma nativa múltiples protocolos, por ejemplo, Pulsar, que permite el uso de Kafka, MQTT, AMQP y RocketMQ.

Plano de datos de la malla de eventos

En una malla de eventos, generalmente, no hay una tecnología subyacente como Kubernetes, ya que los brokers de eventos fueron diseñados para ejecutar de cualquier forma.

Las mallas de eventos enrutan los datos basándose en temas, una cabecera de metadatos jerárquica que describe la carga útil, y se transporta con la carga útil de datos de eventos.

Los productores de eventos se conectan a un broker de eventos y envían (o "publican") eventos (con su tema) al broker. Los consumidores de eventos también se conectan al broker y envían una solicitud de registro para los temas que describen los eventos que desean, a esto se llama "suscribirse". Algunos brokers de eventos les permiten suscribirse a grupos de eventos utilizando comodines.

Cuando los mensajes llegan al broker, este los dirige a los consumidores en función de sus suscripciones.

Los consumidores procesan de forma asíncrona y potencialmente en paralelo. Solo utilizan la carga de procesamiento cuando el broker envía un evento basado en la suscripción del consumidor. Al igual que con la malla de servicios, no hay direcciones IP o DNS involucradas; todo el procesamiento y el enrutamiento se basan en los campos de metadatos del tema. Ese es el trabajo pesado por el cual el broker de eventos abstrae el enrutamiento de eventos entre productores y consumidores. Todo lo que se necesita es una simple biblioteca de clientes, y como no hay conciencia entre productores y
consumidores, están completamente desacoplados.

Los brokers de eventos ofrecen persistencia para que los consumidores no necesiten estar disponibles cuando el evento se produce inicialmente. Los clientes tienen la opción de recibir eventos que se publicaron mientras estaban desconectados o cuando no pudieron seguir el flujo de información.

Mientras que cada broker de eventos proporciona su propia tabla de enrutamiento local basada en temas, el plano de control de la malla de eventos extiende de forma dinámica y transparente esa información de enrutamiento entre todos los nodos brokers de la malla de eventos interconectados (como hace Internet para las rutas IP).

Así es como una malla de eventos hace que muchos brokers de eventos parezcan un único broker de eventos virtual. Utiliza protocolos de enrutamiento de brokers para enrutar de forma inteligente, dinámica y eficiente los eventos basados en el interés del consumidor.

La naturaleza asíncrona de la malla de eventos también permite a los microservicios utilizar marcos de desarrollo modernos, como el procesamiento reactivo y el procesamiento de flujos. El código de bajo toque y las herramientas de desarrollo para el procesamiento asíncrono, como Spring, Quarkus… también aceleran la agilidad del desarrollo. Algunos brokers de eventos admiten servicios como la persistencia, el orden de procesamiento, las uniones tardías de consumidores y la repetición para admitir paradigmas de consistencia eventual que promueven el escalado y mejoran el desacoplamiento.

Plano de Control de la malla de eventos

Hay que tener en cuenta que no todos los Event Brokers permiten formar una malla de eventos. Si el clúster donde ejecuta no proporciona un enrutamiento inteligente entre otros clústeres (locales o a través de una WAN), los Event Brokers no constituyen una malla de eventos. Cada broker de eventos que sí permite una malla de eventos proporciona un plano de control.

Un plano de control de malla de eventos se implementa en varios niveles. Dado que los brokers deben proporcionar las herramientas y capacidades en nombre de los microservicios distribuidos, los brokers de eventos deben proporcionar la funcionalidad que Kubernetes da a una malla de servicios. Como resultado de la falta de dependencias del nodo broker de eventos, el plano de control de la malla de eventos debe proporcionar servicios de alta disponibilidad para los nodos brokers de eventos, y recuperación de desastres para los nodos brokers que soportan la persistencia. El plano de control de la malla de eventos debe ocuparse de todos los servicios entre los nodos brokers de eventos y no solo del enrutamiento de los mismos. El plano de control de la malla de eventos deberían incluir:

• Compartición de la configuración y supervisión de los nodos del broker de eventos en un clúster de alta disponibilidad (HA).
• Compartición y supervisión de la configuración entre clusters de HA desplegados como parte de un cluster de recuperación de desastres.
• Actualizaciones dinámicas en tiempo real de las tablas de enrutamiento de la suscripción a los mensajes de eventos entre todos los nodos y clusters del broker de eventos con sofisticados protocolos de enrutamiento y supervisión.
• Capacidades CLI y API para gestionar la seguridad, la autenticación, la autorización y los controles de acceso.

Los brokers de eventos manejan la configuración y la propagación de la configuración de manera diferente. Sin embargo, en general, la actualización de una suscripción en un solo broker actualizará todos los demás nodos de brokers apropiados. Cada broker de eventos también recoge y pone a disposición diferentes niveles de datos estadísticos.

Conclusión

Como se ha comentado la malla de eventos es todavía un concepto en evolución y que no tiene la madurez de la malla de microservicios, principalmente por la falta de estandarización de la comunicación asíncrona (Async API está intentando poner remedio a esta laguna) a diferencia de la comunicación síncrona.

Las capacidades genéricas de una malla de eventos:

• Una red de brokers de eventos interconectados que puede desplegarse en cualquier nube, PaaS o no nube (por lo que incluye todas las capacidades de un broker de eventos pero está distribuido)
• Proporciona una distribución dinámica de eventos para que los consumidores de eventos puedan recibir eventos de cualquier productor de eventos, independientemente de dónde estén conectados el productor y el consumidor a la malla, sin necesidad de configurar el enrutamiento de los eventos

La malla de eventos conecta no solo microservicios, sino también aplicaciones heredadas, servicios nativos de la nube, dispositivos y fuentes/sumideros de datos, y estos pueden operar tanto en entornos de nube como de no nube. Una malla de eventos puede conectar cualquier fuente de eventos con cualquier broker de eventos.