An introduction to Azure Functions.

Serverless is a way that developers can create applications faster by not having the need to maange any infrastructure. You don’t need to worry about where the server is, or how it’s configured or created. As long as it runs your code, you’re happy.

Azure Functions are the next evolution of Web Roles and Worker roles in Azure to allow us to run our code in a Serverless manor.

With Azure Functions you write a single function and deploy it, and when a event is triggered your function is run. You only pay for your function for while it’s running, down to the milisecond, so in theory this should be a cheaper way to execute your code.

Azure Function Concepts


Defines how functions are run and how we are billed.

They are a hosted on Virtual Machines on Azure, but they are Serverless from the perspective of the Function itself and the developer of the function.

You will run a Function in the context of a Function Application which itself is run in the context of a hosting plan. Which hosting plan you select for your Function Application then defines the level of scalability as well as how you are billed for those functions.

Function Application

Every Azure Function runs within a Function Application


Define how a funcntion is executed in response to a particular event

Types of triggers


A set time interval.


Executes a function in response to a HTTP request being received.


Executes a function whenever something happens in Blob Storage


Executes a function when a message is available in a Storage Queue

Cosmos DB

Executes a function when a document is changed in Cosmos DB, either Created, Deleted or Updated.

Event Grid

Executes a function when a specific event happens in Azure, or when custom events which you’ve defined are published to Event Grid.

Bindings and Integrations

A binding is declaration of how data is passed in or out of our function. It’s typical that an Azure Function has one input binding, which is the data that is associated with an event, in the case of an HTTP trigger, the input binding would be to pass the HTTP request object in to your function.

A Azure Fuction can have zero or more output bindings, a typical response for an HTTP trigger function would be an HTTP response object. You can also define additional output bindings, often referred to as integrations. These are often implemented as out parameters on the function instead of the return value, and you configure the Azure Functions runtime to know that data passed out on a particular parameter is it be be integrated with a particular external service. Your function doesn’t need to know how to deliver the data to that external service, you can just pass the data out of the funciton and the runtime will take care of it for you.

There are two ways you can define bindings:

  • Imperitively - by using an attribute on the first parameter of your function
  • Using a functions.json file - Which can be more flexible, which you can define both the input and output bindings, additional output integreations are always defined in functions.json and you can use the portal to define them, but this just modifies your functions.json file.


Code is the action our function takes when executed. Several languages are supported:

  • C#
  • Javascript
  • Python
  • Java
  • PowerShell Core

Each function should execute in a reasobable amount of time and be single responsibility. The input and output bindings takes away a lot of the effort that we would usually spend writing code by handling all taht for us, leaving us to concentrate on the functional code that is needed.


Often if you’re Function doesn’t execute in a certain amount of time, they will actually be executed. This helps with the scalability of the overall Azure Function Service with in the cloud.

If you need long running functions you can change your hosting plan or use durable functions, or use logic apps which is designed to be more durable.