Guía para Arquitectos Sobre Cómo Implementar Arquitecturas Basadas en Eventos

Guía para arquitectos
sobre cómo implementar

arquitecturas basadas en
eventos
Comience a habilitar los eventos para su empresa con

estos seis pasos
Sumeet Puri
Director de soluciones de tecnología
A medida que las empresas empiezan
a funcionar cada vez más
en tiempo real y se enfocan más en la
experiencia del cliente, la arquitectura
de las aplicaciones debe actualizarse
para satisfacer estas necesidades, y
la arquitectura basada en eventos
representa el gran paradigma”.
Sumeet Puri
Director de soluciones de tecnología
© Solace
Todos los derechos reservados. Ninguna parte de este trabajo se puede reproducir o almacenar en un sistema de
recuperación, ni transmitirse de ninguna forma o por ningún medio, ya sea electrónico o mecánico, a través de una
fotocopia, mediante una grabación o de otro tipo, sin el permiso de Solace. Para realizar consultas sobre permisos,
envíe un mensaje a legal@solace.com.
2 Guía para arquitectos sobre cómo implementar arquitecturas basadas en eventos

Índice
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Un enfoque que prioriza los eventos. . . . . . . . . . . . . 5
Paso 1: Cultura, concientización e intención . . . . . . 7
Paso 2: Identifique candidatos para el desempeño

en tiempo real. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Paso 3: Desarrolle la base para eventos . . . . . . . . . 10
Paso 4: Elija una aplicación piloto . . . . . . . . . . . . . . 17
Paso 5: Descomponga el flujo de eventos en micros-

ervicios asíncronos y basados en eventos. . . . . . . . 19
Paso 6: Obtenga una victoria rápida . . . . . . . . . . . . 29
Conclusión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Introducción
Si su empresa es como la mayoría, las aplicaciones que impulsan su

negocio se ejecutan en diversos entornos, incluidos los centros de
datos en sitio, las oficinas locales, las plantas de fabricación y las
tiendas minoristas, por nombrar algunos.
La falta de compatibilidad y conectividad entre estos entornos obliga a sus aplicaciones a
interactuar mediante interacciones síncronas de solicitud/respuesta altamente acopladas,
procesos de ETL por lotes personalizados individualmente o, incluso, una integración
personalizada. Estas interacciones producen respuestas lentas y datos obsoletos. El
alto acoplamiento obstaculiza la agilidad para sus necesidades de negocio en constante
cambio y sus demandas en tiempo real.
Para que una empresa funcione en tiempo real, los eventos deben transmitirse entre
las aplicaciones y los microservicios que los procesan para que se pueda obtener infor-
mación y tomar decisiones de forma rápida. Para ser más receptivo y aprovechar las
nuevas tecnologías, como la nube, el IoT, los microservicios, entre otras, la arquitectura de
su empresa debe soportar interacciones en tiempo real basadas en eventos.
Cada proceso de negocio es, en esencia, una serie de eventos. En general, un “evento”
se puede describir como una notificación de cambio. Estos cambios pueden adoptar
diversas formas, pero todas tienen la estructura común de una acción que ocurrió en un
objeto. La arquitectura basada en eventos es solo una forma de desarrollar sistemas de
TI empresariales que permitan que las aplicaciones y los microservicios desacoplados
produzcan y consuman estos eventos.

Implementar una arquitectura basada en eventos representa un camino por recorrer y,
al igual que todos los caminos que se emprenden, empieza con un solo paso. Para dar
sus primeros pasos, debe tener un buen conocimiento de sus datos, pero, lo que es más
importante, debe adoptar un enfoque que priorice los eventos.
Sumeet Puri, director de tecnología y soluciones, explicará una estrategia segura sobre
cómo su empresa puede implementar la arquitectura basada en eventos con las herra-
mientas adecuadas para superar los desafíos que, posiblemente, enfrente en el camino.
Con su proceso de seis pasos comprobado en el campo, estará bien orientado para
conseguir la participación de las partes interesadas clave y transformar toda su organi-
zación.
Un enfoque que prioriza los eventos

La arquitectura basada en eventos no es nueva: las GUI y las plataformas de transac-
ciones en el mercado de capitales siempre se han desarrollado de esta manera. Ahora
solo se está volviendo más predominante. Esto se debe, principalmente, a que la arqui-
tectura orientada a servicios (SOA, por sus siglas en inglés); el proceso de extraer, trans-
formar y cargar (ETL, por sus siglas en inglés); y los procesos por lotes deben evolucionar
para satisfacer las necesidades en tiempo real.
Sin embargo, antes de comenzar este recorrido de transformar la arquitectura de su
empresa en una arquitectura más receptiva, ágil y en tiempo real, debe considerar que
todo lo que ocurre en su empresa es un evento digital y, a la vez, debe pensar en esos
eventos digitales como ciudadanos de primera clase en su infraestructura de TI.
Con la arquitectura basada en eventos, las aplicaciones y los microservicios se comunican
a través de eventos o adaptadores de eventos. Los eventos se enrutan entre estas aplica-

ciones en una forma de publicación/suscripción según las suscripciones que indican su
interés en todo tipo de tópicos.
En otras palabras, en lugar de un proceso por lotes o un bus de servicio empresarial (ESB,
por sus siglas en inglés) que orquesta un flujo, los flujos empresariales se coreografían de
forma dinámica en función del interés y la capacidad de cada componente de la lógica
empresarial. Esto hace que sea mucho más fácil agregar nuevas aplicaciones,
ya que pueden aprovechar el flujo de eventos sin afectar a ningún otro sistema, hacer su
tarea y agregar valor.
Entonces, ¿cómo hace eso? ¿Cuál debería ser su estrategia?
En un alto nivel, si su organización quiere convertirse en una empresa basada en eventos,
debe realizar tres acciones:
1. Habilitar sus sistemas existentes para eventos.
2. Modernizar su plataforma para que admita la transmisión en todos los entornos.
3. Alertar e informar a las partes interesadas internas y externas.
Entonces, la siguiente pregunta

01 07
es: ¿cómo se ponen en práctica Culture Scale
Awareness, &
06
Intent
estos pasos? Los siguientes Implement
Quick Win 02
seis pasos utilizan la estrategia Real Time
Event Driven Candidates
Methodology
anterior y han demostrado que
05 Be Event
hacen que el recorrido hacia la Event Driven Driven 03
Design Event
Streaming
arquitectura basada en eventos 04 Foundation
Pilot Selection &
sea más rápido, más ágil y Event Catalog

menos arriesgado en muchas implementaciones del mundo real.
Paso 1: Cultura, concientización e intención
¿Está listo para implementar una arquitectura basada en eventos,

es consciente de lo que eso implica y tiene la intención de hacerlo?
Estoy seguro de que, si está leyendo esto, entonces la respuesta es “sí”. Sin embargo,
la mayoría de las personas que trabajan en el sector de TI fueron formadas para pensar
de manera procedimental. Ya sea que haya comenzado con Fortran o C, como yo, o
Java o Node, la mayor parte de la formación y experiencia en TI ha girado en torno a las
llamadas a funciones síncronas o a las llamadas a procedimiento remoto (RPC, por sus
siglas en inglés) o a los servicios web a las API; todos síncronos. Existen excepciones a la
regla: los sistemas de front-office de los mercados de capitales siempre se han basado en
eventos porque tenían que ser en tiempo real desde el principio. Sin embargo, la mayoría
de las veces, la TI necesita un pequeño cambio en la cultura.
Los microservicios no necesitan comunicarse unos con otros y crear un monolito
distribuido. Como arquitecto, siempre que sepa cuáles aplicaciones o microservicios
consumen y producen qué eventos, puede, simplemente, coreografiar mediante el uso
de un broker de eventos de publicación/suscripción o una red distribuida de brokers, que
también se denomina “Event Mesh”, en lugar de orquestar con un ESB.
Es importante reflexionar un poco, leer, capacitarse y formar a las partes interesadas
sobre los beneficios de la EDA: agilidad, capacidad de respuesta y mejores experiencias
para el cliente. Cree soporte, elabore estrategias y asegúrese de que el próximo proyecto
(la próxima transformación, el próximo microservicio, la próxima API) esté basado en
eventos.

Deberá pensar en qué casos de uso pueden ser candidatos, analizarlos desde una
perspectiva basada en eventos y articular un enfoque de referencia para obtener los
beneficios.
Piense en tiempo real basándose en eventos.
Paso 2: Identifique candidatos para el

desempeño en tiempo real
No todos los sistemas necesitan cambios o pueden modificarse

para funcionar en tiempo real. Sin embargo, la mayoría se benefi-
ciará de un enfoque basado en eventos.
Es posible que ya haya pensado en un montón de proyectos, API o candidatos que se
beneficiarían de desempeñarse en tiempo real.
¿Cuáles son los candidatos para desempeñarse en tiempo real en su empresa? ¿El
problemático sistema de gestión de pedidos? ¿La plataforma de pagos de próxima
generación que está desarrollando? ¿Tendría más sentido propagar los datos maestros,
como las actualizaciones de precios o los cambios de fórmulas de PLM, a las aplicaciones
posteriores, en lugar de sondearlos? ¿Lo motiva la posibilidad de recibir un ascenso de
clase en tiempo real gracias a los puntos de fidelidad de una aerolínea cuando se escanea
una tarjeta de embarque? ¿O la optimización en tiempo real de las operaciones terrestres
en el aeropuerto?

Encontrará varios candidatos con diferentes prioridades y desafíos, así que busque
proyectos que cumplan con estos criterios:
• Eliminen dificultades, es decir, vulnerabilidades, problemas de rendimiento, nueva

funcionalidad.
• Provoquen un impacto comercial medio a alto.

• Sirvan como una solución que brindará valor comercial e infundirá optimismo a su
equipo.
Al empezar con un proyecto pequeño, es posible que comience a encontrar las peculiar-
idades únicas de su organización que, inevitablemente, estarán presentes a mayor escala.
Tenga en cuenta que no todas las fuentes de datos son candidatas para la arquitectura
basada en eventos. Encuentre un sistema que tenga capacidades robustas de generación
de datos y que se pueda modificar de forma fácil para enviar mensajes. Estos mensajes se
aprovecharán como sus eventos más adelante en el recorrido.
Haga una preselección de candidatos para su recorrido hacia el enfoque basado en
eventos. También es importante involucrar a las partes interesadas en esta etapa
temprana porque los eventos, a menudo, están basados en el negocio, por lo que no
todas las partes interesadas tendrán conocimientos técnicos. Considere qué equipos se
verán afectados por la transformación y qué personas específicas deberán participar y dar
su aceptación para que el proyecto sea un éxito desde todo punto de vista.

Paso 3: Desarrolle la base para eventos
Y ahora es el turno de las herramientas. Una vez que se identifica

el primer proyecto, es momento de pensar en la arquitectura y las
herramientas.
Una arquitectura basada en eventos dependerá de descomponer los flujos en microser-
vicios y de poner en marcha un servicio de contenedores que les permita a los microser-
vicios conectarse entre sí con un patrón distribuido de publicación/suscripción, de uno a
muchos.
También es importante comenzar de manera correcta con el tiempo de diseño y tener las
herramientas para garantizar que los eventos se puedan describir y catalogar, y que se
visualicen sus relaciones.
Usted querrá tener una arquitectura lo suficientemente modular como para satisfacer
todos sus casos de uso y lo suficientemente flexible como para recibir datos de todos
los lugares donde estén implementados, ya sea en sitio, en la nube privada, en la nube
pública, entre otros. Aquí entra la plataforma de gestión de eventos con el tiempo de
ejecución del Event Mesh.
Tener una plataforma de gestión de eventos, incluso los elementos más básicos, le
permite a su primer proyecto aprovecharla a medida que los microservicios y los eventos
comienzan a conectarse y comunicarse entre sí, en lugar de a través de REST, lo que da
como resultado un monolito distribuido.

Los siguientes elementos del tiempo de ejecución y de diseño son esenciales:
• Broker de Eventos • Event Portal

• Event Mesh • La taxonomía de los eventos
Broker de Eventos
Un broker de eventos es el componente fundamental del tiempo de ejecución para
el enrutamiento de eventos con un patrón de publicación/suscripción, baja latencia
y entrega garantizada. Las aplicaciones y los microservicios se desacoplan entre sí y
se comunican a través del broker de eventos. Los eventos se publican en el broker de
eventos a través de tópicos que siguen una jerarquía o taxonomía, correspondientemente
suscritos por una o más aplicaciones o microservicios, motores de análisis o lagos de
datos.
Un broker de eventos ideal utiliza protocolos abiertos y API para evitar la dependencia
de proveedores. Con estándares abiertos, tiene la flexibilidad de elegir el proveedor de
broker de eventos apropiado con el paso del tiempo. Piense en la independencia que
TCP/IP les ofreció a los clientes al elegir equipos de red: los estándares abiertos crearon
la Internet. Al aprovechar la comunidad de código abierto, es más fácil crear cambios
sobre la marcha, y no tiene que limitarse a tener que consultar documentación cerrada o
esperar en una cola de soporte.

Por último, un broker de eventos ideal es simple. Ofrece simplicidad en la imple-
mentación, control de eventos y escalabilidad, lo que le brinda la libertad de concentrarse
en lo que importa: sus eventos.
Event Mesh
Aunque puede empezar con un solo broker de eventos en una única ubicación, a
menudo, las aplicaciones modernas están distribuidas. Ya sea en sitio, en múltiples nubes
o en fábricas, sucursales y tiendas minoristas, las aplicaciones, los microservicios y las
capacidades de información están distribuidas.
Un evento que se origina en una tienda minorista puede tener que dirigirse a los sistemas
de una tienda local, al ERP centralizado, al lago de datos basado en la nube y a un socio
externo. Como tal, la distribución de eventos debe ser clara para los productores y los
consumidores. Estos se deben conectar a su broker de eventos local, al igual que usted o
yo nos conectamos a nuestro enrutador WiFi doméstico para acceder a todos los sitios
web, sin importar dónde estén alojados.
La arquitectura basada en eventos es un sistema en constante evolución, por lo que si
identifica fuentes de eventos en sitio hoy, es posible que vea que esos eventos residen
en la nube mañana.
Un Event Mesh es una red de brokers de eventos que enruta dinámicamente eventos
entre aplicaciones sin importar dónde se implementen, ya sea en sitio o en cualquier
nube o evento en ubicaciones periféricas de la IoT. Al igual que la Internet es posible
gracias a los enrutadores que convergen tablas de enrutamiento, el Event Mesh converge
suscripciones por tópicos con varias optimizaciones para transmitir eventos distribuidos.

Hay varias formas en que un Event Mesh es compatible con la arquitectura de su
aplicación:
• Conecta y coreografía microservicios mediante publicación/suscripción, filtrado de

tópicos y entrega garantizada a través de una red distribuida.
• Propaga eventos desde servicios y aplicaciones en sitio a la nube.

• Permite transformaciones digitales para la Internet de las cosas (IoT).
• Habilita los datos como servicio (DaaS, por sus siglas en inglés) en todas las líneas
de negocio para obtener información, análisis, ML, entre otros.
• Le brinda una forma mucho más reactiva y receptiva de sumar eventos.
Por supuesto, la forma en que implemente su Event Mesh ayudará a determinar el tipo
de broker de eventos que busca.
Event Portal
Un portal de eventos, al igual que un portal de API, es la visualización del diseño y del
tiempo de ejecución de su Event Mesh. Un portal de eventos les brinda a los arqui-
tectos una herramienta sencilla basada en GUI para definir y diseñar eventos de manera
gobernada. Además, los ofrece para que publicadores y suscriptores los utilicen. Una vez
que haya definido los eventos, puede diseñar microservicios o aplicaciones en el portal de
eventos y elegir qué eventos consumirán y producirán al navegar y buscar en el catálogo de
eventos.
A medida que se definen sus eventos, se ingresan en un catálogo de eventos para su
detección. Un catálogo de eventos le ofrece visibilidad de sus eventos. Aunque es más
un paso de documentación, esto ayudará a visualizar y describir los eventos que puede
procesar. Cuando se desarrolla el sistema para obtener más fuentes de eventos y

diferentes formas de consumirlas, el catálogo es una excelente referencia para saber lo
que ya se ha creado a fin de evitar la duplicación de esfuerzos.
La taxonomía de los eventos

El enrutamiento de tópicos es la esencia de una arquitectura basada en eventos. Los
tópicos son metadatos de eventos; etiquetas con la forma a/b/c, al igual que una URL
HTTP o una ruta de archivo, que describen el evento. El broker de eventos entiende los
tópicos y puede enrutar eventos en función de quién se haya suscrito a ellos, incluidas las
suscripciones comodín.
Al comenzar su recorrido hacia una arquitectura basada en eventos, es importante
prestar atención a la taxonomía de los tópicos: establecer una convención de nomen-
clatura de tópicos desde el principio y gobernarla. Una taxonomía sólida es, proba-
blemente, la inversión de diseño más importante que hará, por lo que es mejor no
apresurarse aquí. Tener una buena taxonomía ayudará de manera significativa con el
enrutamiento de eventos, y las convenciones serán evidentes para los desarrolladores de
aplicaciones. Si desea obtener más información sobre las prácticas recomendadas para la
jerarquía de tópicos, visite bit.ly/topic-hierarchy

Ejemplo de Udders Ice Cream: Taxonomía
de los eventos
Veamos un ejemplo de los pedidos de Udders Ice Cream. Ha llegado un pedido del
sabor “ron con pasas” del sitio web de comercio electrónico Lazada en Singapur:
Evento Tópico
Pedido nuevo order/init/1.1/icecream/udders/rumraisin/sg/lazada
Pedido validado order/valid/1.1/icecream/udders/rumraisin/sg/lazada
Envío del pedido order/shipped/1.1/icecream/udders/rumraisin/sg/lazada

Debido a que los eventos del publicador (microservicio, aplicación, adaptador de aplica-
ciones heredadas a eventos) tienen tópicos como metadatos, los consumidores pueden
usarlos para suscribirse a eventos.
Evento Publicador Suscriptor

Sitio de la tienda
Microservicio de validación de
Pedido nuevo de comercio electrónico de
pedidos
Lazada
Procesador de pedidos para

Pedido Microservicio de validación
helados
validado de pedidos
en Singapur
Envío del Lago de datos o procesador de

Alguna aplicación anterior
pedido AI/ML
Las suscripciones a tópicos serían las siguientes:
• Consumir y validar todos los pedidos de la versión 1.1 y publicar el mensaje

de validez del pedido: order/init/1.1/>
• Consumir y procesar todos los pedidos válidos de helado con origen en

Singapur: order/valid/*/icecream/*/*/sg/*
• Todos los pedidos sin importar la etapa, categoría, ubicación: order/>
Alineación de la organización
La arquitectura basada en eventos comienza siendo pequeña y crece, pero, con el
tiempo, la organización debe evolucionar hacia un enfoque que priorice los eventos. Esto
requiere un poco de liderazgo de pensamiento para obtener la aceptación. El equipo de
ESB debe empezar a considerar la coreografía, en lugar de la orquestación. Los equipos
de API deben empezar a pensar en las API basadas en eventos, en vez de solo en solic-
itudes/respuestas.

Paso 4: Elija una aplicación piloto
El siguiente paso para implementar su arquitectura basada en

eventos es determinar con qué flujo de eventos comenzar primero.
En esencia, un flujo de eventos es un proceso de negocio que se traduce en un proceso
técnico. El flujo de eventos es la forma en que se genera un evento, se envía a través
de su broker y, finalmente, se consume.
Comenzar con un proyecto piloto es la mejor manera de aprender a través de la experi-
mentación antes de escalar.
Con el proyecto piloto, a medida que identifique eventos y el flujo de eventos, el catálogo
de eventos también comenzará a tomar forma automáticamente. Ya sea que mantenga el
catálogo en una hoja de cálculo simple o en un portal de eventos, el catálogo de eventos
inicial también sirve como punto de partida de eventos reutilizables, que las aplicaciones
en el futuro podrán consumir fuera del Event Mesh.
Usted desea elegir el flujo que sea más adecuado para modernizar su estado actual o
minimizar de las dificultades. Un proyecto en desarrollo o una inminente transformación
son candidatos ideales, ya sea para la innovación o para reducir la deuda técnica a través
del rendimiento, la solidez o la adopción de la nube. El objetivo es que se convierta
en una referencia para las futuras implementaciones. Elija un flujo que pueda ser su
solución.

A modo de ejemplo, considere este flujo para cambiar los precios de un producto:
ESB
API
GetPrice
Request Reply
API
GetPrice
Request Reply
API
Price Change
EVENT Exposure GetPrice
Price API Request Reply
API
Cambiar el precio en sí mismo se considera el evento: el “precio” es el sustantivo y
“cambiar” es el verbo.
En una arquitectura existente que no está habilitada para eventos, el evento de cambio
de precio:
• No se propaga: se requiere una API de solicitud/respuesta o, probablemente,

incluso un proceso por lotes.
• No se produce en tiempo real: las aplicaciones posteriores no saben sobre el

cambio de precio hasta que preguntan.
• No es rentable para escalarlo.

• Genera tráfico en ráfagas: las aplicaciones de eventos llaman continuamente a la
API, lo que puede provocar carga/tráfico en ráfagas.
Al propagar los cambios de precio como eventos e implementar la arquitectura basada
en eventos con un Event Mesh, las aplicaciones posteriores se suscriben a los eventos de

cambio de precio y reciben notificaciones de eventos a medida que ocurren en tiempo
real. El Event Mesh filtra y solo propaga los eventos a los que se han suscrito las aplica-
ciones (de acuerdo con la taxonomía de los tópicos).
Los eventos se ponen en cola y se dosifican para reducir la carga, lo que facilita su
escalamiento. También se entregan de forma garantizada y sin pérdidas.
Also exposed Request Subscribe for

Reply APIs Price Update
ESB EVENT
API
Subscribe for
Price Update
Price EVENT
Expose
Change
Price EVENT
EVENT
API
Subscribe for
Price Update
EVENT
Publish Event to the Event Mesh
Paso 5: Descomponga el flujo de eventos en

microservicios asíncronos y basados en eventos
Una vez que se han identificado los flujos piloto y se está

comenzando con un catálogo de eventos inicial, el siguiente paso
es iniciar un diseño basado en eventos al descomponer el flujo
comercial en microservicios basados en eventos e identificar
eventos en el proceso.

Descomponer un flujo de eventos en microservicios reduce el esfuerzo total que se
requiere para consumir fuentes de eventos, ya que cada microservicio manejará un solo
aspecto del flujo total de eventos. Se puede crear una nueva lógica empresarial con
microservicios, mientras que las aplicaciones existentes (SAP, “mainframes”, aplicaciones
personalizadas) se pueden habilitar para eventos con adaptadores.
Orquestación vs. coreografía de microservicios

Hay dos formas de administrar los microservicios en sus flujos de eventos: orquestación
y coreografía. Con la orquestación, sus microservicios funcionan en forma de llamada y
respuesta (solicitud/respuesta), y están altamente acoplados, es decir, dependen mucho
uno del otro, la conexión entre ambos es muy fuerte. Con la coreografía de enrutamiento
de eventos, los microservicios son reactivos (responden a los eventos a medida que
ocurren) y están desacoplados, lo que significa que, si una aplicación falla, los servicios
comerciales que no dependen de ella pueden seguir funcionando mientras se resuelve el
problema.
Ahora, deberá identificar qué pasos deben realizarse de forma síncrona y cuáles pueden
ser asíncronos. Los pasos síncronos son los que deben ocurrir cuando la aplicación o API
que invoca el flujo está esperando una respuesta o la está bloqueando.
Los eventos asíncronos pueden ocurrir después del hecho y, a menudo, en paralelo, como
el registro en bitácoras, la auditoría o la escritura en un lago de datos. En otras palabras,
las aplicaciones que no tienen problema con ser “eventualmente consistentes” se pueden
tratar de forma asíncrona. Los eventos flotan y la coreografía de los microservicios
determina cómo se procesan. Debido a estas distinciones clave, debe mantener las partes
síncronas del flujo separadas de las partes asíncronas.

Este modelado de procesos controlados por eventos se puede hacer de manera manual al
principio o con un portal de eventos, en el que puede visualizar y coreografiar los micros-
ervicios.
Ejemplo de Udders Ice Cream: Eventualmente consistentes
Uno de los problemas con un sistema basado en la API síncrona RESTful es que cada
paso del flujo comercial, cada microservicio, es secuencial. Cuando el sistema de POS de
Udders Ice Cream envía un pedido, ¿debe esperar a que se completen todos los pasos de
procesamiento del pedido, o solo algunos pasos obligatorios deben ser secuenciales?
Si piensa en ello, no es necesario que todos los procesos de “información” ocurran antes
de que los sistemas de punto de venta obtengan una confirmación del pedido, solo ralen-
tizarán el tiempo de respuesta general. En realidad, solo el procesamiento y la validación
del pedido deben ser secuenciales; todo lo demás se puede hacer de forma asíncrona.
Order Inventory Payment Payment

Validator Credit Check Check Processor Processor
Microservice Microservice Microservice Microservice Microservice
Synchronous,
Parallel Path Cross Sell Data Lake Insights
Upsell Ingestor AI ML
Eventually Consistency Microservice Microservice Microservice
Deferred Execution
El Event Mesh proporciona una entrega garantizada, por lo que los microservicios que
no sean secuenciales pueden obtener los datos un poco después, pero de forma limitada
y garantizada. El flujo de eventos fluye hacia los sistemas de manera paralela, lo que
mejora aún más el rendimiento y la latencia.

Oyentes dependientes
A medida que los eventos fluyen y se catalogan, el análisis, las auditorías, el cumplimiento
y los lagos de datos también pueden consumirlos. Las aplicaciones autorizadas recibirán
un flujo de eventos filtrado y basado en comodines de manera distribuida sin cambios en
el microservicio existente ni en el ESB o el ETL.
Fuentes y receptores de eventos:

Cómo abordar las aplicaciones heredadas
Hay un par de fuentes y receptores de eventos que debe tener en cuenta. Algunas
fuentes y receptores ya se basan en eventos, y es poco el procesamiento que debe imple-
mentar para consumir estos eventos. Llamemos a las demás “aplicaciones preparadas
para API”. Este término significa que tienen una API que puede generar mensajes que
su broker de eventos puede consumir, en general, a través de otro microservicio u otra
aplicación. Aunque se requiere cierto esfuerzo de desarrollo, puede hacer que estas
fuentes funcionen con su broker de eventos de forma bastante sencilla. Luego, están las
aplicaciones heredadas que no están preparadas de ninguna manera para enviar o recibir
eventos, lo que dificulta su incorporación en aplicaciones y procesos basados en eventos.
¡Haga clic para twittear!

La arquitectura basada en eventos comienza siendo pequeña y crece, pero,
con el tiempo, la organización debe evolucionar hacia un enfoque que
priorice los eventos.

A continuación, verá un desglose de los tres tipos de fuentes y receptores de eventos:
Basada en eventos Preparada para API Heredada
¿Estado de la Basada en eventos Tiene una API REST/ No hay API basada en
API? de forma nativa SOAP con esquemas estándares, aunque puede
haber varias formas de
conectarla
¿Capacidades Puede propagar Solicitud/respuesta, Se pueden extraer o sondear

de eventos, puede sin noción de tópicos periódicamente los datos, pero
propagación/ consumir eventos ni propagación también pueden activarse
extracción?
¿Adaptadores No se necesita Necesita microservicios o Necesita un adaptador de

para ninguno flujo de transmisión para integración (JDBC, MQ,
transmisión? transformar la fuente de JCA, ASAPIO, Striim, ESB
solicitud-respuesta en un heredados) instalado cerca de
destino de transmisión la fuente del destino del evento
y publicar un tópico para transformar y publicar/
inteligente suscribir eventos
Aplicaciones basadas en eventos

Las aplicaciones basadas en eventos pueden publicar eventos y suscribirse a estos, y
tienen en cuenta el tópico y la taxonomía. Son en tiempo real, receptivas y usan el Event
Mesh para el enrutamiento de eventos, la consistencia eventual y la ejecución diferida.
Aplicaciones preparadas para API

Aunque es posible que las aplicaciones preparadas para API no puedan publicar eventos
en el tópico correspondiente, pueden publicar eventos que se pueden consumir a través
de una API. En este caso, se puede usar un microservicio adaptador para suscribirse a la
API “nativa” (un Event Mesh puede convertir las API REST en tópicos), inspeccionar la

carga útil y publicar el mensaje en los tópicos apropiados derivados del contenido de la
carga útil. Este enfoque funciona mejor que el enrutamiento basado en contenido,
ya que este requiere la gobernanza de las cargas útiles de formas muy estrictas que
incluyen la semántica, lo que no siempre es práctico.
Aplicaciones heredadas
Probablemente, tendrá algunos sistemas heredados que ni siquiera están habilitados
para API. Dado que la mayoría de los procesos de negocio consumen o aportan datos a
estos sistemas heredados, deberá determinar cómo integrarlos con su Event Mesh. ¿Va
a sondear periódicamente el sistema? ¿O invocarlos a través de adaptadores cuando
haya una solicitud de datos o actualizaciones? ¿O aplicará mecanismos de salida para los
eventos y los almacenará en la memoria caché a nivel externo? En cualquier caso, deberá
averiguar cómo habilitar para eventos a los sistemas heredados que ni siquiera tienen una
API con la que conectarse.
La clave para adaptar los sistemas heredados es identificarlos temprano y comenzar a
trabajar en ellos lo más rápido posible.
Para obtener más detalles y ejemplos, visite bit.ly/sources-and-sinks.
Conviértase en nativo de la nube a medida que pueda

La accesibilidad y escalabilidad de la nube refleja la de un Event Mesh. Son candidatos
perfectos para implementar juntos. Ahora bien, no puede esperar que todos sus eventos
se generen o procesen en la nube. Ignorar los sistemas en sitio sería un descuido
evidente. Con la adopción de un Event Mesh, no importa dónde estén sus datos, por lo
que puede adoptar un enfoque híbrido más fácil.

Por ejemplo, su lago de datos podría estar en Azure mientras que sus capacidades de AI
y ML podrían estar en GCP. Es posible que cuente con fabricación y logística en China
o Corea y con un mercado en India o los Estados Unidos. Con el 5G a punto de desen-
cadenar la próxima ola de conectividad global, su infraestructura basada en eventos
necesita trabajar mano a mano con dos patrones, a 180 grados de distancia: híbrido/nube
múltiple y un perímetro inteligente.
Al usar los protocolos estandarizados, la taxonomía y un Event Mesh, usted puede
ejecutar la lógica de negocio donde quiera.
Ejemplo de Udders Ice Cream: Gestión de pedidos
Un proceso de gestión de pedidos para Udders Ice Cream puede ver estos microser-
vicios en un flujo de eventos que sigue un punto de venta:
• Validador de pedidos • Procesador de pagos

• Verificación del crédito • Procesador de pedidos
• Verificación de inventario

Un pedido de helado de ron con pasas se inicia cuando un sistema de punto de venta
realiza una llamada a la API para enviarlo:
Order INIT Event

Topic [or REST URL]
order/init/1.1/icecream/udders/rumrasin/sg/711
Publish Order Event
Payload:
010010101010001010101011110101010101010
Store 010010101010001010101011110101010101010
El microservicio Validador de pedidos consume el nuevo evento de pedido y genera
el pedido válido o el evento de pedido no válido. Luego, el microservicio Verificación
del crédito consume el evento de pedido válido, que de manera similar produce los
siguientes eventos.
Order Init Event OrderValid Event
Subscribed Event: Published Event:

order/init/1.1/*/*/*/sg/> order/valid/1.1/icecream/udders/rumrasin/sg/711
Order
Validator
Microservice
Published Event:
order/invalid/1.1/icecream/udders/rumrasin/sg/711
OrderInvalid Event
• Eventos suscritos: Todas las admisiones de pedidos, independientemente de la

versión y el producto
• Eventos publicados: Estado de validación de pedidos con otros metadatos

Ejemplo de Udders Ice Cream: Enrutamiento
de los eventos
Problema: Las reglas de validación de pedidos se modificaron de Singapur a Estados
Unidos y la carga útil cambió de JSON a protobufs.

order/init/1.1/*/*/*/sg/>
Subscribed Events:
All orders initiations, for payload
version 1.2, from Singapore
Order
Validator
Microservice
OrderInvalid Event
Solución: Se crea un nuevo microservicio (reutilizado) para abastecer la lógica
comercial de validar pedidos de los Estados Unidos con la nueva carga útil y modificar
las suscripciones al tópico. Los nuevos microservicios comienzan a escuchar el tópico
relevante y consumen eventos de admisión de pedidos de los Estados Unidos de la
versión 1.2. ¡No cambió nada más!

order/init/1.2/*/*/*/us/>
Subscribed Events:
All orders initiations, for payload
version 1.2, from USA
Order
Validator
Microservice
OrderInvalid Event

Problema: Quiere supervisar todos los pedidos procedentes de la cadena de 711.
Solución: Implemente un microservicio con la lógica comercial de información
relevante, busque el evento en el catálogo de eventos y empiece a suscribirse a
eventos usando comodines.
Subscribed Event:
order/init/1.1/*/udders/*/*/711
Subscribed Events:
Only Udders orders initiations,
irrespective of version and product,
and country, but from 711 Udders
Icecream
Analytics
Microservice
OrderInvalid Event

Paso 6: Obtenga una victoria rápida
Una vez que se realiza el diseño y se entrega la primera aplicación

como una aplicación nativa de evento, el catálogo de eventos
también comienza a completarse.
Obtener una victoria rápida con el catálogo de eventos como el entregable principal es
tan importante como la otra lógica de negocio, e impulsa la innovación y la reutilización.
Con suerte, gracias a la capacidad de realizar más acciones en tiempo real, podrá
demostrar la agilidad y capacidad de respuesta de las aplicaciones, lo que a su vez
conducirá a una mejor experiencia del cliente. Con la participación de los interesados,
¡puede ayudar a transformar toda la organización!
Paso adicional: Repita el proceso
Ahora que tiene su plantilla para basarse en eventos y, con suerte,

su primera victoria rápida en marcha, puede repetir el proceso.
¡Continúe y elija su próximo flujo de eventos!
Desde aquí, puede seguir nuevamente los pasos para los próximos proyectos. A medida
que avanza, el catálogo de eventos en su portal de eventos se completará con cada vez
más eventos. Los eventos existentes empezarán a ser reutilizados por nuevos consum-
idores y productores. Un catálogo más rico dará lugar a más oportunidades para el proce-
samiento y la información en tiempo real.

El cambio de cultura es una constante, pero se vuelve más fácil al exponer el éxito.
El equipo de integración/middleware podría poseer el catálogo de eventos y el Event
Mesh, mientras que los equipos de aplicación y LOB los utilizan/hacen sus aportes. Los
catálogos de eventos específicos de LOB y los brokers de eventos localizados también
son patrones atractivos, dependiendo de cuán federados o centralizados sean los equipos
y procesos tecnológicos de la organización.
A medida que escala, más aplicaciones producen y consumen eventos, a menudo
comenzando con la reutilización de eventos existentes. ¡Así es cómo se multiplica el
recorrido basado en eventos a medida que escala!
Conclusión
Las necesidades comerciales en tiempo real y en constante cambio

tienen una demanda: la transformación digital. El mundo no se está
ralentizando, por lo que lo mejor que puede hacer es identificar
formas en las que puede, de manera rentable y eficiente, actualizar
la arquitectura de su empresa para adaptarse al momento.
Sin embargo, no es una tarea fácil.
La mayoría de las personas que trabajan en el sector de TI fueron formadas para
pensar de manera procedimental. Ya sea que haya comenzado con Fortran o C o Java
o Node, la mayor parte de la formación y experiencia en TI ha girado en torno a las
llamadas a funciones, a las llamadas a RPC, a los servicios web, a las API o a los flujos
de orquestación de ESB; todos síncronos. Naturalmente, lidiar con el mundo de la
mensajería asíncrona requiere un pequeño cambio de cultura, un pequeño cambio en el
proceso de pensamiento.

Los microservicios no necesitan comunicarse unos con otros y crear un monolito
distribuido. Los eventos pueden flotar en un Event Mesh para que sus microservicios
los consuman y actúen al respecto. Los arquitectos y desarrolladores necesitan una
plataforma y un conjunto de herramientas que los ayuden a trabajar juntos para lograr los
objetivos en tiempo real y basados en eventos para sus organizaciones.
Con estos seis pasos, puede dar el salto al disponer de la estrategia y las herramientas
correctas que respaldarán su recorrido en tiempo real basado en eventos. Solace
PubSub+ Platform ayuda a las empresas a diseñar, implementar y administrar arqui-
tecturas basadas en eventos y se puede implementar en cada nube y plataforma como
servicio. Solace es la única solución estable y eficaz que se adapta a las necesidades
únicas de los arquitectos que buscan implementar una arquitectura basada en eventos
dentro de sus organizaciones.
Acerca de Sumeet Puri

Sumeet Puri es el director de soluciones de tecnología de Solace,
donde ayuda a los CIO, los CTO y los arquitectos jefes en sus recor-
ridos de transformación tecnológica basada en eventos en tiempo
real. Sumeet es un orador público habitual en foros de tecnología.

Ottawa | Toronto | New York | Chicago | Atlanta | Silicon Valley | London
Paris | Zurich | Tokyo | Seoul | Hong Kong | Shanghai | Singapore | Mumbai
New Delhi | Melbourne | Sydney | Mexico City | São Paulo
Acerca de Solace
Solace ayuda a las grandes empresas a modernizarse y a funcionar en “tiempo real”, al
brindarles todo lo que necesitan para hacer que su operación de negocio e interacción
con clientes sean basadas en eventos. Con PubSub+, la primera y única plataforma de
gestión de eventos del mercado, Solace brinda una manera integral de crear, documentar,
descubrir y transmitir eventos desde donde se producen hasta donde necesitan
consumirse de forma segura, confiable, rápida y garantizada. Obtenga más información
en solace.com.
Síganos en

Algunos de nuestros clientes
Nuestros socios destacados

Guía para Arquitectos Sobre Cómo Implementar Arquitecturas Basadas en Eventos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guía para Arquitectos Sobre Cómo Implementar Arquitecturas Basadas en Eventos

Cargado por

Copyright:

Formatos disponibles

Guía para arquitectos

sobre cómo implementar

Comience a habilitar los eventos para su empresa con

2 Guía para arquitectos sobre cómo implementar arquitecturas basadas en eventos

Un enfoque que prioriza los eventos. . . . . . . . . . . . . 5

Paso 1: Cultura, concientización e intención . . . . . . 7

Paso 2: Identifique candidatos para el desempeño

Paso 3: Desarrolle la base para eventos . . . . . . . . . 10

Paso 4: Elija una aplicación piloto . . . . . . . . . . . . . . 17

Paso 5: Descomponga el flujo de eventos en micros-

Paso 6: Obtenga una victoria rápida . . . . . . . . . . . . 29

3 Guía para arquitectos sobre cómo implementar arquitecturas basadas en eventos

Si su empresa es como la mayoría, las aplicaciones que impulsan su

La falta de compatibilidad y conectividad entre estos entornos obliga a sus aplicaciones a

interactuar mediante interacciones síncronas de solicitud/respuesta altamente acopladas,

procesos de ETL por lotes personalizados individualmente o, incluso, una integración

personalizada. Estas interacciones producen respuestas lentas y datos obsoletos. El

alto acoplamiento obstaculiza la agilidad para sus necesidades de negocio en constante

cambio y sus demandas en tiempo real.

su empresa debe soportar interacciones en tiempo real basadas en eventos.

objeto. La arquitectura basada en eventos es solo una forma de desarrollar sistemas de

TI empresariales que permitan que las aplicaciones y los microservicios desacoplados

produzcan y consuman estos eventos.

4 Guía para arquitectos sobre cómo implementar arquitecturas basadas en eventos

importante, debe adoptar un enfoque que priorice los eventos.

conseguir la participación de las partes interesadas clave y transformar toda su organi-

Un enfoque que prioriza los eventos

ciones en el mercado de capitales siempre se han desarrollado de esta manera. Ahora

para satisfacer las necesidades en tiempo real.

Sin embargo, antes de comenzar este recorrido de transformar la arquitectura de su

eventos digitales como ciudadanos de primera clase en su infraestructura de TI.

Con la arquitectura basada en eventos, las aplicaciones y los microservicios se comunican

5 Guía para arquitectos sobre cómo implementar arquitecturas basadas en eventos

interés en todo tipo de tópicos.

forma dinámica en función del interés y la capacidad de cada componente de la lógica

tarea y agregar valor.

Entonces, ¿cómo hace eso? ¿Cuál debería ser su estrategia?

En un alto nivel, si su organización quiere convertirse en una empresa basada en eventos,

debe realizar tres acciones:

1. Habilitar sus sistemas existentes para eventos.

2. Modernizar su plataforma para que admita la transmisión en todos los entornos.

3. Alertar e informar a las partes interesadas internas y externas.

Entonces, la siguiente pregunta

6 Guía para arquitectos sobre cómo implementar arquitecturas basadas en eventos

Paso 1: Cultura, concientización e intención

¿Está listo para implementar una arquitectura basada en eventos,

Java o Node, la mayor parte de la formación y experiencia en TI ha girado en torno a las

de las veces, la TI necesita un pequeño cambio en la cultura.

Los microservicios no necesitan comunicarse unos con otros y crear un monolito

distribuido. Como arquitecto, siempre que sepa cuáles aplicaciones o microservicios

consumen y producen qué eventos, puede, simplemente, coreografiar mediante el uso

de un broker de eventos de publicación/suscripción o una red distribuida de brokers, que

también se denomina “Event Mesh”, en lugar de orquestar con un ESB.

Es importante reflexionar un poco, leer, capacitarse y formar a las partes interesadas

sobre los beneficios de la EDA: agilidad, capacidad de respuesta y mejores experiencias

(la próxima transformación, el próximo microservicio, la próxima API) esté basado en

7 Guía para arquitectos sobre cómo implementar arquitecturas basadas en eventos

perspectiva basada en eventos y articular un enfoque de referencia para obtener los

Piense en tiempo real basándose en eventos.

Paso 2: Identifique candidatos para el

No todos los sistemas necesitan cambios o pueden modificarse

Es posible que ya haya pensado en un montón de proyectos, API o candidatos que se

beneficiarían de desempeñarse en tiempo real.