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
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.
Some of the features of Azure Functions include:
- Flexible code authoring (in-browser, via continuous integration or directly from IDE such as Visual Studio)
- Pay-per-use (on a Consumption Plan)
- Multiple language support (for example, C#, F#, Python and so on)
- Simplified Azure integrations such as to Event Hubs, Blob Storage and so on
- External dependency support, for example, NuGet and NPM
The uses for Azure Functions are potentially many and varied, for example:
- Scheduled data processing/clean up/archiving
- Serverless Web app/SPA back-ends via HTTP
- Serverless mobile app back-ends
- Real-time/Internet of Things event processing
- Azure service event-based processing such as responding to new queue messages
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
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.