Somos testigos de la creciente popularidad de las arquitecturas de integración Event-Driven, pero, ¿estamos realmente ante algo novedoso? ¿Acaso no es otro patrón de publicación/suscripción? Y, ¿dónde encaja entre el streaming de eventos, los microservicios, el aprendizaje de máquina, la automatización robótica de procesos y otros paradigmas modernos?
En Chakray, somos expertos en todo lo relacionado con la integración; desde la transferencia de datos, pasando por las arquitecturas orientadas a servicios y el ESB, a enfoques más modernos de microservicios.
En este artículo, exploraremos qué significa realmente la arquitectura Event-Driven en el mundo de la integración, y te ayudaremos a entender si este enfoque cumple con todas las expectativas y si es lo que necesitas.
1. Descripción y ejemplos de la arquitectura Event-Driven
1.1. ¿Qué es la arquitectura Event-Driven?
La arquitectura Event-Driven es un patrón de arquitectura software que se caracteriza por su capacidad de distribución, por ser asíncrona y altamente escalable.
1.2. Ejemplos de arquitectura Event-Driven
Veamos un ejemplo real de cómo podemos usar la arquitectura Event-Driven:
«Te han robado el teléfono móvil».
Podemos representar una situación cotidiana como esta como una secuencia de eventos:
Informar de pérdida del móvil –> obtener número de la policía –> informar a la compañía de seguros –> pedir un móvil nuevo –> transferir números de teléfono…
Se trata de un ejemplo sencillo, ya que, evidentemente, existen múltiples pasos adicionales, como notificar a amigos y a tu familia, cambiar las contraseñas de tus redes sociales, reemplazar tarjetas SIM, etc.
Veamos la situación desde un enfoque Event-Driven:
Publicar pérdida de móvil –> lanzar mensaje
- Policía recibe.
- Compañía de seguros recibe.
- Familia recibe.
- Amigos reciben.
- Proveedor del contrato recibe.
Puede que sea una simplificación, pero el concepto básico queda claro: ocurre un evento que reciben varias partes interesadas y al que responden de forma adecuada. Este concepto enfatiza el aspecto de «dirigido» del paradigma «Event-Driven». Es la diferencia clave entre este patrón y otros.
La parte de arquitectura del paradigma refiere a que el diseño de prácticamente todas las partes variables de la situación apoya el «evento» o el «flujo de eventos» para que estos sean el foco de la situación.
2. La historia de las arquitecturas Event-Driven
2.1 ¿Acaso no llevamos haciendo esto durante años?
La respuesta es sí y, desde una perspectiva de integración, es lo que conocemos como publicar/suscribir. Publicamos un «evento» y los suscriptores lo reciben y reaccionan.
Sin embargo, existen varios factores que han llevado a que la necesidad hacia un enfoque Event-Driven haya incrementado en los últimos años.
- Mayores cantidades de datos.
- La relevancia de aplicaciones y servicios distribuidos.
- El escalamiento dinámico de sistemas y aplicaciones.
- Las expectativas de respuestas y acciones inmediatas (experiencia del usuario).
- La proliferación de Microservicios.
- Una mayor necesidad por inteligencia y agilidad empresarial en tiempo real.
- El ascenso del internet de las cosas y los dispositivos smart.
No es una lista exhaustiva y podemos observar una relación evidente de causa y efecto entre los factores mencionados.
Es probable que gran parte se deba a la civilización del consumidor y del servicio; los consumidores esperan que todo esté disponible a petición, sin tener que enfrentarse a ningún tipo de fricción. Hoy en día, tenemos acceso a un taxi cuando y donde queramos, películas y series a la carta, luces que se apagan cuando se lo pedimos a Alexa, etc. Lo instantáneo y conveniente se ha convertido en lo estándar.
2.2 Ya tenemos publicación/suscripción, así que, ¿cuál es el problema?
Cambiemos el enfoque que tenemos hacia esta cuestión para buscar oportunidades en vez de ver problemas. Podemos aprovechar mucho más que el simple patrón de publicar/suscribir en las arquitecturas Event-Driven. Es aquí cuando empezamos a hablar de conceptos como el streaming de eventos.
Tradicionalmente, el patrón de publicar/suscribir se ha basado en la idea de «publicar una vez y esperar que los suscriptores lo reciban». Puedes aprovecharte de los reintentos, de las colas y de otros mecanismos para asegurarte de que una entrega ha sido exitosa. Sin embargo, la propia naturaleza del patrón hace que el publicador no sepa quién está suscrito ni si todos los suscriptores críticos han recibido el mensaje. Volvamos al ejemplo del móvil robado. ¿Qué pasa si la compañía de seguros no recibe el mensaje?
Gracias al flujo de eventos, los eventos publicados se almacenan como un registro continuo. Es decir, que podemos preservar el historial completo de los eventos para que esté disponible en todo momento. Si un suscriptor no está disponible o suscrito temporalmente cuando se publica un evento, tendrá acceso a dicho evento en cuanto se suscriba o conecte de nuevo.
3. La arquitectura Event-Driven en el panorama de la integración actual
Ahora que ya tenemos una idea general sobre la arquitectura Event-Driven, los patrones de publicar/suscribir y el streaming de eventos, abarquemos las cuestiones que nos quedaban pendientes:
- ¿Cómo se relaciona la arquitectura Event-Driven con otros paradigmas, como los microservicios?
- ¿Es la arquitectura Event-Driven la solución para todo?
- ¿Por qué no debería explorar la arquitectura Event-Driven?
Una de las ideas erróneas más comunes es pensar que una arquitectura solo puede seguir un paradigma de integración u otro. Por ejemplo, puede que algunas personas te hayan dicho: «tenemos una arquitectura de integración de microservicios», o «tenemos una arquitectura ESB monolítica». Sin embargo, las arquitecturas pueden emplear varios estilos diferentes y seguir siendo válidas.
No vamos a indagar sobre las connotaciones de la palabra «arquitectura» en este artículo, pero, en resumen, la arquitectura Event-Driven debe emplearse en conjunto con, o complementada por, arquitectura de microservicios. Una combinación de ambas arquitecturas se conoce como una arquitectura de microservicios Event-Driven. Asimismo, podemos obtener resultados en una arquitectura más monolítica combinada con el streaming de eventos.
Una gran parte de los impulsores que apoyan la arquitectura de microservicios son los mismos que están detrás de la arquitectura Event-Driven. Ambas ayudan a superar los mismos retos.
No obstante, piensa en una arquitectura de microservicios desde un enfoque tradicional, sincrónico y de integración de solicitud/respuesta: la arquitectura de microservicios facilita un servicio independiente y atómico, con un ciclo de vida independiente y que, por lo tanto, suele contar con un equipo independiente para ello. Si ese servicio dependiese de un flujo de integración de solicitud/respuesta con otro microservicio (sin motivo alguno), dicho servicio tendría una conexión directa y no sería verdaderamente independiente. No podrías actualizar/desarrollar el servicio sin preocuparte por el servicio conectado.
No es necesario contar con una arquitectura Event-Driven para sortear este obstáculo (también funcionaría otro patrón asincrónico alternativo, como una cola de mensajes), pero esto demuestra cómo las características de una arquitectura Event-Driven pueden interactuar de forma positiva con los microservicios.
3.1 Oportunidades para una arquitectura Event-Driven
Hasta ahora, este artículo se ha centrado principalmente en la arquitectura desde una perspectiva de integración, por lo que la función de la dirección por eventos, el patrón de publicar/suscribir y el streaming de eventos quedan claros. Sin embargo, vamos a analizar otras oportunidades para el uso de esta arquitectura que tienen que ver con la IA, el aprendizaje de máquina y la automatización robótica de procesos.
Ya hemos explicado que el streaming de eventos (event streaming) almacena todos los eventos pasados junto con los eventos actuales. Podemos distribuir y repetir este flujo en varias ubicaciones. Es decir, podemos diseñarlo para que maneje un alto volumen de eventos y, por ende, de datos. Volvamos al ejemplo del móvil robado e imaginémonos un registro de cada evento, pasado y presente, en el que una persona informó sobre un móvil perdido o robado.
Piensa en todos los datos obtenidos. ¿Qué podemos aprender de ellos y cómo podemos usarlos?
- Momentos del día/semana/mes/año en los que la pérdida o el robo es más probable.
- Las ubicaciones en las que se pierden/roban con más frecuencia.
- Las características de las personas que más sufrían estos incidentes.
Imagínate que una compañía de seguros de teléfonos móviles pudiese acceder a este flujo de eventos y combinarlo con otro flujo que registra eventos de personas comprando móviles nuevos. Estos datos ahora son información que permite que la compañía pueda ajustar sus precios, promociones y esfuerzos de ventas de forma dinámica para maximizar sus ganancias.
Esto solo es un ejemplo, pero te imaginas todas las posibilidades que hay si piensas en situaciones más orientadas a tu industria.
Ninguno de estos resultados es novedoso y los proyectos llevan años aprovechándose y analizando grandes volúmenes de datos. Sin embargo, el streaming de eventos simplifica el proceso para que las organizaciones que tengan una práctica de organización de datos establecida puedan ir más allá y para que aquellas empresas que, hasta ahora, no podían invertir en esta herramienta, puedan acceder a ella.
3.2 Problemas que evitar cuando adoptas una arquitectura Event-Driven
Antes de concluir este artículo, veamos la otra cara de la moneda. Es decir, cuándo un enfoque Event-Driven no es beneficioso.
El problema principal con este tipo de arquitectura es su complejidad, que suele estar directamente relacionada con su coste. A pesar de que los beneficios son evidentes, establecer registros de eventos distribuidos, altamente disponibles y en tiempo real no es tarea fácil y requiere de una planificación detallada.
Te presentamos algunos de los problemas más comunes a la hora de adoptar arquitecturas Event-Driven:
- Captar demasiado información o información muy ambiciosa
Es fácil dejarse llevar y crear eventos para todo. Aunque estos eventos «podrían ser útiles en un futuro», añadirán más complejidad y necesidad de desarrollo al trabajo. No es necesario crear un evento para todo, así que céntrate en lo que «es útil para ahora». Los eventos deberían ser fáciles de entender para todo el mundo y no difíciles de explicar.
- Usar eventos cuando no deberías
Puede parecer algo evidente, pero uno de los errores más comunes es intentar encajarlo todo en lo relacionado al «Event-Driven». La arquitectura es, por diseño, asincrónica y de conexión no directa. Por lo tanto, ¿es el mejor enfoque para situaciones que requieren una respuesta de un recipiente conocido dentro de un plazo específico? Son muchas las situaciones en las que este enfoque da más problemas que soluciones.
También deberíamos considerar el valor ROI o valor empresarial de cara al diseño de un flujo o una situación. Por ejemplo, hay que evaluar si el coste de tener un flujo de evento para «solicitudes de vacaciones de los empleados» compensa la inversión hecha. Puede que sea así en determinados casos, pero, al final, lo más recomendado es abarcarlo desde un enfoque pragmático basado en valores.
- Titularidad de la tecnología
Un camino Event-Driven suele empezar con un caso que no es crítico a nivel empresarial. Por ejemplo, puede que se implemente para desconectar una aplicación. En una situación como esta, es fácil que la tecnología se convierta en una facilitadora de la aplicación que dirige su titularidad desde el desarrollo de la misma aplicación. Para obtener los mejores resultados, es necesario que cuente con un diseño de datos y pensamiento de integración sólido para que funcione como facilitadora a largo plazo en una organización.
- Intentar ejecutarla demasiado rápido
Suele pasar que una organización se centre exclusivamente en «ser la empresa farmacéutica inteligente más automatizada del mundo» y que intente abarcar cada caso a lo grande. Esto es una receta para el desastre y probablemente resulte en perder más tiempo. Las mejores implementaciones empiezan a pequeña escala y crecen con el tiempo, la comprensión y la experiencia.
Kafka market leaders Confluent™ nos ayuda con esta curva de adopción:
- Expectativas imposibles
«Event-Driven» no significa tener una solución para todo. Los sistemas disfuncionales existen y seguirán existiendo. Las pruebas automatizadas deficientes y la capacidad de despliegue pobre no desaparecerán ni se solucionarán gracias a este enfoque. Es cierto que el enfoque Event-Driven ofrece muchas oportunidades, pero no es la cura para todos los males.
Desde una perspectiva técnica, algunas de las situaciones en las que conviene usar una herramienta como REST o GraphQL son:
- Necesitas una interfaz de solicitud/respuesta dentro de un plazo específico, por ejemplo, una verificación de crédito
- Necesitas una traducción que sea fácil de mantener.
- Necesitas que una API esté disponible al público
- El proyecto/requisito es de bajo volumen.
4. Conclusión
En resumen, es evidente que un enfoque «Event-Driven» trae beneficios fantásticos que cada vez son más esenciales para que una organización sobreviva y prospere en este panorama de tendencia competitiva y consumista.
Sin embargo, no debemos tomarlo a la ligera y lo más importante no es este enfoque en particular, sino la estrategia de integración en su conjunto, así como las colaboraciones adecuadas que te ayuden a navegar por esta selva de la integración y a evitar los problemas más comunes.
No existe un estilo que sea la panacea; el camino al éxito va marcado por una combinación de las soluciones más apropiadas tomadas en el momento correcto.
