Los equipos de desarrollo siempre han sido retados por requerimientos y problemas de negocio que no encajaban bien con el clásico enfoque online/sincrónico, en el cual un cliente hace una petición y se queda esperando la respuesta. Para muchos tipos de aplicaciones y sistemas este enfoque es suficiente, pero ante procesos de negocio con gran demanda o concurrencia se quedaba corto. Para afrontar este desafío, los equipos de desarrollo apuntaron a implementar flujos asincrónicos y/o reactivos que no dejen esperando al cliente/consumidor, sino que puedan responderle rápidamente y luego el sistema continúe con las operaciones tras bambalinas. Para implementar esta asincronía la industria se valió del concepto de colas de mensajería.

Esta idea/concepto no es nada nuevo y, para los que recordamos un poco de la vieja escuela, este tipo de flujos solían ser soportados con colas de sistema operativo como Microsoft Message Queue (MSMQ), opciones licenciadas como IBM MQ y opciones aún vigentes como RabbitMQ y ActiveMQ. Luego vinieron tendencias como Enterprise Service Bus (ESB) —parte de la tendencia SOA—, que eran plataformas que incluían capacidades de colas de mensajería.

En las tendencias modernas, el concepto sigue vigente, pero trasladándose a la nube como servicios PaaS. Además, ha evolucionado, complementándose con tendencias como la orientación a eventos. En este artículo no comentaré sobre la diferencia entre mensajería y orientación a eventos, pero sí se debe tener en cuenta que, por concepto, son diferentes, y es por ello que existen soluciones y servicios dedicados para mensajería y servicios dedicados para la orientación a eventos.

Azure, como plataforma cloud, cuenta con una serie de servicios que ayudan a implementar estos requerimientos y flujos asincrónicos. Por ejemplo, para colas de mensajería existen Queue Storage y Azure Service Bus; y para orientación a eventos se dispone de Event Grid y Event Hub. Ante esta variedad de alternativas, es frecuente tener la duda: ¿cuál elegir? Esto dependerá del caso de uso específico, pero aquí te dejo algunos criterios:

Azure Queue Storage

Queue Storage es la opción más ligera y económica que ofrece Azure; forma parte del servicio Account Storage. Se le puede considerar una cola de mensajería simple, sin todas las características que se buscan en un servicio empresarial, porque no permite implementar comportamiento. Por ejemplo, no garantiza validación de mensajes duplicados ni orden. Por lo tanto, si necesitas orden e idempotencia, debes asegurarte de implementarlos desde los consumidores.

Es ideal para flujos asincrónicos simples pero muy concurrentes, ya que escala a millones de mensajes. Puedes integrarlo con varios lenguajes, ya que Azure ofrece SDKs para facilitar la integración. Por otro lado, el SDK de Azure Functions permite integrarlo fácilmente con .NET, Java, Node y Python.

Azure Service Bus

Service Bus es el servicio de mensajería con características empresariales de Azure. Es ideal para garantizar orden y consistencia de entrega, validación de duplicados y diferentes patrones de reintento, ya que se basa en el protocolo AMQP, el cual asegura propiedades que fortalecen los flujos asincrónicos.

Además de colas, se pueden implementar los Topics o temas, que admiten múltiples suscriptores para lograr un comportamiento de entrega de mensajes tipo broadcast. Cada suscriptor puede implementar filtros y condiciones de reenvío para satisfacer necesidades específicas. Para integrarlo, Azure también cuenta con SDKs para varios lenguajes. El SDK de Azure Functions incluye triggers tanto para consumidores de cola como para suscripción a temas.

De lejos, es la opción ideal para flujos asincrónicos robustos y donde se necesita comportamiento. La limitante es el tamaño de la cola; por ende, en número de mensajes no escala tanto como Queue Storage.

Azure Event Grid

Event Grid es el servicio de Azure lanzado para cubrir la necesidad de las arquitecturas basadas en eventos. Trabaja como un enrutador de eventos e implementa el protocolo CloudEvents de la CNCF (Cloud Native Computing Foundation). Es ideal para flujos basados en eventos de aplicaciones transaccionales.

Azure Event Grid inicialmente nació para responder a eventos generados por recursos de Azure, como la creación de un Blob Storage, escaneos de Azure Defender, acciones en máquinas virtuales, entre otros. Sin embargo, ahora también admite eventos personalizados que pueden generarse desde tu aplicación.

Como mencioné, Azure permite que muchos recursos que generan acciones usen Event Grid como broker de estos eventos, y los suscriptores pueden ser tanto Azure Functions como incluso publicar mensajes en una cola de Azure Service Bus. Las posibilidades de integración para EDA son muy variadas.

Azure Event Hub

Event Hub, por otro lado, es el servicio de Azure ideal para streaming de eventos. Esto quiere decir: eventos pequeños que llegan en gran escala (miles a millones) y de forma continuada o ininterrumpida. Por ello es ideal para IoT y telemetría.

También suele usarse en arquitecturas de datos tipo streaming, donde se almacenan los millones de eventos entrantes en un Data Lake o en Blob Storage, para luego ser procesados por trabajos de Stream Analytics. A diferencia de Event Grid, no es un enrutador de eventos; de hecho, se asemeja más a un servicio del nivel de Kafka.

Conclusiones

• Es importante evaluar el escenario específico para un requerimiento o problema de negocio y, con base en ello, definir el mejor enfoque para implementar la asincronía o reactividad, ya sea que te decantes por usar colas de mensajería o por orientación a eventos.
• Azure, como plataforma, ofrece diferentes servicios para implementar colas de mensajería y arquitecturas orientadas a eventos. Qué servicio elegir dependerá de tus requerimientos no funcionales de concurrencia, escalabilidad, integración y políticas de reintento.

---

Sígueme en Linkedin para estar al tanto de mis publicaciones y novedades

Referencias

• Asynchronous messaging options