Building serverless (event-based) architectures using Azure Event Grid
When you look at a software systems and what it is what they actually do it is all about events. A lot of programming has been done through the years to emit, transport and handle events. Although event-based asynchronous software design is slowly becoming the norm there is still room for improvement and simplification in the way we can tell a system what to do when whatever happens.
Azure Event Grid is a new service in Microsoft Azure that focusses on event routing and integration with either Azure services like Functions and Logic Apps as well as 3rd party Publishers and Handlers.
The main concepts in Event Grid are: Sources, Events, Topics, Subscriptions and Handlers. These are brought together using a simple point and click approach with advanced routing options. It is a cloud service that offers reliability, high-throughput (think millions of events per second), fan-out and elaborate filtering.
As it fits the category of Serverless offerings in the cloud you are only billed for actual usage at $0.60 per million operations (50% off during preview). An operation can be the ingress, complex matching, and a delivery (attempt) of an event. The first 100k operations are free of charge.
So how does Event Grid compare to other integration offerings? First of all it is complementary to existing integration services in Azure by acting as the glue that brings multiple parts of an architecture or topology together. It is an eventing backplane that simplifies the practice of reactive programming.
Initially there is deep integration with Azure services out-of-the-box like Blob storage (announced) and Event Hubs but custom publishers and handlers are supported and open up a lot of opportunities. For internal automation in an Azure subscription and its underlying Resource Groups can act as event publishers for management operations.
Let’s take a look at an example of how to setup a custom publisher and handlers using the Azure CLI (version 2.0.14 or later). The Azure Portal has these features in preview as well.
First we create a resource group, an Event Grid topic and a subscription that links incoming events to an external URL (API). I’m using requestb.in to generate a temporary test API that can be monitored from your browser.
az group create --name vjeventgrid --location westus2
az eventgrid topic create --name vjproductrequesttopic -l westus2 -g vjeventgrid
az eventgrid topic event-subscription create --name vjproducteventssub --endpoint https://requestb.in/11mxq7v1?inspect -g vjeventgrid --topic-name vjproductrequesttopic
Next we collect the access key (the primary, indexed as 1) and URL of the provisioned endpoint to which we can start sending messages (the publisher in the context of Event Grid).
az eventgrid topic show --name vjproductrequesttopic -g vjeventgrid --query "endpoint"
az eventgrid topic key list --name vjproductrequesttopic -g vjeventgrid --query "key1"
Now we can use a HTTP request tool to trigger an event. We have to add a header called aeg-sas-key with the value we got from the key1 query. The body of the POST request has to be in this format (ISO8601 date format for the eventTime):
Using postman I got the following results calling the Service Grid ‘trigger’ endpoint:
This is the most basic example imaginable but things get more interesting when you take into account the integration with Azure where any event coming in to Azure EventHub, every file drop in Blob storage, any changes in role assignments within a subscription and many more of the extension points that will follow in this brand new service there is a lot of potential.
Where things get really powerful is when you combine this with Azure Functions and Azure Logic Apps to augment the routing Service Grid handles with code or proces designs that react on these events. As shown in this video.
Service Grid shows us that Serverless is a big thing in Azure and that there is a lot coming to make it even bigger.