Publicado el 18 Nov, 2021 8 minutos de lectura
Imagina por un momento que estás encendiendo una vela y estás tan concentrado en encender la mecha que no te das cuenta de lo cerca que está tu dedo de la llama. De repente, sientes un dolor que recorre tu mano, y rápidamente te apartas y la sueltas.
Todo esto ocurrió en cuestión de segundos. Una vez que tu dedo se acercó demasiado al fuego, pequeños receptores de tu piel empezaron a captar el cambio de temperatura y tu cuerpo disparó entonces un impulso nervioso, una señal eléctrica que transmite un mensaje urgente a otras partes de tu cuerpo: "¡Peligro! Muévete rápido!". Antes de que te dieras cuenta de que algo iba mal, tu cuerpo ya estaba reaccionando.
¿Qué tiene esto que ver con los microservicios basados en eventos?
Para responder a esto, primero tenemos que entender que la definición de datos ha cambiado con el tiempo. Hace varios años era muy común centrarse principalmente en el almacenamiento de datos transaccionales sobre usuarios, productos, pedidos y otras informaciónes similares en bases de datos relacionales. Esta visión del mundo centrada en el estado dominó durante muchos años.
Ahora, es muy común incluir también datos de eventos que registran lo que sucede. En otras palabras, almacenamos información sobre la actividad de los usuarios, las respuestas del sistema y mucho más. Ya no solo nos limitamos a actualizar el estado actual de nuestros sistemas. Los puntos de datos a nivel de evento son para nuestras empresas lo que los impulsos eléctricos son para nuestro cuerpo.
El almacenamiento de información en bases de datos relacionales sigue siendo muy útil y potente, pero está limitado en muchos aspectos. Vamos a repasar algunas de estas limitaciones a lo largo del post. La idea principal que queremos compartir es que es posible que la información fluya en tiempo real a través de nuestras organizaciones, al igual que los impulsos viajan a través de los organismos vivos.
¿Por qué los eventos?
Empecemos a desarrollar un entendimiento compartido definiendo un lenguaje común. Alexander Dean, director general de la plataforma de datos de comportamiento Snowplow, define claramente un evento como "cualquier cosa que podamos observar que ocurre en un momento determinado". Por ejemplo:
-
Usuaria 123 (Fernanda Valdés) invierte en fondos XYZ a las 13:46:53 28/07/2021
-
Viajero AB123 (Juan Manuel Cortés) compra un vuelo desde Colombia a las 11:23:21 13/06/2021
-
La máquina 88-C se avería a las 23:54:31 el 13/09/2021
Los eventos suelen estar ligados a un momento concreto. Por ejemplo, un estado continuo como "el sistema se ha caído" no es un evento (el sistema se cae a las 13:21 del lunes es un evento).
Una de las principales ventajas de utilizar eventos es que simplifican la colaboración. Imagina cómo sería si el cerebro estuviera constantemente solicitando información al resto del cuerpo, independientemente de si está ocurriendo algo interesante o no. Esto sería un enorme desperdicio de actividad.
Con la colaboración en eventos, no es necesario que un componente (software u orgánico) pida a otro que haga algo. En su lugar, cada componente simplemente señala que algo ha cambiado y los demás componentes que escuchan pueden reaccionar como quieran.
El problema de la integración de datos
Los datos de eventos conllevan a una amplia serie de retos. Por ejemplo, los enfoques tradicionales de integración de datos no suelen ser capaces de gestionar los datos de eventos porque suelen ser órdenes de magnitud mayores que los datos transaccionales.
Cuando los datos se almacenan en diferentes tablas y bases de datos, a menudo nos encontramos con que los desarrolladores crean conexiones desde sus aplicaciones directamente a las bases de datos para obtener los datos que necesitan. Con el tiempo, esto crea una amplia red de conexiones diferentes que es extremadamente difícil de entender y hace casi imposible modificar los datos de cualquier manera sin romper las diferentes aplicaciones.
Este tipo de complejidad suele hacer que los datos no sean fiables. Las discrepancias en los datos son muy difíciles de identificar y por lo mismo toma mucho tiempo hacerlo, siendo encontrar el origen de las discrepancias aún más difícil. Esto significa que cualquier informe o almacenamiento de datos derivado de este sistema se vuelve cuestionable en el mejor de los casos.
Para resolver este problema, podemos recurrir a un héroe a menudo infravalorado o subestimado: el registro. Muchos de nosotros sólo nos preocupamos por los registros cuando intentamos identificar por qué nuestro sistema dejó de funcionar. Pero, según Jay Kreps (cofundador y director general de Confluent, la empresa que está detrás de la popular plataforma de streaming Apache Kafka), el registro es en realidad una estructura de datos natural para manejar el flujo de datos entre sistemas.
La idea principal es poner todos los datos de la organización en un registro central al que se pueden suscribir diferentes sistemas y agentes en tiempo real.
¿Qué es un registro?
Un registro como estructura de datos es extremadamente simple: es una secuencia o flujo de hechos inmutables.
Estos hechos son iguales a los registros sobre los eventos descritos anteriormente en este post en donde se incluye la información de cuando sucedieron. Este flujo de registros está ordenado cronológicamente y sólo se pueden añadir nuevos registros a la secuencia. Esto hace que los registros almacenados sean inmutables.
Los eventos pueden ser almacenados indefinidamente, a gran escala y pueden ser consumidos una y otra vez. Esta es en realidad una de las principales ventajas de esta estructura de datos, ya que tenemos en esencia un registro con una historia persistente y reproducible.
Martin Fowler ha compartido interesantes casos de uso en torno a los eventos almacenados de esta manera. Uno de estos casos de uso se conoce como "Event sourcing". Si tenemos un registro de la historia reproducible, podemos recrear el estado de nuestra aplicación cuando queramos. Si la aplicación se bloquea, podemos simplemente volver a ejecutar los eventos y recrear el estado actual sin pérdida de información. Si perdiéramos el estado actual de un perfil de usuario, podríamos reconstruir ese perfil ejecutando todos los eventos producidos por este.
Fowler lleva esta idea aún más lejos: "Dado que el estado de nuestra aplicación está totalmente definido por los eventos que hemos procesado, podemos construir estados alternativos de la aplicación, que yo llamo modelos paralelos". Esto nos permite retroceder en el tiempo para entender por qué alguien hizo lo que hizo o incluso crear realidades alternativas para el análisis contrafactual.
Por ejemplo, podríamos preguntarnos "¿cómo serían nuestras operaciones a finales de 2020 si la pandemia no hubiera ocurrido o si hubiera durado sólo unos meses?". Para responder a esto podríamos volver a ejecutar todos los eventos almacenados de 2020 con nuestras suposiciones y comparar el estado final alternativo con el estado real.
Otro caso de uso interesante es el de contrarrestar las consecuencias de una información incorrecta. Imaginemos que alguien ha cometido un error al diseñar el algoritmo para una métrica específica. Si sólo tenemos acceso a la métrica resultante mes a mes, resulta muy difícil saber cómo serían los números si el algoritmo hubiera estado correcto desde el principio. Con la fuente de eventos podríamos volver al momento en que se introdujo el algoritmo defectuoso y volver a ejecutar los eventos utilizando el algoritmo correcto.
Arquitecturas basadas en eventos
Ahora que entendemos el poder del seguimiento de eventos y la idea central del registro inmutable, podemos empezar a añadir más fuentes y agentes a la mezcla para describir las arquitecturas impulsadas por eventos.
En una arquitectura basada en eventos, el registro central tiene una API bien definida para añadir datos y los sistemas se comunican entre sí enviando y consumiendo eventos almacenados en el registro. El consumo de un evento no lo destruye, sigue formando parte del registro para que otros sistemas puedan consumirlo también.
Cada fuente de datos puede enviar eventos al registro central o puede modelarse como su propio registro antes de converger en el registro central. Este registro central se convierte naturalmente en la única fuente de verdad para todas las aplicaciones relacionadas.
Por último, es importante señalar que este enfoque de flujo de eventos desvincula la producción y la propiedad de los datos del acceso a los mismos. Los productores se concentran en la creación y el envío de datos bien definidos, mientras que el acceso a los datos y los requisitos de modelado se trasladan al consumidor.
Microservicios basados en eventos
Hemos compartido múltiples recursos en el pasado sobre los beneficios de desacoplar la funcionalidad en el front-end con micro-front-ends, y desacoplar sus sistemas en el back-end con microservicios. Por lo tanto, no nos centraremos aquí en los beneficios de los microservicios.
Utilizando un lenguaje tomado del Domain-Driven Design, un microservicio es una pequeña aplicación construida para cumplir con un contexto específico y delimitado.
Los microservicios orientados a eventos también pueden separarse en productores y consumidores. Los microservicios productores envían eventos a los flujos para que otros servicios los consuman, mientras que los microservicios consumidores, consumen y procesan eventos de uno o más flujos de eventos de entrada. Es común que los microservicios sean tanto productores como consumidores.
Una gran ventaja es que en lugar de utilizar llamadas sincrónicas y callbacks, cada microservicio puede escribir directamente en el flujo de eventos. El flujo de información de los usuarios, por ejemplo, está fácilmente disponible para cualquier otro servicio que esté escuchando y tenga interés en las cuentas de los usuarios. Esto nos permite crear servicios modulares y componibles.
En el diagrama siguiente, los datos del rastreador de actividad de los usuarios se envían al registro central unificado. Diferentes bases de datos y servicios escuchan el flujo y actúan sobre los datos en consecuencia. Por ejemplo, el CRM puede almacenar información sobre los usuarios que han utilizado el simulador financiero y han mostrado interés en un préstamo.
Los datos guardados en el almacén de datos también pueden utilizarse para entrenar un modelo de aprendizaje automático o para alimentar motores basados en reglas y diseñados para producir la siguiente mejor acción o la siguiente mejor oferta para los usuarios. Las predicciones o recomendaciones de estos modelos también pueden enviarse al flujo, que sería recogido por el widget de recomendaciones del producto digital. Esto daría lugar a recomendaciones personalizadas para el usuario cuando visite el sitio.
Como los vendedores registran la información de la comunicación directa con un usuario, el CRM también puede producir eventos que se comparten al flujo. La base de datos de usuarios y el almacén de datos también se actualizarán en consecuencia sin tener que crear un acoplamiento directo entre todos estos servicios.
Caso de uso: Banco de Norteamérica
Uno de los mayores bancos del mundo por capitalización bursátil y con más de 16 mil millones de clientes quería mejorar la experiencia de los clientes y, al mismo tiempo, cumplir con la normativa del sector. Decidieron migrar a una arquitectura basada en eventos y transmitir datos en tiempo real.
Al igual que la mayoría de las instituciones financieras, tienen que ser muy cuidadosos con la forma en que maneja los datos de los clientes y, a medida que el banco crecía a lo largo del tiempo, el aprovechamiento de los datos en las diferentes funciones empresariales se hacía cada vez más complejo.
El banco comenzó esta transformación dividiendo sus grandes aplicaciones monolíticas en pequeños microservicios basados en la nube. Permitieron que estos microservicios se sincronizaran en tiempo real a través de procesadores de eventos, en lugar de conectarlos a una base de datos o a través de patrones ETL. Esto hizo posible la creación de sistemas más flexibles y desacoplados sin tener que reescribir todo desde cero.
Estos cambios han dado lugar a una mayor eficiencia a la hora de crear o actualizar aplicaciones y los datos pueden ahora compartirse fácilmente entre los equipos. El banco también fue capaz de reducir el tiempo de detección de anomalías de semanas en tiempo real tras migrar a una arquitectura basada en eventos.
Conclusión
En la última década, el revuelo en torno al aprendizaje automático y la inteligencia artificial ha hecho que las empresas se centren en cómo utilizar los algoritmos y los cálculos para generar valor. Resulta que los datos en sí mismos son una poderosa fuente de valor. Pueden suceder cosas increíbles cuando empezamos a juntar diferentes piezas de datos que antes estaban encerradas en diferentes silos.
Las arquitecturas basadas en eventos y los microservicios no tienen tanto que ver con un nuevo tipo de tecnología (porque no es nueva), sino que se trata de medir por primera vez cosas que antes ni siquiera se registraban, y de reunir datos que antes estaban separados.
El envío instantáneo de mensajes a toda la organización abre nuevas posibilidades de colaboración que antes no eran posibles. Al igual que la actividad cerebral aumenta cuando una persona se despierta de un sueño profundo, podemos ver que los procesos empiezan a acelerarse y que pueden desarrollarse nuevas ideas y funciones cuando las organizaciones despiertan ante la posibilidad de tener un sistema nervioso central.
Photo de Ramón Salinero en Unsplash.
