Serverless on Azure – Azure Functions Review

I’ve been learning and using Azure Functions for the past couple of months, so this is my experience so far.

Developing and deploying to Azure Functions is very simple if you’re running an up to date version of Visual Studio.  In the Visual Studio installer, be sure to tick “Azure Development” under the Web and Cloud workflow options.  At the time of writing the latest VS 2017 version is 15.6.4.  The free community edition works fine for this.

Once that’s installed, you’ll have an option under File -> New Project to start an Azure Functions project:

When you start a new project, you’ll get an option to select which API version you want to code against (v1 or v2), and a choice of triggers.  These can all be changed afterward they’re just useful scaffolding:

Recently Microsoft released version 2 of the Azure Functions Runtime, which allows you to use .NET Core or .NET standard rather than the full-fat .NET framework.  There are some limitations however.  I’ve used both v1 and v2, but I’m only using Http and Queue triggers so I haven’t run into any issues (yet).

The great thing about Azure Functions is you can write them in more-or-less any language, with bindings provided for C#, F#, Python, PHP, Javascript/Node and Powershell/Bash.  The function.json file is the heart of the function, and it describes how to trigger your job and its inputs and outputs.

If you’re developing in a language with first-class support such as C#, then the functions.json file is automatically generated for you when you deploy.

Deployment is as simple as right-clicking on the project and hitting “Publish”.  You’ll be given a chance to choose your Azure subscription and whether you wish to publish to an existing app service or create a new one.

When publishing to Azure you have an option to run your function in an app service, or to use the function runtime.  If you choose to run in the context of an app service it allows you to use the infrastructure that you’re already renting for the app service to run the functions.  This allows you to have longer-running functions.  However, if you’re just starting out and your function is doing a single well-defined and short-lived task it makes sense to use the function runtime and only pay for the executions you use.

The Configuration Files

When you first create a functions project you’ll have a C# code file, a local.settings.json and a host.json file.

The host.json file is initially empty apart from a set of curly braces.  It can, however, be extended to configure various parts of how the functions run and respond to triggered events.  For example if you’re listening to a ServiceBus queue you might want to change how many messages the function will try to process at once.  If you only want to process one message at a time (assuming you’re only running the service on a single VM) you can set the host.json to read like this:

    "serviceBus": { "maxConcurrentCalls": 1, "prefetchCount": 1, "autoRenewTimeout": "00:05:00" }

You can find a complete list of options, and their default values here

The other config file is local.settings.json.  Here you can configure application settings that are accessible by key using System.Configuration.ConfigurationManager.AppSettings["settingName"] just as you would with the <appSettings /> tag in an XML config file.  However (and although it’s implied in the name it caught me out initially) this file doesn’t have any effect when you deploy to Azure.

Configuring the Azure instance

Although you can test locally with the local.settings.json file, when you deploy, you need to use the Azure portal to configure the app settings.  When you configure these they’ll be accessible using ConfigurationManager.AppSettings[“settingName”] just as they were locally, so your code doesn’t need to change.  Once you click on “Functions” in the portal, you get an option to “+ Add new setting” as below:

Just give it the same key and it’ll pick it up automatically.


You can now add Application Insights into your function app so that you can monitor exceptions and response times, etc.


Unlike some parts of MSDN which are little more than autogenerated API documentation, the Azure documentation and guides are actually pretty good.  There’s a wealth of information available there.


More to follow.

Leave a Reply

Your email address will not be published. Required fields are marked *