Phidiax Tech Blog

This blog is a continuation of the series started in Part 1 on Microsoft Azure Event Grid, which focused on the overall event framework offering in Azure. In this article I want to get into detail on the concept of a Serverless event-based framework and how it ties into Azure offerings.

Serverless

Serverless computing in general is a cloud computing model where the cloud provider dynamically manages the allocation of infrastructure to support the application. The pricing is based upon sub-second utilization in Azure, and is based upon the actual amount of resources consumed by the application as opposed to pre-allocating purchased infrastructure units and allowing them to sit dormant. In an Azure Functions video, which I watched, it was shared that 75% of customers see a price advantage from dynamic resource allocation, or “serverless” computing.

One of the key tenets of serverless computing is that everything is driven by events and it completely fits hand in hand with the event-driven programming and architecture concepts introduced in my first blog post. In many ways this represents the next logical step in cloud computing – along the chain from IaaS, to PaaS, to Serverless. 

Microsoft’s main serverless component offerings are Azure Functions and Logic Apps. These tie in to the Azure Event Grid as consumers of events in the overall model. But before we can get to the Event Consumers, let’s examine the source of the Events – the Event Publishers, and look at the different types of information they offer.

Event Types

Fig 1 – Event Publishers – from Azure event grid overview

In examining the publishers for the Azure event framework, the events seem to divide themselves into a couple of different “types,” those related to Infrastructure, and those related to Applications. A good breakdown of the overall events and what they look like can be found in this Azure Event Grid event schema article.

Infrastructure Events

Events triggered by Event Publishers in Azure Subscriptions or Resource Groups are triggered by changes to cloud infrastructure.  These events are highly helpful in security related scenarios. For both Azure subscriptions and Resource Groups, events can be raised when resources are written or deleted, helping to secure subscriptions, either in their entirety or specific resource groups within the subscription.

The tutorial Monitor virtual machine changes with Azure Event Grid and Logic Apps is a great place to start with walking through the steps of setting up an Azure Event Grid subscription that monitors write changes to a virtual machine, then uses a Logic App workflow to send an email message alert through a Gmail connector. This gives a flavor for how to handle the subscription or the resource group types of events. 

Application Events

Events triggered by Azure Event Publishers in Event Hubs, Blob Storage, and Custom events are events that are triggered by more application level or microservice types of applications. Event Hubs offers a useful event raised called “CaptureFileCreated” that fires when the Event Hub stores its data payload in temporary blob storage. Outside of Event Hubs, the Blob Storage offers events raised when blobs are created or deleted. Custom events can be defined by the user and can contain a data payload of any well formatted JSON object. All three of these scenarios more completely line up with event-driven programming and application development than they fall into infrastructure buckets. 

The tutorial Automate resizing uploaded images using Event Grid is a great place to start with Application Events, where you can build a very useful image thumbnail generator through the Azure Blob storage create event as well as routing it through Azure Functions.

After some familiarization with the different types of events that are available, and some experience with the format that events take in both of those tutorials, in the next article we will get into some detail on building parts of a Serverless Application using Event Hubs. See Microsoft Azure Event Grid (Part 3).