Definitive Guide to Getting Started With Azure Functions
- Introduction to Serverless Computing
- Azure Functions
- Supported languages
- Development environments
- Hosting plans
- Azure Functions – how do they work?
- Function triggers
- Function input and output bindings
- Advanced concepts
- Durable functions
- Durable functions components
- Durable functions state storage
- Durable functions work process – high-level overview
TL;DR
Serverless computing is an offering that eliminates the need for developers to manage the underlying infrastructure for hosting the code, allowing them to focus more on developing and building applications.
In this post, we are going to look at the concepts of how to work with functions in Azure. We are going to discuss various concepts related to Azure Functions as well as use-case scenarios.
Introduction to Serverless Computing
Serverless computing is an offering that eliminates the need for developers to manage the underlying infrastructure for hosting the code, allowing them to focus more on developing and building applications.
Take the following illustration below:
- By choosing the non-serverless path, the developer is responsible for everything from creating and maintaining the server to creating and maintaining the code itself.
- By choosing the serverless path, the developer delegates the task of creating and managing the server to the cloud provider (i.e Azure) and only deals with creating and maintaining the code itself.
Azure Functions
Now that we know the basics of serverless computing, we can discuss what Azure Functions is, and what it offers.
So, Azure Functions is an Azure service that provides serverless solutions to the developer. It can be used to run small pieces of code that perform a specific task (also known as functions).
Supported languages
There are multiple languages supported when working with Azure Functions. Some of them include:
- C#
- JavaScript
- Java
- Python
- PowerShell
- TypeScript
Development environments
In addition to supporting multiple languages, Azure also provides multiple ways/tools that you can use when you are developing your function:
You can use:
- A built-in editor in the Azure Portal (which is great for starting immediately)
- IDE/Visual Studio (the recommended tool if you are developing for a corporate/production environment)
- Azure Functions Core Tools (which is a CLI based tool)
Hosting plans
When it comes to hosting your function, Azure provides you with the following Hosting options (plans):
- Consumption plan
- Premium plan
- Dedicated plan (App service)
- Kubernetes
- App Service Environment
Azure Functions - How Do They Work?
Let’s recap what we have discussed until now. We talked about serverless computing and how it helps developers, we got an introduction into what Azure Functions are, what tools you can use to write your code and which programming language. Additionally, we went over the various plans you can use to host your function.
Now, let’s start with the most important concepts that make the functions work:
- Function triggers
- Input bindings
- Output bindings
Function triggers
For a function to get executed – there must be something that triggers it.
A function trigger is an event that makes the function run.
EVENT —> FUNCTION —> EXECUTION STARTS
There are multiple trigger types that we can choose from (but bear in mind a function can have only one trigger):
- HTTP request trigger (one of the most commonly used trigger type, the function gets executed when an HTTP request is received)
- Timer trigger (a trigger type that makes the function run based on a schedule, it uses cron to define the schedule)
- Blob storage trigger (a trigger type that makes the function run based on changes on a storage account – ex. a file is added/modified/removed)
Function input and output bindings
Sometimes, when working with functions, you might need to load external resources so that your function can use them and perform specified task.
For this purpose we can use input and output bindings:
- INPUT BINDING: accepts input from an external source
- OUTPUT BINDING: writes to an external source.
To clearly understand this, let’s take a scenario:
We have a function whose job is to read from two files: names.csv (containing the names of the employees) and surnames.csv (containing the surnames of the employees) and combine these two files into one employees.csv file. The function will be triggered by an HTTP request sent by Mark (the marketing manager)
Advanced Concepts
In the last section of this post, we will discuss some of the advanced concepts about Azure Functions.
Durable functions
Let’s say that you have created 2 functions for a law company, which will allow their lawyers to delete sensitive information based on an HTTP request. To make sure that the right information is being deleted the operation will have to pass through the manager which will approve the process:
LAWYER sends HTTP request –> FIRST FUNCTION triggered –> MANAGER approves –> SECOND FUNCTION triggered –> Data is deleted
Doing this with regular functions is a difficult process, that’s why Azure provides us with Durable functions. Durable functions are an extension of the regular functions that allow us to define workflows.
Some of the advantages of using durable functions include:
- Parallel execution (multiple functions can run at the same time)
- Error handling (automatically handles errors on the entire workflow)
- Support advanced workflows (ex. waiting for user interaction)
- Automatically tracks the workflow progress
Durable functions components
Three main components allow durable functions to work:
Orchestrator functions:
Are used to orchestrate and manage the entire workflow (from start to finish). They trigger the activity functions (mentioned below).
Activity functions:
Are individual functions that are used to perform a single task, p.s. they do the real work.
Orchestrator client (DurableClient binding):
Is a function that is used to trigger the orchestrator function, thus starting the whole workflow.
Durable functions state storage
After the orchestrator function triggers an activity function, it goes into sleep mode. When the activity function completes, the orchestrator function wakes up and continues the workflow from where it was.
The workflow state is saved in a Storage Account. To perform this, Azure uses a process known as event sourcing – which instead of storing the current state stores the actions that led to that state (you can compare this with Docker build which builds the image layer by layer).