Azure Event Grid: The Evolution of an Event Broker in the Cloud

We'll take a look at the recent updates to the Event Grid service by the Microsoft Service Bus engineering team.

Steef-Jan Wiggers

12 December 2018

Microsoft offers various means of messaging services in Azure: Logic Apps, Service Bus, Event Hubs, Storage Queues, and Event Grid. The latter is the latest addition to Azure with the service going GA at the end of January of this year. With Azure Event Grid users can centrally manage their events in the cloud. Furthermore, Event Grid supports data events through a proprietary schema, and cloud events – a specification for describing event data in a standard way.

Last month the Microsoft Service Bus engineering team responsible for Event Grid added a few updates to the Event Grid service. These updates include an “Event Domains” feature, several new types of advanced filters, updates to some of Event Grid SDKs, a time-to-live feature for Event Subscriptions, and additional Portal UI support for configuring dead-lettering and retry policies.

Use cases

With Event Grid, developers will have the option to build a reactive application without the need for polling. They can develop an application subscribing to events they are interested in, and handle the event by applying their logic. For example, developers can create an application such as an Azure Function, Logic App or custom, that subscribes to events like storage blob events, provisioning notifications in an Azure subscription, IoT device signals, or even custom events.

Azure Event Grid Concepts

The concept of Azure Event Grid is simple – it is a pub-sub model. An event source pushes events to Azure Event Grid, and event handlers subscribe to events. An event source or publisher – an Azure service like Storage, IoT Hub, or a third party source emits an event, for instance, blobCreated or blobDeleted. You can send the event to a topic. Each topic can have one or multiple subscribers (event handlers). You can configure an Azure Service, if supported, as an event publisher or you create a custom Azure Event Grid Topic. Subsequently, the event handlers in Azure like Functions, WebHook, and Event Hubs can react to the events and process them.

Note that the pub-sub model of Azure Event Grid is not similar to service bus Topics and subscriptions. Moreover, Topics and subscription are push-pull, while the Azure Event Grid is push-push. See the difference in the picture below.

Event Domains

One of the new features in Event Grid is Event Domains, allowing users to a get fine-grained authorization and authentication control over each topic via the Azure Active Directory. An Event Domain is nothing more than an uber-topic that can manage the authentication, authorization, and publishing for thousands of topics immediately. Furthermore, the Event Domain also handles partitioning, which means instead of needing to publish events to each topic individually, users can publish all their events to the Domain’s endpoint. Subsequently, Event Grid takes care of ensuring each event will be sent to the correct topic.

Advanced filtering

Another feature valuable for developers is the enhancement of filters (advanced filters). The engineering team added several new types of filters such as numerical, string, and Boolean. With these filters, developers can have a set of operators for each data type and more fields available to run them on. Hence, developers will have more control over what events are routed where and can ensure only the necessary events are accessed by the compute services handling them.

Cloud Events

Azure Event Grid supports since June of this year CloudEvents – a new open specification and standard for consistently describing event data. It is an open standard created by the Serverless Working Group of the Cloud Native Compute Foundation (CNCF), who partner with many cloud services and cloud providers. Furthermore, Azure Event Grid currently supports the 0.1 version of CloudEvents including native support for events adhering to the CloudEvents JSON schema.

Assume a custom application sends windspeed events adhering to the Cloud Events schema. The events arrive at a custom Event Grid Topic containing a subscription by an event handler like Logic Apps. The subscription is on the Eventype (WindSpeedEvent), and dead-lettering and retry policies are enabled.

A custom application measuring wind speed sents the following event to the custom Event Grid Topic:

{

“CloudEventsVersion”: “0.1”,

“EventId”: “d98d73f0-34a3-49c1-a676-356e72dd166f”,

“Source”: “#CloudWindEvents”,

“EventType”: “WindSpeedEvent”,

“EventTypeVersion”: “”,

“EventTime”: “2018-12-05T14:22:16.4960093Z”,

“Data”: {

“WindSpeed”: 10,

“Type”: “WindDetails”,

“Location”: “Amsterdam”,

“Lat”: 52.373888888889,

“Lng”: 4.8894444444444

}

}

The event will arrive in the custom Event Topic and pushed to a subscriber, i.e. Logic App, which can handle the event accordingly to the logic in the action(s) that follows.

Management

The management of Event Grid has been improved since its GA date. Users can now enable retry policies, and dead lettering, observe matched, and unmatched events, latency, and errors on each subscription.

Conclusion

Throughout the last months since the GA of Event Grid, the service keeps evolving and more updates are in the works such as increasing the number of event sources and event handlers, further management improvements, and additional features.