• Albert Bennett

Tech Talk: Azure Function Apps Basics

Updated: Jul 12, 2021

So here we are all about Azure Function Apps. In this post, I will be explaining to the best of my knowledge what a Function App is, and any tips tricks and issues that I have come across whilst using them. More specifically, when setting them up and publishing to them directly from Visual Studios.


Simply put, a Function App is a server-side application that is hosted in Azure. In it you create various different Functions.

Each function has a trigger type. A trigger type defines what/ how the function is going to be triggered. The most common type is HttpTrigger. When published to an Azure Function App the trigger becomes an endpoint that can be called.

The Setup

Function Apps like most Azure resources are easy to set up. Simply search for them in the "marketplace" and click "Create".

However it is whilst creating them that we can come into a few... unknowns. Now a Function App is created inside of something called a resource group. I'll be doing a separate post on this but, for the purposes of this the only thing that you need to make sure of is the the region that the resource group and the Function app are in are the same. This will help with performance as the resources will be closer together.

- Hosting Type

Now there are two options for this field, consumption plan and app service plan. Consumption plan means that you only get charged per thousand calls as opposed to an app service plan which incurs a monthly fee.

There are benefits to using one over the other. Pricing being one but, Functions apps on a consumption plan have this thing called a cold start. Basically when the Function App has been left unused for so many minutes it gets turned off. So when the next request comes in it will take time to spin up the required resources. Function apps on an app service plan don't have this issue, unless their "always on" property is turned off.

- Application Insights

This is a service that is used to monitor your Azure Function App. It is a means of catching errors that are thrown, and enable you to debug the function app and see where it is failing.

- Storage Account

This is the place where the code/ resources for the Azure Functions will be published to. You don't have to create a new one for each Function App. Instead try to have only one per resource group. It will help when trying to manage resources.

The Code

This is a sample of what the default Http trigger function looks like. This a a project called Azure Functions and can be created as soon as you have the Azure Cli tools and relevant extensions installed. It is a .Net core 2 project.

- Every function needs to return an IActionResult. This is basically the response from the function's execution.

- The "FunctionName" attribute defines the name of the function when published.

- "get", "post" refer to the http methods that a request can have to execute the function.

Authorization Levels

Each trigger has an "AuthorizationLevel". The "AuthorizationLevel" defines what can make calls/ access to it.

. Anonymous

. Function

. Admin

. User

. System

Before I go on to what each "AuthorizationLevel" is it is worth noting that with each Function App there are two sets of authentication keys. The host key and the function key. The host key and "_master" key is scoped at the function app level, meaning that there should only be one of each host key per function app (2 total). Whereas the function key is scoped on a function level, as such every function can have there own unique function key.

- Anonymous triggers can be called by any valid http request

- Function triggers can be called by any valid http request that passes on the function key

- Admin triggers can be called by any valid http request that passed the host key

- User triggers can be called by any valid http request that has a valid bearer token

- System triggers can be called by any valid http request that passes the master key

The Extra Files

With each azure function app the you create there are two extra files. local.settings.json, and host.json.

- The local.settings.json file defines application settings and can be retrieved by using Environment.GetEnvironmentVariable

this file is not published to the function app. As such you can hold sensitive information in it without the risk of exposure.

- The host.json file defines how the function app is to be hosted. Namely what version are the function apps.

Publishing Code from Visual Studios

To publish you can find the publishing option under the "Build" tab in VS (Visual Studios). Select use existing, then click publish. Fill out the details and find your function app in the drop-down menu. Click "ok" and away you go. In a few minutes... the process can take a while...

Now, there are several gotcha ya's when publishing directly from VS namely. The problem of locked files. These are files that are currently in use by the function and cannot be overwritten, which causes us problems :( .

To overcome this we are going to need to add an app setting when we are publishing to our function it is MSDEPLOY_RENAME_LOCKED_FILES with a value of 1:

If that doesn't work, stop the function app in the portal then try to publish again. Then start it again.

I hope that helps you understand the basics of function apps.

If you have any questions leave a comment and, I'll get back to you as soon as I can.

44 views0 comments

Recent Posts

See All