Azure Functions for Administrators

Azure Functions is a serverless compute service that enables you to run small pieces of code (called functions) in response to events. Unlike virtual machines or App Service plans, you do not manage the operating system, runtime, or scaling. The platform handles all infrastructure concerns, allowing you to focus on code. Functions can be written in multiple languages: C#, JavaScript, Python, Java, PowerShell, and TypeScript.

Serverless computing abstracts away the server. You are billed only for the time your code executes (consumption plan) or for a pre-provisioned plan (premium/dedicated). This model is ideal for sporadic workloads, microservices, and event-driven architectures. For example, processing an image when it's uploaded to Blob Storage, or responding to an HTTP request.

When an event occurs (e.g., a message arrives in a queue), the Functions runtime invokes the appropriate function. The function executes and may produce output (e.g., write to a database). The runtime handles scaling automatically: if many events arrive simultaneously, the runtime creates more instances of the function app. The function must be stateless—any state should be stored externally (e.g., in Azure SQL, Cosmos DB, or Blob Storage).

- Function App: A container for one or more functions. It defines the runtime environment, hosting plan, and common settings. - Triggers: Define how a function is invoked. Common triggers: HTTP, Timer, Blob, Queue, Event Grid, Service Bus, Cosmos DB. - Bindings: Connect your function to other Azure services for input or output without writing connection code. For example, an input binding can read from Blob Storage; an output binding can write to a queue. - Hosting Plans: - Consumption Plan: Default. Scales automatically based on demand. You pay only for execution time (per second) and number of executions. Cold start can occur (up to 10 seconds). - Premium Plan: Pre-warmed instances to avoid cold starts. Scales out to more instances. VNet integration. Billed per second for baseline instances and execution time. - App Service Plan (Dedicated): Runs on a VM that you manage. Predictable pricing. No cold starts. Good for long-running functions (up to 230 minutes).

Using Azure CLI:

az group create --name MyResourceGroup --location eastus
az storage account create --name mystorageaccount --location eastus --resource-group MyResourceGroup --sku Standard_LRS
az functionapp create --resource-group MyResourceGroup --consumption-plan-location eastus --runtime dotnet --functions-version 4 --name MyFunctionApp --storage-account mystorageaccount

This creates a function app in the Consumption plan. The --storage-account is required for internal operation (e.g., storing function code and metadata).

Triggers and bindings are defined in the function's configuration (function.json) or via attributes in code. For example, a Blob trigger function in C#:

public static void Run(Stream myBlob, string name, ILogger log)
{
    log.LogInformation($"C# Blob trigger function Processed blob
 Name:{name} 
 Size: {myBlob.Length} Bytes");
}

The trigger is defined in function.json:

{
  "bindings": [
    {
      "name": "myBlob",
      "type": "blobTrigger",
      "direction": "in",
      "path": "samples-workitems/{name}",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

In the Consumption plan, the Azure Functions scale controller monitors the trigger's event rate. For a queue trigger, it polls the queue length. When a message appears, it creates a function instance. If many messages arrive, it creates more instances, up to 200. Each instance processes one message at a time by default. The scale controller uses a threshold: if the queue length exceeds 1,000 messages, it adds instances aggressively.

az webapp log tail --resource-group MyResourceGroup --name MyFunctionApp

Functions are often used with: - Azure Logic Apps: Orchestrate multiple functions and services visually. - Azure Event Grid: Trigger functions on events from Azure resources. - Azure Cosmos DB: Input/output bindings for NoSQL operations. - Azure Service Bus: Trigger on queue/topic messages.

A media company uploads thousands of images daily to Azure Blob Storage. They need to generate thumbnails and extract metadata. They deploy an Azure Function with a Blob trigger. When an image is uploaded to the images container, the function runs, creates a thumbnail using a .NET image library, and saves it to a thumbnails container. It also writes metadata to Cosmos DB. In production, they use the Premium plan to avoid cold starts because image uploads spike during business hours. They set the function timeout to 10 minutes to handle large images. They monitor using Application Insights and set up alerts if the failure rate exceeds 1%. Misconfiguration: If the storage account used for the function app is the same as the one being monitored, it can cause throttling. Best practice: use a separate storage account for the function app runtime.

A financial services company needs to sync transaction data from an on-premises SQL Server to Azure SQL Database every hour. They create a Timer trigger function that runs every hour (CRON: 0 0 * * * *). The function uses a VNet-integrated Premium plan to securely connect to the on-premises database via a VPN gateway. It reads new transactions, transforms them, and writes to Azure SQL. They monitor execution duration and set alerts if it exceeds 50 minutes. Common issue: if the function takes longer than the timer interval, multiple instances can overlap, causing duplicate processing. Solution: use the Singleton attribute or queue-based processing.

An e-commerce site processes orders via an HTTP-triggered function. When a customer submits an order, the function validates it, writes to a Service Bus queue for downstream processing, and returns a confirmation. They use the Consumption plan because traffic is unpredictable. During Black Friday, the function scales to 200 instances, handling thousands of orders per second. They use Managed Identity to access Service Bus instead of connection strings for security. Misconfiguration: if the function key is exposed in client-side code, attackers can invoke the function without authorization. Solution: use Azure AD authentication with App Service Authentication.