# Functions

## Explore Azure Functions

The three main hosting plans for Functions:

<table><thead><tr><th width="198">Plan</th><th>Benefits</th></tr></thead><tbody><tr><td><strong>Consumption plan</strong></td><td>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.</td></tr><tr><td><strong>Premium plan</strong></td><td>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.</td></tr><tr><td><strong>Dedicated plan</strong></td><td>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.</td></tr><tr><td><strong>ASE</strong></td><td><a href="https://docs.microsoft.com/en-us/azure/app-service/environment/intro">App Service Environment (ASE)</a> is an App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at high scale.</td></tr><tr><td><strong>Kubernetes</strong></td><td>Kubernetes provides a fully isolated and dedicated environment running on top of the Kubernetes platform. For more information visit <a href="https://docs.microsoft.com/en-us/azure/azure-functions/functions-kubernetes-keda">Azure Functions on Kubernetes with KEDA</a>.</td></tr></tbody></table>

#### Always on <a href="#always-on" id="always-on"></a>

* If you run on a Dedicated plan, you should enable the **Always on** setting so that your function app runs correctly.&#x20;
* 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.&#x20;
* Always on is available only on an App Service plan.&#x20;
* On a Consumption plan, the platform activates function apps automatically.

#### Scale

* Function apps that share the same Consumption plan scale independently.&#x20;
* 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.

## Develop Azure Functions

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.

```json
{
    "disabled":false,
    "bindings":[
        {
            "type": "bindingType",
            "direction": "in",
            "name": "myParamName",
            // ... more depending on binding
        }
    ]
}
```

The `bindings` property is where you configure both triggers and bindings.

<table><thead><tr><th width="147.33333333333331">Property</th><th width="106">Types</th><th>Comments</th></tr></thead><tbody><tr><td><code>type</code></td><td>string</td><td>Name of binding. For example, <code>queueTrigger</code>.</td></tr><tr><td><code>direction</code></td><td>string</td><td>Indicates whether the binding is for receiving data into the function or sending data from the function. For example, <code>in</code> or <code>out</code>.</td></tr><tr><td><code>name</code></td><td>string</td><td>The name that is used for the bound data in the function. For example, <code>myQueue</code>.</td></tr></tbody></table>

### Binding direction <a href="#binding-direction" id="binding-direction"></a>

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 Function*

*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.

<br>

### Application patterns <a href="#application-patterns" id="application-patterns"></a>

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:&#x20;

* 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*.<br>

## An event-driven, serverless compute service

{% embed url="<https://www.microsoft.com/en-us/videoplayer/embed/RE2yzjL?postJsllMsg=true>" %}

{% embed url="<https://docs.microsoft.com/en-us/learn/modules/explore-azure-functions/2-azure-functions-overview>" %}

* 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&#x20;
* 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.