Driven by Microsoft’s roots as a platform company, Azure’s focus on hosting microservices makes a lot of sense, providing developers to build software at scale well beyond that available on-premises.
At the heart of that focus are two key technologies:
- Azure’s implementation of Kubernetes
- Its related serverless computing implementation, Azure Functions
Both are important elements of building modern distributed systems—Kubernetes for hosting scalable business logic elements, and Azure Functions for basic data processing and hosting service endpoints. Azure Functions’ own evolution has added support for state and the option of permanent instances to avoid latency due to container replication and startups.
But they’re only part of Microsoft’s distributed computing platform. Other elements include Cosmos DB at the data layer, and Azure Service Fabric and Azure Event Grid at the input layer. Azure Service Fabric’s implementation of the actor/message design pattern is one way of handling events in a microservices framework, sourcing and syncing events at specific addresses, with each microservice registering the events in handles, and publishing an address to enable Azure Service Fabric to route messages appropriately.
Azure Event Grid provides serverless publish-and-subscribe
Back in the early 2000s, at the beginning of the switch to service-oriented architectures, we used messaging techniques to handle connections to service endpoints, with service buses to process and route messages. One common technique was the publish-and-subscribe model that’s now used by Azure Event Grid, with registered events delivering results to specific endpoints.
Recently out of beta, Azure Even Grid’s publish-and-subscribe turns out to work well as part of a serverless architecture, giving you both a way of triggering the launch of a serverless function and a way of marshalling event information with guaranteed delivery, even if no serverless application instances are currently running. Ensuring message delivery is an important element of any event-driven architecture, and by launching functions on demand, Event Grid lets applications either queue events to manage compute resources or prevent delays and launch as many handling functions as necessary to work with incoming data.
There’s always a trade-off between resource allocation and latency in scalable systems, and Event Grid manages to support both up to 24 hours of retry (with a simple back-off algorithm that increases the delay between tries) and more than millions of events per second. Pricing is per event, so you can size both your Event Grid implementation and your application to fit your budget.
Choosing event architectures in Azure Event Grid
Making Event Grid part of a mix of messaging services can simplify your code.
At heart it’s about reacting to changes in state somewhere in your application. The events it delivers don’t contain significant amounts of data, and often they are only a pointer to information held elsewhere in your application. Perhaps you’re using it to detect if there’s been an update to a catalog item in an online store; all you need to deliver to a function in your CMS is the location of the Azure Storage blob that contains the new content.
Azure’s other two messaging tools have different roles to play:
- Event hubs are for working with high-volume streaming data, such as to process telemetry from IoT devices, or for working with data sourced across a large organizational IT system.
- Service Bus is for high-value messages, where every message sent is critical to your business, such as handling orders in an e-commerce system or user actions in an online game.
That’s not to say they’re completely exclusionary; it’s easy to come up with scenarios where you might use all three—Event Grid, event hubs, and Service Bus—in the same application.
If you’ve decided to use Event Grid in your application, you need to choose between working with one of its many preconfigured service sources or building your own custom link. Endpoints don’t need to be functions—you can use your own code to subscribe to an Event Grid publisher—but it’s a lot easier to use Microsoft’s own tools, especially if you’re using Event Grid to work with messages from bursty sources, where the number of events sourced is highly variable.
Using Event Grid in your code
Event Grid sits between event publishers and event handlers, with events sourced from publishers and delivered to handlers. Although most of the publishers are sources you’re likely to use in your applications, two of them—Azure Subscriptions and Resource Groups—are more focused on managing your Azure services. By tying them to Azure Automation as a handler, you can respond to notifications from virtual infrastructure or from containers to automate deployment of additional resources. It also lets you link Azure to existing devops tools and platforms, using custom code or via webhooks.
Tools like this are also an important component of serverless architectures, because they provide the lightweight triggers needed to launch and run serverless code. Distributed computing is inherently asynchronous, so triggering Azure Functions from an Event Grid means you can build code that works with events that can occur at any time, and in any order. Once a function has triggered, it can either use its own code to handle the event message and deliver an appropriate output, or it can marshal the event data and deliver it to additional services for processing.
Going serverless with events
The Azure Portal handles much of the configuration needed to build an event grid. You can configure the event source and the method used to deliver the result, picking the supported event type and using the endpoint automatically generated when you use the tools built into the Azure Functions editor to add an Event Grid subscription.
For example, you could write a function that takes an uploaded image of an object and then uses Cognitive Services image-recognition APIs to determine whether it’s a specific plant or not. By using Event Grid to deliver a link to a storage blob containing an image as soon as a new image uploads, all your serverless code needs to do is pass that link to the Cognitive Services REST APIs, and then wait for a response, before delivering the answer to the appropriate endpoint. You don’t even need to wait, using another function to handle the response, triggered by a custom event.
By connecting events and APIs with events, you remove much of the complexity needed when writing your own code. All you need to do is build an appropriate UI that can upload an image and then poll an endpoint for a response.
The combination of events and serverless computing is a powerful one. By bringing the two together, Azure simplifies the process of writing distributed code—and perhaps also helps keeps costs to a minimum.