Introduction:
This article outlines the basics of Azure Functions which are one of several “Serverless” offerings in Azure. With serverless computing, your code still runs on a server, however the underlying hardware has been abstracted away from developers. Maintenance tasks such as updating the language runtimes, patching security vulnerabilities, fixing hardware faults and system updates etc are all handled automatically.
What Are Azure Functions:
Azure Functions are a serverless offering that enables developers to build applications without the need to manage the infrastructure. This can help reduce time to market and enables developers to focus on the key business logic for the company.
Typical Scenarios For Functions:
In general, Azure Functions are suitable for parts of the application that are triggered by a particular event where the ability to scale quickly may be necessary. For example:
- Microservices / APIs.
- Handling File Uploads
- Run Scheduled Tasks
- IoT Data Processing
Hosting Plans
Every Azure Function must have a hosting plan. The hosting plan that is chosen has an impact on how the application is scaled, what resources are available to each instance of the function application and whether there is support for functionality such as virtual networks. It is possible to migrate between the consumption plan and a premium plan using the Azure CLI when using Windows.
There are three basic plans:
Consumption Plan
This is the default plan. This plan scales automatically depending on the number of incoming events and you only pay for the resources whilst the function is running. This is good for occasional usage. This is basically the full “serverless” approach. The consumption plan can’t be used if you wish to provide a Linux Docker container with your function code.
Premium Plan
This scales automatically based on demand using pre-warmed worker instances. As a result, there is no delay (or cold start) after the function has been idle. The functions can run on more powerful instances and can connect to virtual networks. This is good for continuous usage, if the function will likely execute for longer than the maximum allowed under the consumption plan or if you require more CPU / memory than the consumption plan.
App Service Plan
This is the best hosting plan to use if you require predictive scaling and costs, or if you would like to use your existing app service plan infrastructure.
Requirements:
A function app requires a general purpose Azure storage account. This storage account must support Blob, Table and Queue storage. This storage account is used by the function to manage triggers, log executions. The storage account can either be created as part of the function creation process, or it can be pre-existing. If the storage account is created during the function creation process from the Azure portal, it is guaranteed to meet the necessary storage account requirements. This storage account should be located in the same region as the function app for the best performance. If the storage account is created during the function creation process from Azure portal, this best practice is enforced automatically.
What is a trigger?
Every function must have exactly one trigger - a trigger is what causes the function to be executed. This could be in response to an HTTP request, a new Servicebus message, a timer etc.
For example, we may want our function to generate a report at a given time. In this case, we would want to use a Timer trigger. Or, we may wish the function to execute when a new message arriveson a service bus queue or topic, in which case we would want to use a service bus trigger.
Some common trigger types can be seen in the following chart:
| Type | Purpose |
|---|---|
| Timer | Execute the function based upon a configured interval |
| Cosmos Db | Execute the function when a document has been changed |
| HTTP | Execute the function in response to http requests |
What are bindings?
A function can have multiple input and output bindings. A binding allows us to connect another resource to the function. Whilst every function must have exactly one trigger, bindings are optional. It is possible to have multiple input bindings or output bindings. By using bindings, we can avoid hardcoding access to other services, and the function will receive data from the input bindings in function parameters. The return value of the function can be used to send data.
For further reading around triggers and bindings, I recommend the following: https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-service-bus-output?tabs=in-process%2Cextensionv5&pivots=programming-language-csharp