Moving away from monolithic apps to microservices, containers and REST APIs means that communications and message queues within applications becomes even more important, but traditional polling and pub-sub approaches don’t scale well to handle that. Whether it’s IoT or automated operations or serverless functions, event-driven computing is becoming foundational, and the Azure Event Grid service was created to fill this gap for event communications, Corey Sanders, Microsoft’s head of product for Azure Compute told the New Stack.

“As apps get more complex, as they take on more components, as they span multiple clouds and span hybrid, the requirements to communicate between them have become increasingly important. The previous way of doing this with polling mechanisms and listeners and so on is incredibly cumbersome and costly, so clearly an event-based solution is the way to go,” Sanders said.

In the longer term, Event Grid might move beyond cloud and become the basis of Azure Stack event handling, especially as the Azure Functions is already available there. For example, many IoT systems need to work for remote and low-bandwidth locations, using edge computing. “The primary scenario we see for Azure Stack is that latency-sensitive edge scenario; it’s the fastest growing usage case we see today with the solutions that focused on compute and storage and so on,” Sanders said.

Publish and Push

Event Grid has been in preview since the middle of last year, offering the primary way to handle events on Azure and beyond; now it’s generally available, and in more regions (initially Europe and Asia with more regions coming soon), new enterprise features and more developer tools.

Azure Event Grid service integrations.

Events are delivered by push semantics, so apps don’t have to continuously poll to look for changes. Event Grids supports events from key Azure services like storage, resource groups, Azure subscriptions and resource groups: the GA release adds General Purpose Storage and Azure IoT Hub as event publishers, as well as Azure Container Registry. That means that Event Grid shows up as an option in

But events don’t have to come from Azure services; they can be anything from tweets to IoT device updates, cloud provisioning, storage blob creation, new users being added to an HR system or products on a manufacturing line.

Finnish industrial processing service provider Outotec has been using the preview of Event Grid to rearchitect its hybrid integration platform, Sanders explained. “They have a bunch of plants and processing locations and manufacturing lines and they’re using [Event Grid] to take this central funnel of events happening from all of those locations, to be able to react to them on a service in Azure. It creates this opportunity for them to go rethink how the service is built without having to deal that any of underlying infrastructure.”

In and Out of Azure

Event handlers subscribe to topics (the endpoint where publishers send events); handlers also use subscriptions to filter incoming events, by type or publish path. Fan-out subscribes multiple endpoints to the same event, so it can be consumed in different ways.

Now that the service has launched, delivery SLAs are what Sanders called ‘enterprise focused’; “four nines SLA and a 24 hour retry period for any event inside the grid.”

Setting up an event subscription in the Azure portal, with prefix and suffix filters.

The native Azure event handlers include serverless options like Azure Functions, Logic Apps and the “no-code” Microsoft Flow service, as well as Azure Automation; Event Hubs is a new handler since preview and webhooks handle sending events to custom code and third-party services beyond Azure. “It’s not restricted to Azure cloud,” Sanders pointed out. “The ability to come in and say ‘I’m going to run custom code and I’m going to run it anywhere I want and take advantage of Event Grid’ we were excited about, because we felt it opened up opportunities. It has been a very common scenario where customers come in and use one side of the Azure platform with Event Grid and use custom on the other side. Sometimes the input is custom and the output is Azure Functions; sometimes the input is Azure Storage and the output is some custom event handler — or another cloud service or an on-prem system. The handling and firing of the events are equivalent, whether it’s an internal or external source — it doesn’t matter; Event Grid treats them the same.”

Many Event Grid customers are building IoT systems. “The two big scenarios that we see are IoT and operational workflow. Customer usage has been very focused on Functions usage, very focused on serverless usage, to enable IT solutions, all the way out to operations and management of your infrastructure. Some of most common scenarios where customers are deploying serverless solutions, it’s appending to existing applications it’s adding richness to other applications, and Event Grid just makes that much easier.”

IoT systems tend to have a much higher volume of events, but many of the operational workloads running on Event Grid don’t go above the free tier of 100,000 monthly events. (The service handled an average of 300 million events a week during the preview.)

Writing custom code to use Event Grid is also getting simpler. There are new management and data plane SDKs for Python, Nodejs, Go and Ruby as well as the existing C#/.NET support, with more languages coming later in 2018.

“As we see more customers come in and look to build out more complex solutions using Event Grid they need to be able to do it in a programmatic way,” Sanders told us. “The portal experience makes it very easy but when you’re doing it at a larger scale, say with a CI/CD pipeline or doing it as part an overall application rollout, being able to do programmatically is important and delivering whatever languages people want has been an on-going goal.”

It’s also easier to consume events; instead of needing the event subscriber to deserialize events, it can fetch the JSON schema for all supported event types from the event schema store.