Azure Functions were introduced during Microsoft Build 2016 as a means to provide a serverless computing environment that could scale as needed and provide a pay-as-you-go service. Serverless computing is a means of providing computing power and resources for solutions without the need to be concerned about the underlying infrastructure.
They provide a mechanism that allows developers and solution architects to react to events and process usually small amounts of functionality before either passing back a response or creating another event.
Given this, Azure Functions provide a mechanism to deliver a truly event-driven architecture, including the ability to chain and fan out events to multiple sources.
In the previous chapters, we have spoken about how Logic Apps and the App Service model within Microsoft Azure provide a good basis to build solutions that follow microservices architectural principles.
One of the key requirements for a microservices architecture is that each service should have responsibility for its own work and data. This leads to added complexity when data needs to be shared or updated across different services because it is essential to maintain this single responsibility principle.
One solution to the problem is to use an event-driven architecture and principles around eventual consistency to provide a highly decoupled and highly scalable solution architecture (https://www.nginx.com/blog/event-driven-data-management-microservices/).
Azure Functions provide this event-driven solution, but they can be used across a range of other workloads.
In this chapter, we will discuss these workloads, provide an overview of Azure Functions, and pay particular attention on how they can be used from within Logic Apps.
We will continue to build out our Sunny Electricals solution and use an Azure Function to provide some basic checking of data as it flows through.
Azure Functions are essentially a managed service for WebJobs SDK that provide similar functionality but in a fully serverless environment.
WebJobs provide a means to run background tasks in the context of a Web App, Mobile App, or API App. With them, you can upload a script such as PowerShell or a command file and have them run on a schedule (https://azure.microsoft.com/en-us/documentation/articles/websites-webjobs-resources/).
At the very basic level, Azure Functions can be thought to be defined by:
Events + Code + Data = Function App
The key part of a Function App is the initial trigger that starts the process of running the code contained within a function. This trigger can be in the form of an input event, such as a message being written to a queue, or a timed event. A function can have a number of outputs that send data and information to a range of endpoints.
A Function App represents a unit of computing, and it can contain a number of functions, each of which can be triggered separately by different trigger mechanisms with different outputs and can be written in any of the supported languages. This allows functions to be grouped together; care needs to be taken to ensure that the memory of the Function App is not exhausted.
Function Apps are part of App Services that we have discussed in detail in previous chapters, and they sit in the same model as Web Apps, API Apps, Mobile Apps, and Logic Apps.
An App Service can be scaled as necessary, either up to a larger virtual machine size or out to a greater number of virtual machines, either manually or automatically, or an App Service Environment can be used that provides isolated computing resources that can also run within a virtual network.
Azure Functions can be hosted and executed in an App Service Plan that already exists, a new App Service, a fully isolated App Service Environment, or they can be hosted in a Consumption Service Plan and executed purely on demand and charged based on consumption. This pay-as-you-go execution model makes Azure Functions an attractive solution when there is a need for large-scale deployment because you are only required to pay when the code is triggered and executed.
The concept of a Consumption Service Plan was introduced with Azure Functions, and it has since been extended to include Logic Apps, which also support a consumption-based model.
When using a Consumption Service Plan, it is important to understand how functions scale. The unit of scale is the Function App and not the individual functions within it. When creating a Function App, which is described later, 1.5 GB of memory is allocated to it. This memory is provided to the Function App and not the functions within it.
The function runtime is single-threaded, so in the instance of event triggers arriving more quickly than a function can process them, multiple instances of the function may be invoked in parallel.
The Functions runtime is open source and available on GitHub (https://github.com/azure/azure-webjobs-sdk-script).
In order for a function within a Function App to execute, an event trigger needs to occur. A function can be triggered by a number of bindings, and triggers can either provide input as required for the function or as a result of event an input can be read as appropriate.
The following table provides a list of supported triggers and bindings. Bindings can provide input to the function and output that can be used by other services, including other Azure Functions. In this latter case, it is possible to create a chain of events that can effectively fan out and scale as necessary.
|
Type |
Service |
Trigger |
Input |
Output |
|---|---|---|---|---|
|
Schedule |
Azure Functions |
Yes | ||
|
HTTP (REST or WebHook) |
Azure Functions |
Yes |
Yes | |
|
Blob Storage |
Azure Storage |
Yes |
Yes |
Yes |
|
Events |
Azure Event Hubs |
Yes |
Yes | |
|
Queues |
Azure Storage |
Yes |
Yes | |
|
Queues and topics |
Azure Service Bus |
Yes |
Yes | |
|
Tables |
Azure Storage |
Yes |
Yes | |
|
Tables |
Azure Mobile Apps |
Yes |
Yes | |
|
No-SQL DB |
Azure DocumentDB |
Yes |
Yes | |
|
Push Notifications |
Azure Notification Hubs |
Yes | ||
|
Twilio SMS Text |
Twilio |
Yes |
Note
- WebHooks (https://en.wikipedia.org/wiki/Webhook)
- Push Notifications (https://azure.microsoft.com/en-us/documentation/services/notification-hubs/)
It can be seen from the table that some bindings can be used to only provide input to a function rather than as a trigger.
In the case of HTTP, the output can only be provided when the input is also HTTP, which provides a mechanism to provide the Function as a REST endpoint or WebHook that can be called by another function. We will use this later in the chapter to provide the processing of information as part of a Logic App.
Another binding of particular interest is the schedule; this allows a Function to be executed on a specific timed schedule with that schedule based on a Cron expression.
Azure Functions have been created to provide the broadest level of support for both modern and more traditional programming languages and scripts.
Along with support for multiple bindings and triggers, Azure Functions also supports a range of common programming languages to allow developers to easily and comfortably create functions using existing knowledge.
At the time of writing, the following languages are supported:
- First class support: C# and JavaScript
- Experimental support: Batch, Bash, F#, PHP, PowerShell, and Python
When creating a template, choices can be limited by choosing from a list of specific types:
- Core
- API and WebHooks
- Data processing
- Samples
- Experimental
The process for creating a function within a Function App is described in the next section