Functions
Last updated
Last updated
The three main hosting plans for Functions:
Plan | Benefits |
---|---|
If you run on a Dedicated plan, you should enable the Always on setting so that your function app runs correctly.
On an App Service plan, the functions runtime goes idle after a few minutes of inactivity, so only HTTP triggers will "wake up" your functions.
Always on is available only on an App Service plan.
On a Consumption plan, the platform activates function apps automatically.
Function apps that share the same Consumption plan scale independently.
In the Premium plan, the plan size determines the available memory and CPU for all apps in that plan on that instance.
By default, Consumption plan functions scale out to as many as 200 instances, and Premium plan functions will scale out to as many as 100 instances.
Using an App Service plan, you can manually scale out by adding more VM instances. You can also enable autoscale, though autoscale will be slower than the elastic scale of the Premium plan.
A function contains two important pieces - your code, which can be written in a variety of languages, and some config, the function.json file. For compiled languages, this config file is generated automatically from annotations in your code. For scripting languages, you must provide the config file yourself.
The function.json file defines the function's trigger, bindings, and other configuration settings. Every function has one and only one trigger.
The bindings
property is where you configure both triggers and bindings.
All triggers and bindings have a direction property in the function.json file:
For triggers, the direction is always in
Input and output bindings use in
and out
Some bindings support a special direction inout
. If you use inout
, only the Advanced editor is available via the Integrate tab in the portal.
Durable Functions is an extension of Azure Functions that lets you write stateful functions in a serverless compute environment.
The durable functions extension lets you define stateful workflows by writing orchestrator functions and stateful entities by writing entity functions using the Azure Functions programming model. Behind the scenes, the extension manages state, checkpoints, and restarts for you, allowing you to focus on your business logic.
The primary use case for Durable Functions is simplifying complex, stateful coordination requirements in serverless applications. The following sections describe typical application patterns that can benefit from Durable Functions:
Function chaining
In the function chaining pattern, a sequence of functions executes in a specific order. In this pattern, the output of one function is applied to the input of another function.
Fan-out/fan-in
In the fan out/fan in pattern, you execute multiple functions in parallel and then wait for all functions to finish. Often, some aggregation work is done on the results that are returned from the functions.
With normal functions, you can fan out by having the function send multiple messages to a queue. To fan in you write code to track when the queue-triggered functions end, and then store function outputs.
Async HTTP APIs
The async HTTP API pattern addresses the problem of coordinating the state of long-running operations with external clients. A common way to implement this pattern is by having an HTTP endpoint trigger the long-running action. Then, redirect the client to a status endpoint that the client polls to learn when the operation is finished.
Monitor
The monitor pattern refers to a flexible, recurring process in a workflow. An example is polling until specific conditions are met.
Human interaction
There are currently four durable function types in Azure Functions:
Orchestrator
Orchestrator functions describe how actions are executed and the order in which actions are executed. An orchestration can have many different types of actions, including activity functions, sub-orchestrations, waiting for external events, HTTP, and timers. Orchestrator functions can also interact with entity functions.
activity
Activity functions are the basic unit of work in a durable function orchestration.
entity
Entity functions define operations for reading and updating small pieces of state. We often refer to these stateful entities as durable entities.
client
Orchestrator and entity functions are triggered by their bindings and both of these triggers work by reacting to messages that are enqueued in a task hub. The primary way to deliver these messages is by using an orchestrator client binding, or an entity client binding, from within a client function.
Executes code in any modern language
used when you need to perform work/task in response to an event, timer, or message from another Azure service
can be either stateful(durable functions) or stateless(default)
stateless - behaves as if they're restarted every time they respond to an event.
stateful - a context is passed through the functions to track prior activity.
Azure Functions can perform orchestration tasks by using an extension called Durable Functions, which allow developers to chain functions together while maintaining state.
Functions App
automated and flexible scaling based on workloads
end-to-end development experience, i.e., build, debug, deploy and monitor
support for multiple languages and hosting options
programming model is based on triggers and event that assists with responding to events and seamlessly connecting to services.
Event-driven scale:
Timers, for example, if a function needs to run every day at 10:00 AM
HTTP, for example, API and webhook scenarios
Queues, for example, with order processing
Instead of writing an entire application, a function that contains both code and metadata about its trigger and bindings.
Triggers define how a function is invoked. Bindings provide a declarative way to connect to services from within the code.
Property | Types | Comments |
---|---|---|
Consumption plan
This is the default hosting plan. It scales automatically and you only pay for compute resources when your functions are running. Instances of the Functions host are dynamically added and removed based on the number of incoming events.
Premium plan
Automatically scales based on demand using pre-warmed workers, which run applications with no delay after being idle, runs on more powerful instances, and connects to virtual networks.
Dedicated plan
Run your functions within an App Service plan at regular App Service plan rates. Best for long-running scenarios where Durable Functions can't be used.
ASE
App Service Environment (ASE) is an App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at high scale.
Kubernetes
Kubernetes provides a fully isolated and dedicated environment running on top of the Kubernetes platform. For more information visit Azure Functions on Kubernetes with KEDA.
type
string
Name of binding. For example, queueTrigger
.
direction
string
Indicates whether the binding is for receiving data into the function or sending data from the function. For example, in
or out
.
name
string
The name that is used for the bound data in the function. For example, myQueue
.