Introducing: Serverless C# with Azure Functions

Azure Functions get you beyond the traditional client/server approach to app creation, right into the cloud. Let’s first look at triggers.

By Jason Roberts

04/12/2017

Azure Functions is another evolution of Platform as a Service (PaaS), where small discreet pieces of software execute in the cloud. These small pieces of software, called functions, address a specific need for an individual problem.

Even though functions are small and self-contained (high-functional cohesion), they can be composed so that they form part of a greater system. Azure Functions is one implementation of Serverless Architecture also known as Functions as a Service (FaaS). Azure Functions can also be a delivery mechanism for microservices.

With Azure Functions there are no virtual machines (VMs) to manage. Instead, a number of discrete functions live inside a Function app. As with other Azure services, multiple instances of function apps can be created -- for example, for different systems/applications.

Because there are no servers to manually manage, Azure Functions can automatically scale (typically using a Consumption Plan) to process varying levels of workloads. In terms of pricing/costs, Azure Functions can run in the existing App Service Plan model where functions run on dedicated VMs, or they can run in a Consumption Plan. With a Consumption Plan, costs are incurred only when compute resources are actually used and the cost is measured in gigabyte-seconds, which is based on memory size and total execution time for all functions in a given Function App.

Function Triggers
An individual function can begin execution based on some kind of event. To respond to events, a function has a "trigger." There are a number of types of triggers provided. The simplest is the manual trigger. As its name implies this is a function that can be executed on an ad-hoc basis, whenever it’s required, by clicking a button in the Azure Portal Functions editor environment, as shown in Figure 1.

There are also a host of other triggers available:

Blob Trigger

Event Hub Trigger

Azure Storage Queue Trigger

Service Bus Queue Message Trigger

Service Bus Queue Topic Trigger

HTTP Trigger

Timer Trigger

Generic Webhook Trigger

GitHub Webhook Trigger

Function Integrations
In addition to data provided as part of the function trigger (such as the content of the blob that triggered a function), individual functions can retrieve input and generate output to a range of third-party and Azure services, such as:

Azure Blob, Queue, and Table Storage

Azure Event Hubs

Azure DocumentDB

Azure Mobile Table Record

Azure Service Bus

Bot Framework

For example, a queue-triggered function can be used to retrieve the name of a blob as a queue message, load the blob as a function input, and write an entry to Table Storage as an output. The output from one function can also be used to trigger another function to create pipelines of processing.

To learn more about Azure Functions, check out the documentation here and the series of articles on my blog here.

Featured

This week saw two third-party vendors of dev tools -- UX and UI toolkits and controls -- release new offerings that include support for two of Microsoft's main open source frameworks, the cross-platform .NET Core 3.1 and Blazor, which allows for creating browser-based web applications with C# instead of JavaScript.

Clustering non-numeric -- or categorial -- data is surprisingly difficult, but it's explained here by resident data scientist Dr. James McCaffrey of Microsoft Research, who provides all the code you need for a complete system using an algorithm based on a metric called category utility (CU), a measure how much information you gain by clustering.