Azure Event Grid is a messaging service built to enable event-based architectures to be built more easily. At the basic level it’s similar to a message queue service, like Azure Service Bus Topics, that enables a publish / subscribe model. However, the similarity really ends there. Azure Event Grid is a different kind of messaging service that’s built to enable event-based architectures like those use with Microservices architectures to be built more easily.

Topics and Subscriptions

If you’re familiar with Azure Service Bus Topics (a message queue service in Azure that uses a publish / subscribe model) you may think you already know how Azure Event Grid works. In that case, you would be wrong. Well, mostly any way, as there are some similarities between the two services, but they are still vastly different.

At the basic level, similarly to Azure Service Bus, a Topic is an endpoint that receives messages, and a Subscription is used to receive messages through the Topic that will be handled by a message listener. These concepts are basically the same, but there are some differences in how they work.

Within your Azure Subscription, you provision an Event Grid Topic which is the endpoint that will receive Events. In Event Grid, they are called Events, not Messages since it’s a event-based messaging system. From there, you setup Subscriptions on the Topic that will receive Events. These Subscriptions are setup as an Endpoint using WebHooks or other Azure Services that will receive the Events sent to the Topic.

This all sounds fairly simplistic, and it really is a nice addition to the capabilities of Microsoft Azure to help build event-based architectures. This lends itself nicely to microservices architectures using serverless computing options like Azure Functions and Logic Apps in addition to other methods of implementation.

There are also more differences between Azure Event Grid and other message queue services. The capabilities of Azure Event Grid are centered around speed, scale, breadth, and low cost. Rather than being a general / generic messaging service, Azure Event Grid is built specifically for Serverless architectures.

Azure Event Grid is built specifically for Serverless architectures.

Primary Event Grid Terms

To fully understand what Azure Event Grid is, you need to understand a few terms used. These terms represent the different components and capabilities of the service.

Event

The Event is essentially a message that contains the data sent to the service that represents a single event that occurred. Rather than a general / generic message, an Event in Event Grid is very specific to describe something that happened. For example, an Event could represent a new file being saved in Azure Blob Storage and will contain information about the file (not the file itself), such as the modified or created date/time stamp for the file.

The specialized message that is an Event contains information around the event like the following: source of the event, timestamp event occurred, unique id for the event.

Event Publisher

The Event Publisher is the source of Events that is publishing Events to Azure Event Grid. Some examples of Event Publishers that can be integrated are:

• Azure Blob Storage
• Azure Event Hubs
• Custom Topics

There are also Event Publishers within Azure that can publish Azure Resource Manager management operations performed against Azure Resources. These would publish events around provisioning and configuration management events  from the Azure platform itself. Here’s some examples these management operation events could come from:

• Resource Groups
• Azure Subscriptions

Topic

The Topic is the endpoint that the publishers send events to. The Event Publishers will categorize events into Topics that they sent the Events to.

Event Subscriptions

An Event Subscription will receive specific Events sent to the Topic. The Events sent to the Event Subscription are then sent to subscribers or Event Handlers.

Event Handlers

The Event Handlers is the receiver of Events from the Event Subscription it’s subscribing to. These handlers can be setup as any service that uses WebHooks, or using the Azure services that have built-in support for being configured as Event Handlers.

Here are some examples of services that can be used as Event Handlers:

• Azure Functions
• Logic Apps
• Azure Automation
• WebHooks

Event Grid Architectures

Azure Event Grid is designed to use for implementing microservices, event-based architectures. Event Grid can be used to connect Event Publishers to Event Handlers in a similar fashion to any other message queue service. However, with Azure Event Grid specifically designed for event-based architectures, it has some features that are tailored specifically for currying Events from Publishers to Handlers.

One architecture pattern that is an immediately obvious fit for Azure Event Grid is a Serverless, event-based architecture. This is really the primary usage scenario the service is built for. The Event Grid could be wired up to instantly trigger an Azure Function or Logic App to execute on an Event to perform some kind of background processing and/or enterprise integration operations.

There are also a couple more usage scenarios that fit well with Azure Event Grid, such as Ops Automation and Application Integration scenarios. Pretty much any architecture that uses Events to trigger some kind of automation or alerts can be built out using Azure Event Grid easier than using other more generic message queue services.

Azure Event Grid is basically a further evolution of the message queue services in the cloud, just as Azure Functions and Serverless are evolutions of traditional PaaS (Platform as a Service) cloud services. The Cloud, and Microsoft Azure, are currently at a time of cloud evolution that is starting to capitalize on the maximum capabilities of the Cloud. Cosmos DB is another service in this “PaaS to the Max” space as well.

Attribution: This articles uses some graphics from the official Azure Event Grid documentation, such as diagrams.

About the Author

Chris Pietschmann

Chris Pietschmann is a Microsoft MVP, HashiCorp Ambassador, and Microsoft Certified Trainer (MCT) with 20+ years of experience designing and building Cloud & Enterprise systems. He has worked with companies of all sizes from startups to large enterprises. He has a passion for technology and sharing what he learns with others to help enable them to learn faster and be more productive.