This is part 4 of a 4-part series about Azure App Service. You can find the other posts in this series here:
And if you like these posts and want to support me in what I do, please visit my Pluralsight page and follow me and check out the
courses on my website.
Azure Functions is one of the most popular services in Azure. They offer the ability to run pieces of code that are triggered by events or a schedule, like every hour or when a new message is added to a queue. Azure Functions run inside Azure Function Apps, which is an App Service Type. Within a Function App, you can run one or more Azure Functions.
Azure Functions are the evolution of Azure WebJobs, which is a feature of Azure App Service. Azure Functions are based on the WebJobs concepts and technology. Basically, they are the standalone, improved equivalent of Azure WebJobs.
You can write and run code in Azure Functions, in a lot of flavours. You can run C# and F# code, JavaScript, Python, and Java.
The code that you write and run in Azure Functions is the application that Azure Functions runs. Just like in WebJobs, this application can be triggered by various triggers. For instance, an Azure Functions application can be triggered by Azure Event Hubs, by Azure Service Bus topics and queues, or it can be triggered by a timer, let’s say, every hour. There are many trigger types that can trigger an Azure Function, Azure Blob Storage, Azure Storage queues, and the HTTP trigger.
Additionally, Azure Functions have bindings. A blob trigger, for instance, can also be a binding. This means that when a Function is triggered by a new blob in Azure Storage, the binding takes care of passing the blob value into the Azure Function code. You don’t have to write any code to connect to Azure Blob Storage, you just receive the blob to work with. There are also outgoing bindings which you can use to return values to services like Azure Service Bus or Azure CosmosDB.
In a nutshell, Azure Functions allow you to just write the code that you need and takes care of running and scaling it.
Azure App Service Function Apps enable you to focus on the code that adds value. Here are some facts about Function Apps:
- Function Apps are part of Azure App Service and can contain one or more Azure Functions
- An Azure Function can run code that is written in C#, F#, JavaScript, Python or Java
- Azure Functions can be triggered by a schedule or by an outside event, like a HTTP call, a new blob in Azure Storage or something else
- You can use bindings in Azure Functions to get input values from outside services like Azure Storage. You can also use bindings to output values to services like CosmosDB
- Function Apps can run in an App Service Plan (just like other App Service types) or serverless (more on this later on)
You’ve probably heard about serverless and that Azure Functions are serverless. What does that mean?
You can choose to run a Function App (which runs one or more Functions) in an App Service Plan or in a consumption plan (this is also called serverless).
When you choose the App Service Plan, you run the Function App just like any other App Service. You choose the App Service Plan pricing tier and you are limited to the resources of that App Service Plan. In this case, you pay a fixed price every month for the App Service Plan.
If you choose to run the Function App in consumption mode, you don’t choose a pricing tier. You pay for when an Azure Function runs and for how long it runs. The actual price is calculated by the amount of executions and by looking at resource consumption, which is calculated by multiplying average memory size in gigabytes by the time in milliseconds it takes to execute the Function.
The consumption mode is perfect when you want to be able to scale endlessly as you aren’t bound to the resources in the App Service Plan. Also, you don’t pay anything if the Function isn’t used.
Here is a comparison of running a Function App in an App Service Plan vs. a consumption plan.
|
App Service Plan |
Consumption Plan |
| Function time out |
Unlimited |
Max 10 minutes |
| Scaling mode |
Needs to be configured |
Automatic |
| Scaling limits |
Limited to App Service Plan |
Unlimited |
| Function startup time |
Fast, when you use Always On |
Slower |
| OS options |
Windows, Linux, Container |
Windows |
| Pricing |
Fixed per month |
Based on consumption |
This last post was a bit shorter than the previous ones. I hope that it still helps you. Thank you for reading this series of blog posts about Azure App Service. I hope that these helped you to understand what Azure App Service is and which ones you can use for which purpose.
