Azure Functions

Azure Functions provide provide developers the option of running smaller pieces of code in the cloud, also called Function as a Service. This Azure service falls into the category of Serverless application, given that developers don't have control over the underlying operating system.

Azure Functions are usually developed, deployed and hosted as a group. The group is called an Azure Function App. Azure Functions can be built using different languages such as C#, Java, Javascript, Python, and Powershell. An Azure Function App can be built using different development environments such as : Azure Portal, Visual Studio, Azure Functions Core Tools (Cross-platform CLI) with a code editor such as Visual Studio Code.

Hosting Azure Functions

  • Consumption Plan (serverless): automatic scale. It has a time limit of 5 minutes
  • App Service Plan: Traditional pricing model, once a month for compute resources reserved. Doesn't have time limit
  • Premium Plan: faster perfomance, enhanced security, reserved instances. automatic scalability
  • Docker Container: allow to run Azure Functions on premisse or in the cloud
  • Locally

Creating a Function App

When creating a new Function App, you will need the to enter the following details.

  • name
  • resource group
  • unique name
  • Runtime stack: .NET Core, Python, Java, Node.js
  • Region
  • storage account
  • Operating System: Windows or Linux
  • Plan Type

Azure Function Triggers

As mentioned at beginning of the article Azure Functions are hosted in the cloud, developers have different options to start these functions, these options are called triggers. Every Azure function has exactly one trigger. These are

  • HTTP Request Trigger - use for APIs and webhooks
  • Timer Trigger - use for scheduled tasks
  • Queue Trigger - run in response to a message on a queue
  • Cosmos DB Trigger - run when a document is created or updated
  • Blob Trigger - run when a new file is uploaded to Azure blob storage

HTTP Trigger.

  • Choose HTTP methods
  • Route
  • Secured using authorization key: Anonymous, Function (key per function), Admin (key per function app).
  • function.json has the trigger definitoin (every function has a json file)

Blob Trigger

  • Can access properties such as the name of the file using a path like sample-workitems/{name}
  • Can access the blob as well
  • Can choose the storage account connection (by default the same used for the Azure Function)

Implment Input and Ouput bingings

A binding is a connection to data and these are optional. A function can have multiple input and output bindings. Input binginds to get data into our functions. Output binginds to send messages and add document to a database.

  • Blob storage binding - read contents of a file in blob storage
  • Cosmos DB binding - look up a document in a Cosmos DB database
  • Microsoft Graph binding - access One Drive
  • Blob Storage binding - Create a new file in Blob Storage
  • Queue Storage binding - Porst a message to a queue
  • Cosmos DB binding - Create a new document in a database
  • Event Hub, Service, Bus, SendGrid, Twilio

Tools

  • Azure Functions Core Tools
  • Visuatl Studio Code
  • Azure FunctionsVS Code Extensions
  • Azure Storage Emulator
  • Azure Cosomos DB Emulator
  • Microsoft Azure Storage Explorer

Azure Durable Functions

Is an extension to Azure Functions. Create stateful, serverless workflows ("orchestrations") Three types of function required:

  • Client "starter" function: initiate a new orchestration, use any trigger
  • Orchestrator function: Defines the steps in the workflow, handle errors. Has multiple activity functions (parallel or sequence) Returns an instanceId when initiated that can be used to check status.
  • Activity function: implements a step in the workflow. Developers can pass data as parameters and also get a result
  • Function chaining
  • Fan out/Fan in. Multiple activities in parallel and waits until finish
  • Asynchronous HTTP APIs. Do work and pull status until the operation is completed
  • Monitor: Do work/check status
  • Human Interaction: wait for events

Custom Handlers

Using a language or runtime tha is not currently supported. Allow you to use your language or runtime of choice