This is the second post in a series: Azure Functions 101. In this series I will be covering the following topics:
- Part 1: What Is Azure Functions
- Part 2: Anatomy of Azure Functions (this post)
- Part 3: Deploying Azure Function Resources Using Bicep and GitHub Actions (coming soon)
- Part 4: Creating Azure Functions using the Azure Functions Core Tools (coming soon)
- Part 5: Publishing Azure Functions Using GitHub Actions (coming soon)
In the previous article, I introduced Azure Functions – its use cases, benefits, and limitations. In this post I will be describing the anatomy of Azure Functions.
Table of Contents:
- Azure Function App
- Scale Controller
- Application Settings
- Logging and Monitoring
- Function Code
Azure Function App
This is a collection of one or more Azure Functions. You cannot deploy a single Azure Function in isolation. It must be deployed as part of a Function App. In other words, a Function App is the deployment unit for Azure Functions. All functions inside a Function App share the same configuration, such as the runtime version, the application settings, and the storage account.
The Functions runtime is responsible for running your code. The runtime includes logic on how to trigger, log, and manage function executions.
The scale controller is responsible for managing the number of instances of a function that are running. It monitors the rate of events that trigger the function, and adjusts the number of accordingly. It is responsible for ensuring that the function is able to handle the load that it is receiving. If you are running your Azure Functions in Docker containers, you’ll only have the runtime and not the scale controller. You will have to manage the scaling of your functions yourself using tools such as KEDA.
The runtime and the scale controller are the two key components of the Azure Functions service. As a developer, you don’t need to worry much about them. Of course you’re are responsible for choosing the runtime version that you want to use, but the scale controller is managed by Azure Functions.
Application settings are configuration values that a function can use at runtime. They can be used to store connection strings, API keys, environment variables, or any other values that the function needs to access during execution. Application settings can be stored securely in the Azure portal or in a
local.settings.json file during development.
Logging and Monitoring
Azure Functions provide built-in logging and monitoring capabilities that allow developers to diagnose issues and optimize performance. The logging system captures detailed information about the execution of a function, including input and output data, exceptions, and timing information. The monitoring system provides real-time metrics and alerts for functions, allowing developers to identify issues and respond quickly.
Triggers, as the name suggests, are the events that trigger the execution of an Azure Function. Each function should have only one trigger. Triggers have associated data, which is often provided as the payload of the function. There are several types of triggers available in Azure Functions. The following table lists some of the available triggers:
|Blob||Triggered when a new blob is added to a blob storage container.|
|Cosmos DB||Triggered when a new document is added to a Cosmos DB collection.|
|Event Grid||Triggered when an event is published to an Event Grid topic.|
|Event Hub||Triggered when a new message is added to an Event Hub.|
|HTTP||Triggered when an HTTP request is received.|
|IoT Hub||Triggered when a new message is added to an IoT Hub.|
|Queue||Triggered when a new message is added to a queue.|
|Timer||Triggered on a schedule.|
Here is an example of a function that is triggered by an HTTP request:
The function trigger is defined by the
HttpTrigger attribute. The trigger’s associated data is provided as the
HttpRequest parameter. The
HttpRequest parameter is an object that contains information about the HTTP request, such as the request body, headers, and query string parameters.
Bindings provide a way to declaratively connect other resources to the function. They are provided to the function as parameters. By using bindings, developers can write less code to interact with external systems, as the binding takes care of the details of connecting to and interacting with the external system. There two types of bindings: input and output bindings. Input bindings are used to read data from other resources, while output bindings are used to write data to other resources. The following table lists some of the available bindings:
|Blob||Used to read and write data to a blob storage container.|
|Cosmos DB||Used to read and write data to a Cosmos DB collection.|
|Event Grid||Used to publish events to an Event Grid topic.|
|Event Hub||Used to read and write data to an Event Hub.|
|IoT Hub||Used to read and write data to an IoT Hub.|
|Queue||Used to read and write data to a queue.|
|Service Bus||Used to read and write data to a Service Bus queue or topic.|
|SignalR||Used to send messages to a SignalR Hub.|
|Table||Used to read and write data to a table storage table.|
Each binding has a corresponding attribute that is used to define the binding. The attribute takes in parameters that define how to connect to the external resource. For example, the
Blob attribute takes in the path to the blob storage container as a parameter. I have enhanced the previous example to use an output binding to publish an event to an Event Grid topic:
The output binding is defined by the
EventGrid attribute that takes in the topic endpoint and the topic key as parameters.
In this post I provided an overview of the different components that make up an Azure Function, including the function trigger, function code, bindings, function host, application settings, logging and monitoring. I hope you found this post useful. If you have any questions or comments, please leave them below.