Microsoft’s Event Grid is an important addition to Microsoft’s serverless options, providing the back end needed to build distributed applications that can work at scale, with minimal management and orchestration. It brings to Microsoft’s serverless tools an event routing fabric that simplifies subscribing to events raised by other Azure services and by external sources.
There’s a lot to be said for using serverless computing models as the basis of a modern cloud application architecture. For one thing, there’s no need to worry about the underlying infrastructure, or even the network you’re using, reducing the management load on your application orchestration tools. But serverless models, like Microsoft’s Azure Functions, are themselves limited, launching on demand in response to events. If they don’t receive the appropriate signals, they don’t fire.
Working with Azure events
So how should you capture events? Traditional event queues are an issue in distributed architectures, because it can be hard to ensure that events are delivered correctly. Ideally, you want messages to be idempotent, delivered once and once only, with that delivery guaranteed. In practice, that’s a hard problem to solve, so you’re more likely to use a system that delivers a message at least once; that way, you can use back-end code to clean up logs and stored data, using event and message IDs to identify duplicates.
With Event Grid, Microsoft has done the hard work of building a publish-and-subscribe system for you, integrating it with notifications from various Azure services. Events are now a first-class object, and your Event Grid configuration can filter and direct events to appropriate services. It’s also scalable, so it can handle simple architectures with one or two sources as well as complex environments with thousands.
At its simplest, Event Grid is a tool for routing event notifications from sources in Azure to Azure Functions. It turns your Azure environment into a notification fabric. Unlike traditional service buses, there’s no traditional workflow model here: An event happens, it launches an appropriate function, and your application is triggered.
Using Event Grid in your applications
Initially, Event Grid supports only a subset of the possible Azure services, including notifications from infrastructure services like Event Hubs and from your Azure subscriptions. Where things get interesting is how you can use Event Grid and Azure functions to tie together various services. One example Microsoft gives is using an event from a blob storage container to trigger an Azure function that runs a machine learning-powered image-recognition service every time a picture is uploaded.
What’s perhaps most interesting about this example is that it ties together actions that are otherwise uncoupled. There’s no need to have a monolithic application; all you need is an upload service and an image-analysis function. The linkage comes from your Azure storage account, with an event delivered to Event Grid when an image is uploaded into the specified blob container. A filter in Event Grid takes that specific message and passes it as an input to a function, giving it a link to the recently uploaded file.
There’s a lot to like here, especially when you consider it as part of a trend in Azure of tools to build near-autonomous platform-as-a-service applications. By using Event Grid with Azure Functions, you no longer need to manage the number of event handlers to service your serverless code. Instead, functions are launched as soon as the event they need has been raised, and they’re thrown away once that event has been handled. Why write event-handling and routing code, when the platform gives it to you for a very low cost?
Also, existing Azure services, like Logic Apps, use a lot of compute resources polling for events. But with Event Grid that’s no longer an issue. As services migrate to using Event Grid, they should become more efficient. Reduced compute requirements from Azure should result in lower costs for you and for your applications.
Fitting Event Grid into the new serverless, containerized Azure
Microsoft’s serverless model goes beyond Azure, thanks to Logic Apps and Flow, so using Event Grid to trigger Flow actions to feed from, say, an e-commerce application into Dynamics 365 could let you update customer records on the fly, or quickly target offers to specific customers. Then there’s the option of using Event Hubs in Azure’s IoT platform to push events from IoT devices, quickly raising alerts and using a function to pull data from a device as and when its actually needed, saving bandwidth and avoiding complex IoT hub architectures that may not be supported by low-cost, simple hardware.
With Azure Functions at the heart of Microsoft’s serverless model, you can easily imagine an application that uses Event Grid to source data from key Azure services, triggering a function that then uses the Azure Container Instances API to launch containers running more complex services to process data that’s linked to the underlying event trigger, with Kubernetes reclaiming the container resources when they’re no longer needed. With this type of architecture, you avoid an expensive permanent virtual infrastructure, and you’re billed only when your services run.
Perhaps we should start thinking about infrastructureless applications rather than serverless ones.