A Closer Look at Microsoft’s Azure Event Grid – InApps Technology 2022

During the last week of August, Microsoft launched a preview of Azure Event Grid, a service that has the potential to become the messaging foundation of the Microsoft cloud infrastructure.

Azure Event Grid helps Microsoft and its customers in multiple forms. Firstly, Azure didn’t have a direct competitor to Amazon Simple Notification Service (SNS). Second, the existing services such as Azure Queue and Service Bus are designed for different use cases. They predate the emerging paradigm of serverless computing. Microsoft utilized the opportunity to ship something better than SNS, and a messaging service designed for the contemporary microservices and serverless applications.

The cloud is increasingly becoming event-driven. When the average CPU utilization goes beyond 60 percent, an auto scale event is triggered to add new VMs to the scale set. When the health check fails for five consecutive times, the load balancer will raise an event and then stops sending the traffic to the VM. When a document is manipulated in Microsoft Cosmos DB, a change feed event is triggered. These sample events only represent a tiny subset of events that take place in the cloud. Almost every action initiated through the portal, API and CLI results in firing an event. If developers are exposed to these events along with the metadata, they gain fine-grain control over the lifecycle of resource lifecycle.

Azure Event Grid is designed to address this scenario, to enable developers to access events generated by the cloud infrastructure.

Apart from the cloud-generated events, Azure Event Grid can be exploited for custom events. It can act as a pipe to connect custom event sources and targets. For example, a developer can use Azure Event Grid to fire a custom event to notify that the shopping cart is checked out in an e-commerce portal. That event can be consumed by independent targets to process the event.

The ability to use Azure Event Grid as a generic eventing and messaging infrastructure opens up a new avenue for Azure developers targeting contemporary applications based on containers and microservices. It is extremely valuable in the context of serverless computing that’s squarely dependent on the event-driven execution.

Closer Look

On the face of it, Azure Event Grid looks a lot like Amazon SNS. But it is different in the way event consumers receive the messages. Both Azure Event Grid and SNS support multiple consumers associated with a topic. But unlike SNS that essentially dumps the message to every subscriber, Azure Event Grid consumers can subscribe to filtered topics. This mechanism ensures that only the events matching specific criteria are delivered to the target.

Azure Event Grid stands tall on the solid foundation laid by Azure Resource Groups. A few years ago, Microsoft Azure transitioned from traditional provisioning to a resource provider model. Each Azure service is exposed as a resource provider responsible for dealing with the provisioning and scheduling workflow. For example, VMs are tackled by a resource provider called Microsoft.Compute/virtualMachines while storage is handled by Microsoft.Storage/storageAccounts. Each resource provider is an autonomous service responsible for performing related operations specific to the requested resource.

The lifecycle of these resources, their association, and dependencies is orchestrated by Azure Resource Manager. A JSON file declaring the entire stack is submitted to Azure Resource Manager which treats the entire deployment as an atomic unit while provisioning the declared workload.

Azure Event Grid is a first class citizen supported by Azure Resource Manager. It can be included in the JSON template alongside other providers. But what’s more interesting about Azure Event Grid and Azure Resource Manager is the way Azure Event Grid becomes the channel for Azure Resource Manager delivering events raised by the resource providers.

The core eventing infrastructure is already built into Azure Resource Manager, which is now elegantly exposed via Azure Event Grid. What this actually means is that every resource provider becomes a publisher that fires various events during the lifecycle of a resource.

For example, Microsoft.Compute/virtualMachines can publish events each time a VM is created, stopped, run, and terminated. Developers can subscribe to these topics to get notified every time an event related to the VM lifecycle is published. As mentioned earlier, they can decide to filter the topics to only receive events that matter. For example, it is possible to subscribe only to the VM termination event instead of all the events published by the resource provider.

During the preview, Azure Event Grid is integrated with some of the key Microsoft services such as Azure Service Fabric, Azure Blob Storage, Resource Groups, and Event Hubs. The real power of Azure Event Grid lies in its ability to support almost every resource provider including those in the public cloud and the private cloud powered by Azure Stack.

One of the top use cases for Azure Event Grid is intra-service communication of containers running in Azure Container Service (ACS) and Azure Container Instances (ACI). Each microservice deployed as a container can publish to a topic consumed by multiple other containers. This represents the fan-out pattern of messaging. Similarly, multiple containers can publish to the same topic consumed by one container for further processing. This is known as the fan-in pattern in which multiple messages are aggregated at one endpoint.

Azure Functions and Azure Automation make ideal subscribers. An event can trigger a runbook defined in the Azure Automation environment. For custom tasks such as invoking third-party web services, developers can write and code snippets running in Azure Functions.

For operations that require additional configuration that may not be ideal to run within Azure Functions, we can invoke an Azure Container Instance. This instance can have access to both the code and configuration to perform complex workflow. Once the execution is done, the Azure Container Instance instance will be automatically shut down. This scenario takes advantage of the short-lived processes hosted within Azure Container Instance and the pay-per-execution billing model.

Microsoft has gone one step ahead and integrated Azure Event Grid with Azure Logic Apps, the designed environment to create serverless applications. This integration makes it possible to perform actions without writing any code.

The most powerful consumer of Azure Event Grid is a custom WebHook. An event can send the payload to the WebHook for custom processing. This integration enables developers to create complex workflows that go beyond the basics of event processing.

In one of the upcoming articles, I will walk you through the steps involved in creating a custom HTTP listener based on the WebHook infrastructure. The listener will run on your machine to create a backup of each blob uploaded to Azure Storage. This tutorial will give us an opportunity to dissect Azure Event Grid architecture and learn the barebones implementation of an event handler.

Since Blob Storage is not publicly available as a publisher, go ahead and register for the preview release.

Stay tuned for Azure Event Grid tutorials that I am planning to cover in this series.

Microsoft is a sponsor of InApps Technology.

Feature image via Pixabay.