Leveraging Functions on the Azure Platform

This blog will go into the capabilities of Azure Functions and discuss what they are, how to develop, test, monitor, and deploy them.

A little history

Amazon was the first cloud provider introducing a serverless computing service or what’s called a function – AWS Lambda. This service from Amazon lets you run code without provisioning or managing servers – hence it’s labeled as a serverless compute service. With Lambda you only upload your code and AWS will take care of everything required to run and scale your code with high availability.

When Amazon released this capability on AWS – other cloud providers soon followed. Microsoft launched Azure Functions early 2016 as a preview, and it became generally available mid-November of 2016. You can build and run functions on the Azure Platform without worrying about managing any infrastructure, scalability, or availability, similar to what AWS Lambda offers, and what other cloud vendors like Google Cloud, or the new Oracle Fn platform offer.

Azure Functions are part of the Azure Web + Mobile suite of App Services and are designed to enable the creation of small pieces of meaningful, reusable methods, easily shared across services. These serverless, event-driven methods are often referred to as “nano-services” due to their small size. Although an Azure Function can contain quite a bit of code, they are typically designed to serve a single purpose and respond to events in connected services.

Languages

You can build the Azure Function in various languages like Node.js, C#, F#, Python, PHP, and even Java. Followed by scripting languages, Bash, and PowerShell – and support for Command Line through CMD- or BAT file.

Common Scenarios

Azure Functions are “event-driven” meaning they run based on associated and configured events, or “triggers” (see also triggers and bindings later in this post). For example, an Azure Function could be triggered by a simple timer, such as running a process once every 24-hours or triggered by an event in a document management system, such as when a new document is uploaded to a SharePoint library. Azure Functions can also respond to Azure-specific events, such as an image added to a Storage Blob or a notification arriving in a Message Queue.

Common scenarios for Azure Functions are:

• Timer-based processing
• Azure service event processing
• SaaS event processing
• Serverless web application architectures
• Serverless mobile backends
• Real-time stream processing
• Real-time bot messaging

Introduction to Azure Functions

The WebJobs SDK runtime, a framework that simplifies the task of writing background processing code that runs in Microsoft Azure, is the foundation of Azure Functions. Furthermore, Functions leverage a declarative binding and trigger mechanism, which works with several Azure services like Storage, Cosmos DB, and the Service Bus.

The diagram below outlines the Azure Functions building blocks.

Anatomy of a function

An Azure Function is a group of a few files that work in harmony. All actual function logic resides in a “Run” file written in a language of choice. A “Project” file is similar to a project file in other technologies such as .NET Core or Universal Windows Platform and contains “secondary” assembly references such as NuGet packages. Finally, a “Function” file contains information about triggers and parameters, such as locations of Storage Queue connection strings and whether the parameter is designed as an “in”, “out” or “bi-directional” (see also Code concepts). Optionally, additional configuration is also found in the Function App Settings such as an API Key or database connection string.

Azure Function Hosting

The hosting environment for Azure Functions is the App Service (Dynamic) Runtime. A runtime managed by Microsoft, which scales automatically in case of the consumption plan. Furthermore, the runtime abstracts away the underlying infrastructure and the bindings discussed in the previous paragraph. The App Service offers a dedicated tier – App Service plan tiers, Basic, Standard, Premium and a dynamic tier (Consumption plan).

Functions run either in a consumption- or app service plan. The consumption plan means that it will automatically allocate compute power when your code is running, scales out as necessary to handle the load, and then scales down when the code is not running. Furthermore, you only pay for what you use. However, when you need more computing power than the consumption offers then you need to choose the app service plan and allocate compute power yourself.  For more information, see scaling and hosting.

Triggers and Bindings

With the bindings in Azure Functions, you can quickly write code that reads or writes messages to the Service Bus, or read or writes into Blob Storage. Triggers automatically invoke the code in a function. For instance, whenever a message in a Service Bus arrives.  Bindings in Azure Functions provide a way to connect to data with code declaratively – you define them by specifying a connection string and other properties depending on the binding you choose. Furthermore, you can extend the bindings by leveraging the extensions available in the WebJob SDK.

The following table shows the triggers and bindings that supported by Azure Functions.

Note that all triggers except schedule have, as previously mentioned, data associated with them and the HTTP output binding requires an HTTP trigger.

Code concepts

The code in an Azure Function executes by a trigger raised by, for instance, an HTTP request or event occurring in one of the Azure Services like a message written to a Service Bus queue. Moreover, the trigger is the starting point or an invocation of logic (code) to execute. The input and outputs are configured through the bindings Azure Functions supports such as HTTP, Storage, Schedule, Cosmos DB, and Azure Service Bus.

The picture above shows a function triggered by a timer trigger, having an input document, and multiple outputs. The input and output are defined by bindings, and the function will be executed based on a timer set by a schedule. Furthermore, the code itself operates on each document from the inputDocument, i.e. a collection of documents. In the Azure Portal under the integrate tab you can configure the triggers and bindings.

Developing Azure Functions

You can create an Azure Function through the Azure Portal, i.e. in a browser or using an IDE like Visual Studio, Visual Studio Code, or Eclipse. Moreover, with an IDE you can debug the code and leverage IntelliSense, while these capabilities are not supported in the browser.

Build an Azure Function using the Visual Studio 2017

We recommend building a function with Visual Studio (Code or Eclipse) as you will have the ability to debug and leverage IntelliSense. Furthermore, you can use Visual Studio online (VSTS) as a repository for your code and deploy quickly to Azure. With Visual Studio 2017 version 15.4 and up including the Azure development workload, you have access to the Azure Functions template. You can create a project in Visual Studio and choose within Visual C# –  Cloud Node the Azure Functions Template, specify a name for your project and you are then ready to develop. Note that when selecting the Function template in Visual Studio you can create a V1 (.NET Framework) or V2 (.NET Core) function.

Sample Function

Let’s consider the following function, which can be triggered when a blob is created in Azure Storage container.

The function above can be run locally for the test and debug.

Testing an Azure Function

You can run a function locally and test its behaviour. You can start the function, and the core tools will aid in the testing.

Integration with VSTS

Once you feel comfortable with your function, you can sync it with a VSTS repository (VSTS Git). Furthermore, with your function code in VSTS, you leverage the build and release capabilities. You can create a build definition, by doing the following:

• From the Build Definitions view in VSTS, select +New.
• Choose the template NET Core (.NET Framework). Even though we’re not deploying an ASP.NET Core app, this template has the correctly configured tasks for a Functions project.
• Add a build task for Azure App Service Deploy.
• Ensure you use a VS2017 build agent
• Choose an Azure subscription and select your Function App under App Service name.
• Modify the Package or folder setting to use $(build.artifactstagingdirectory)/**/*.zip
• Save and queue the build.

You can find a sample (animated gif) of the build definition through the following link. Note that you’ll need to provision a Function App first before you can release the function through a build definition.

Azure Functions Monitoring

You can do Azure Functions Monitoring by leveraging the Application Insights service on the Azure Platform in combination with Turbo360. Both services can provide value in getting insights into your Azure Function as they are complementary to each other.

Application Insights

Application Insights is an Azure Service that can give insights in application performance, provide instant analysis, apply machine learning on the telemetry and diagnostics. Moreover, this service can quickly be hooked up an Azure Function App. You create an instance of Application Insights, obtain the instrumentation key and set in the application settings.

Note that when deploying a function to a FunctionApp the Application Insights is enabled and you do not have to do anything.

Once this setting has been saved the Function App automatically will send information to Application Insights, without any code changes. If you open Application Insights instance and click “Live Metrics” you will see a near-live view of what’s coming from your Function App.

Turbo360

With Turbo360 you can monitor your Function App containing your functions, look at each function individually and its properties (like bindings).

Furthermore, you can look at the invocations of each function and set, for instance, an alarm when your FunctionApp or function is not healthy, i.e. not running.

The benefit of Turbo360 is that you can quickly see if a function is healthy, look into individual invocations of functions, and you are able to set alarms to notify people when the Azure Function App or function is not running.

These simple matters are quite challenging to achieve with Azure, i.e., you need to understand the Function App service, Kudu dashboard, and Application Insights. For the first tier support staff that need to monitor cloud-native integration services, Turbo360 is the right tool.

Integration with other Azure Services

Functions are integrated with Application Insights, Logic Apps, and Event Grid. With integration is meant that you can monitor Azure Functions with Application Insights, call a Function from a Logic App, or have a Function handle and Event from Event Grid. See the following documentation for integration with Logic Apps and Event Grid:

• Create a function that integrates with Azure Logic Apps
• Event Grid trigger for Azure Functions

Wrap Up

In this blog post we have discussed what Azure Functions are, how you develop them using Visual Studio, test them locally, monitor them leveraging Application Insights and Serverless, and how to deploy them through VSTS build template. Functions provide a way to execute code in Azure without managing any infrastructure, you focus on logic, and later keep them in check with Application Insights and Turbo360.

Also, read Steef Jan-Wiggers blog on:

How To Build A Reactive Solution With Azure Event Grid

Messaging Options In The Microsoft Azure Platform