Technical Basis of Azure Functions

So, we successfully created an Azure Function, ran it on a local environment, and deployed it to the cloud.

Azure Functions run on servers that have Azure WebJobs installed on them. Azure WebJobs allow DLLs, or any supported code, to be hot-swapped in and take advantage of deep Azure integrations.

We'll cover the two runtimes in more depth now, but the key takeaway is that there is a fully-supported, Windows-based version, and also a beta cross-platform version. Microsoft are pushing towards the cross-platform version.

Version 1 is based on Azure WebJobs, which is written in C# and .NET. Azure WebJobs is essentially a service with a set of adapters for Azure products. These adapters usually go a lot deeper than a standard API. When code is deployed into it, Azure WebJobs reads host.json to create an environment with the same context every time. When you downloaded azure-functions-core-tools, it contained a full production Azure Functions environment, exactly the same as the ones used in Azure. That is why we can only develop on Windows machines for version 1.

Version 2 is based on the new Azure WebJobs, written in C# and .NET Core. It can run on any server that supports .NET Core, which includes all major distributions of Linux, as well as Windows.

.NET Core is significantly faster than .NET and can run on any platform, allowing Microsoft to allocate more types of servers to Azure Functions work.

Rewriting Azure WebJobs in .NET Core will remove support for the plethora of semi-supported, experimental languages, like Python and PowerShell, but will add Java support.

Executing and Scaling Azure Functions

The containers that Azure Functions run in are inherently short-lived, with a maximum execution time of 10 minutes allowed (this was set in host.json, as seen earlier), but it is generally advisable to execute HTTP requests in two minutes. This short timeframe is part of what allows for the flexibility of Azure Functions, so if you need longer execution times but still want most of the convenience of serverless computing, then look at using Azure WebJobs SDK, running on a VM or physical machine that you control, or Azure Data Lake Analytics, if you are processing large datasets.

The resources that Azure allocates to functions is set at the Function App level, split equally among functions inside that app. Most of the time, this will have absolutely no practical impact on your work, and generally, you should keep logically connected functions in the same app. However, in cases where you suddenly demand massive scaling for one of your functions but not for the others, this can cause issues. If your suddenly popular function is one of twenty in an app, it's going to take longer to allocate enough resources to supply it. On the other hand, if you have a seldom-used function that you need better latency from, consider adding it to the Function App of a commonly-used one, so that the function doesn't have to warm up from the cold.

Activity: Creating a Function That Stores User Detail

Prerequisites

You will need Visual Studio installed, with Azure development workload.

Scenario

Creating a personalized application for users.

Aim

Create a function that stores user details.

Steps for Completion

Create a new function, called PostUser, using the HttpTrigger template. If you are competent in another language, like JavaScript or F#, you can try creating it in that language.
Create a new model called User. Think about what properties you'd like to include, but as a minimum, you will need an email address and a unique identifier (these can be the same property).
Modify the function to decode a JSON-formatted request into this model.

Outcome

You have a function ready to store user details.

Refer to the complete code placed at Code/Serverless-Architectureswith-Azure/Lesson 3/BeginningAzureServerlessArchitecture/Models/.

Before the transactions have taken place: User.cs: https://goo.gl/9FpHce.

After the transactions have taken place: PostUsers.cs: https://goo.gl/CWxA2S.