With Event Grid, Microsoft Provides the Missing Half of Azure Serverless Computing – InApps 2022

Microsoft is turning just about everything in Azure into events you can connect together with serverless code.

Serverless computing lets you focus on the app you’re coding rather than the infrastructure that it will run on; you write your app as functions triggered by events, so that you only pay to run your code when there are events for it to process, and the service takes care of scaling up to handle the events that trigger your code.

Handling those events can still mean caring about some infrastructure, like the message queues that you have to interact with. That’s where Microsoft’s new Azure Event Grid service comes in: it’s a fully managed event routing service that lets you subscribe — and react — to any event happening across other Azure services, as well as events from other services that you monitor via webhooks and REST APIs.

“We’re seeing many more modern apps being built around events, whether it’s reacting to changes coming from IoT devices whether it’s responding to user clicks on mobile applications or initiating business processes from customer requests,” Corey Sanders, Microsoft’s head of product for Azure Compute told InApps.

Events are becoming the same first-class, native object across the full range of Microsoft services.

“Serverless platforms, like Azure Functions and Azure Logic Apps, allow you to use on-demand event-based application models without any of the weight or baggage of the infrastructure. But as we see more customers deploy apps this way, we’re seeing increased challenges in other aspects of the application model — primarily in managing and responding to those events that are initiated across many different platforms,” Sanders said. “Events come from a plethora of sources and, until today, they’ve had to be managed with lots of additional code. Event Grid completes the story; it’s a single managed service for managing all events from any source, to any destination, that’s built to be highly available and handle massive scale dynamically. It’s the second half of what serverless applications really need — a reliable global eventing solution.”

Azure already has various ways to use events: in Functions and Logic Apps, in Power Apps for building custom business apps, in Azure Event Hubs for logging telemetry from apps and sites, in Azure IoT Hub for events from IoT assets and even in Cosmos DB with the new Change Feed processor. Event Grid gives you one central place to manage the routing of those events, using filters to route specific events to different endpoints (or even multicast to multiple endpoints).

It’s built on Azure Service Fabric, which powers key Microsoft services from SQL DB to Power BI, which means that events are becoming the same first-class, native object across the full range of Microsoft services, starting with Azure (and that the service can cope with events at very large scale). That makes it very different from other services that handle events but only do it through REST APIs and webhooks.

“These events are completely decoupled from the app platform,” explained Sanders. “Event Grid is more than just a standard pub-sub system because of the breadth of services covered by the platform, but also because events are first class which means you have direct control over them, including filtering around prefix or event type. you can control and configure a set of filters so that you can easily decide which events to listen and react to in your code. That filtering is done on the server side and that means the complexity of code you need to decide which events to react and respond to is dramatically reduced.”

Filtering by event type and prefix let you precisely isolate the events to respond to, even from a very large stream of events.

Events Go across Azure

The obvious use for Event Grid is to route between different Azure services; uploading an image file to Azure Storage could trigger an Azure function that resizes the image or runs image recognition on it. “Imagine a custom event being fired from an IoT-based solution and launching a function or a third-party eventing service,” Sanders suggested.

Event Grid is a perfect match for Azure Functions, but it doesn’t only work with serverless services. “The goal is that it becomes a central point for developers and system administrators to use for managing all their events, and from every service that’s running in Azure so customers don’t have to manage multiple services multiple sources, multiple different types of platforms and can enable all this in a single, simple way,” he explained.

“We have plans for the broad set of services to be integrated, including Cosmos DB, Azure AD, SQL DB, and Postgres and MySQL. We’ll offer direct IoT Hub and Event Hub integration with Event Grid to be able to take those messages, the storage and the managing of those messages and be able to convert them into these first-class eventing objects that then are routed properly to the service or scenario you want to execute.”

In the preview, you can collect events from Azure Resource Groups and Azure Subscriptions (for management operations), Event Hubs and your own custom topics that you create. Blob Storage and Azure Automation support is coming soon, and Azure Active Directory, API Management, Logic Apps, IoT Hub, Service Bus, Azure Data Lake Store and Cosmos DB will join the list “later this year.”

Initially, you can send the events to Azure Functions, Logic Apps (which covers Power Apps and Microsoft Dynamics, as well as third-party services like Salesforce), Azure Automation and webhooks to external services. Later on, you’ll be able to route events to Service Bus, Event Hubs, Azure Data Factory and Storage Queues.

You can also use Event Grid for operations and automation; when it launches the service will support Azure Automation from Azure Operations Management Suite. “You’ll be able to be able to take an event from any source and be able to run a script or response as part of that, and the alerting and monitoring systems will be integrated over time,” Sanders told us.

That means you can track how you’re using Azure services like VMs and SQL DB, to enforce policies or automate administration by putting metadata into operations tools or creating work items. “With a few lines of code, a virtual machine being created could result in a full app workflow that adds a billing tag and sends a notification that the VM has been created. That end-to-end capability is very powerful for managing control and access to the environment and in future, perhaps including Azure Active Directory changes in addition to the API changes.”

Event Grid in Action

Event Grid is designed for large scale. “We’re thinking in millions when comes to event-based management and communications,” he said. Microsoft has already tested millions of events per second in a single region, sustained for several days and that’s how the service is priced – at $0.60 per million operations ($0.30 during preview) with the first 100,000 operations per month free during the preview. Operations are defined as event ingress, advanced match, delivery attempt, and management calls.

There are other limits during preview: manage operations are throttled to 10 per second and you can have 1,000 event subscriptions per account. When the service launches, expect to see 10 million events per region and 100 million event listeners supported. “The goal is to really offer that fast transmission of events through the system,” Sanders explained.

If you’ve used Azure Logic Apps, the visual programming interface for defining events with triggers and actions will look familiar (although with the option to flip into code view to extracting details from your Azure subscription).

Event Grid has predefined common triggers or you can define your own.

Events have common information like the event source, the time it happened and a unique identifier, as well as specific information for the event. The metadata for a file saved into Azure Storage, or if the event is a VM reboot it will include the VM name and reason for rebooting.

The schema of what information is in each event comes from the event topic, and creating custom topics is how you define the endpoints that events are posted to. Event Grid topics are Azure resources and you create them in Azure resource groups. Subscribing to a topic is how you tell Event Grid which events you want to track; subscriptions are how Event Grid routes and filters events.

The event handler (which Event Grid calls a subscriber) is the final destination of the event and the actions to be taken to process it — which includes retrying for up to 24 hours, with an exponential backoff time, until the destination service confirms the event has been accepted.

Subscriptions are how Event Grid filters and routes events

The long list of actions for events builds on the many connectors Azure already has for serverless computing.

Event Grid might look like an extension of existing Azure event handling, and having a single, central point for handling all your events in Azure is certainly convenient; but the fact that it’s built on Service Fabric and thus plumbed deeply into the way Azure services are built makes it more significant than that. Microsoft is taking some of the core principles of event-driven, serverless computing and using them to interconnect disparate Azure services — and anything else you want to receive events from and send events to, giving you a simple but very scalable way to create serverless apps that span services and platforms.

Feature image via Pixabay.