¿Qué es la arquitectura impulsadas por eventos?
La arquitectura basada en eventos (EDA) es un modelo de integración que detecta "eventos" importantes en un negocio –tales como una transacción o un carrito de compras abandonado– y actúa a partir de ellos en tiempo real.
Resumen de la arquitectura basada en eventos
Casi todos los eventos de una empresa son sensibles al tiempo. Cuando un cliente realiza una compra on-line, un sensor marca un mal funcionamiento inminente, cae el precio de las acciones, o se detecta una brecha de seguridad se deben tomar medidas inmediatas. Aquí es donde entra en juego una arquitectura basada en eventos (EDA). Una EDA puede crear, detectar y responder a los eventos a medida que se desarrollan, ayudando a las empresas a mejorar todo, desde las experiencias del cliente hasta la eficiencia y agilidad operativas.
¿Qué es un evento?
Primero, lo básico. Un evento es cualquier acción o cambio de estado que resulta importante para un negocio. Por ejemplo, cuando alguien desliza una tarjeta de crédito, hace el check-in para un vuelo, restablece una contraseña, o cuando se actualiza el inventario en un almacén. Los eventos ocurren todo el tiempo, en todas las organizaciones, en todas las industrias. Las empresas pasan a estar "impulsadas por eventos" cuando pueden captar y reaccionar a los eventos a medida que ocurren.
¿Qué es una arquitectura basada en eventos?
Una arquitectura basada en eventos (EDA) es un modelo de integración creado para publicar, captar, procesar y responder en tiempo real a eventos entre todos los sistemas distribuidos. Cuando se produce un evento en una aplicación, automáticamente se envía un mensaje a todas las demás aplicaciones que deben conocerlo, para que a su vez puedan actuar.
Las arquitecturas basadas en eventos están desacopladas –es decir que las aplicaciones no necesitan conocerse entre sí para compartir información y completar tareas–. La información, o los mensajes, sobre el evento pueden fluir de manera libre y automática entre las apps. Como resultado, el modelo de EDA es mucho más rápido que el modelo de solicitud/respuesta tradicional, donde una aplicación debe solicitar la información específica que necesita de otra y esperar una respuesta antes de pasar a la siguiente tarea. También debido a su naturaleza desacoplada, la EDA es ampliamente considerada como una mejor práctica para la comunicación de microservicios.
¿Cómo funciona una EDA?
En una arquitectura basada en eventos, las aplicaciones actúan como productoras de eventos (apps que producen o capturan eventos) o consumidoras de eventos (apps que procesan y actúan a partir de eventos). Las productoras transmiten eventos a los consumidores a través de un agente, conocido como middleware orientado a mensajes, en tiempo real. Las consumidoras pueden procesar el evento y disparar otras acciones, workflows o eventos propios.
En una arquitectura muy simple –donde hay un solo productor y un solo consumidor de datos que están en comunicación directa entre sí–, los brokers pueden ser opcionales. Sin embargo, en la mayoría de las empresas hay múltiples fuentes que envían eventos a múltiples consumidores, por lo cual se necesita un broker, o incluso una red de ellos (también conocida como “event mesh”). Cuando se utiliza un broker o un event mesh, se crea un “acoplamiento flexible” de aplicaciones.
Patrones de arquitectura basada en eventos
Hay dos patrones principales para transmitir los eventos en una arquitectura basada en eventos: publicar/suscribir y transmisión de eventos.
Publicar/suscribir (también conocido como “pub/sub”) – Con el pub/sub, las apps consumidoras de eventos se suscriben a mensajes y canales publicados por las productoras de eventos. Cuando se publica un evento, se envía directamente a todas las suscriptoras a través de un agente. Para evitar la duplicación, no es posible reproducir ni acceder a los datos una vez consumidos –el agente los elimina–.
Transmisión de eventos– Con la transmisión de eventos, los productores de datos envían flujos de eventos enteros a un broker. Los consumidores se suscriben al flujo y pueden leerlo desde cualquier parte, usando solo los eventos que son relevantes para ellos. En este patrón, los eventos son retenidos por el broker incluso después de haber sido consumidos.
3 enfoques para el procesamiento de eventos
Hay tres enfoques diferentes para procesar los eventos una vez que llegan a una app consumidora: procesamiento de eventos simple, complejo, y de flujos de eventos.
- Procesamiento de eventos simple: las consumidoras procesan cada evento a medida que lo reciben.
- Procesamiento de eventos complejo: Los consumidores procesan una serie de eventos para detectar patrones y realizar acciones basadas en el resultado.
- Procesamiento de flujo de eventos: Las consumidoras procesan y actúan a partir de un flujo constante de datos (datos en movimiento) en tiempo real utilizando una plataforma de transmisión de datos.
Las empresas eligen su enfoque para el procesamiento de eventos en base a sus necesidades y casos de uso individuales.
Ejemplos y casos de uso de arquitectura basada en eventos
Hay muchos casos de uso diferentes para arquitecturas basadas en eventos en cada industria –desde la banca hasta el comercio minorista–. Este es un ejemplo de la industria de restaurantes:
Un estudiante universitario pide una pizza a través de una app de entrega de comida, como Uber Eats. La app captura su información básica (nombre, dirección, información de pago y pedido) y publica el evento como "pedido de pizza".
La pizzería se suscribe al evento, cumple con el pedido, y publica su propio evento como “pedido listo” de nuevo en el servicio de entrega de comida.
Luego, el servicio asigna un conductor para la entrega, programa una hora de llegada, y le avisa al cliente que su pizza está en camino.
Un ejemplo de EDA en e-commerce:
Un comprador on-line ingresa los detalles de su tarjeta de crédito en un sitio de e-commerce, que publica el evento como “pago enviado”.
El sistema de pago se suscribe al evento, procesa el pago y emite su propio evento como "pago procesado" indicando éxito o falla –y lo enruta de vuelta a la IU del sitio web–.
La IU muestra el estado de pago del cliente y dispara los pasos siguientes.
Algunos otros ejemplos de EDA incluyen:
Cuando un comprador on-line hace clic en un producto y el sistema responde generando recomendaciones de productos basadas en artículos similares
Cuando un cliente deposita un cheque en un banco y el sistema automáticamente contabiliza el depósito en su cuenta
Cuando un minorista examina transacciones globales en busca de fraude y señala cualquier compra sospechosa a la empresa de la tarjeta de crédito
Cuando un fabricante monitorea la transmisión de datos de IoT desde su equipamiento y recibe alertas sobre potenciales fallas o problemas de mantenimiento
Beneficios de una arquitectura basada en eventos
La arquitectura basada en eventos tiene muchos beneficios. Los 3 principales son:
- Flujos de trabajo y capacidad de respuesta en tiempo real. Una EDA puede monitorear y reaccionar rápido a los eventos a medida que ocurren, a menudo utilizando automatización robótica de procesos (RPA) para acelerar los flujos de trabajo y disparar los pasos subsiguientes en tiempo real. Esto es especialmente crítico durante los momentos de máxima demanda –por ejemplo, grandes eventos de ventas o días festivos–. Esta capacidad de respuesta también se puede aplicar a diario (es decir, a flujos de trabajo no pico), lo cual mejora todo, desde la automatización de la cadena de suministro hasta la detección de fraudes.
- Mensajería asincrónica. En una EDA, las solicitudes se comunican de forma asíncrona –es decir que las apps productoras publican mensajes de eventos sin esperar a que las consumidoras los reciban–. Esto no solo permite a las aplicaciones pasar a otras tareas sin esperar, sino que simplifica la integración.
- Desacoplamiento y acoplamiento débil. Las aplicaciones de una EDA están desacopladas o débilmente acopladas y no dependen de la disponibilidad de las demás. Se pueden actualizar, probar e implementar de forma independiente. También pueden fallar de forma independiente –así que la arquitectura es más duradera y persistente que en los modelos tradicionales–. El desacoplamiento también facilita el añadir editores y consumidores extra según sea necesario, sin tener que reescribir el código cada vez que hay un cambio.
Conclusión
Un event mesh brinda opciones de implementación en diferentes hiperescaladores y en entornos de nube privada. Se puede configurar para que forme una malla distribuida de agentes de eventos implementados en entornos de nubes privadas o públicas. Un event mesh brinda un completo conjunto de servicios para eventos, incluyendo su trasmisión, gestión y monitoreo, y características avanzadas como enrutamiento de mensajes dinámico y filtrado detallado.
Explore las capacidades de SAP para event mesh
Potencie sus apps con una arquitectura basada en eventos de SAP Integration Suite.
Ideas que no encontrará en ningún otro lugar
Regístrese para recibir una dosis de business intelligence directamente en su bandeja de entrada.