Azure Functions (Serverless)

Azure Functions is a serverless compute service that allows you to run small pieces of code (called 'functions') in response to events, without provisioning or managing infrastructure. The fundamental business problem it solves is the inefficiency and complexity of running dedicated servers for code that only executes occasionally. In traditional on-premises or even IaaS environments, you must maintain a server (virtual or physical) that is always on, consuming resources and incurring costs even when no code is running. For workloads like processing uploaded images, responding to database changes, or handling webhook calls, this leads to significant waste.

Azure Functions eliminates this waste by abstracting away the server entirely. You upload your code, define what triggers it (e.g., an HTTP request, a new blob in Azure Storage, a message in a queue), and Azure automatically runs the code when the trigger fires. The service handles scaling, patching, and resource allocation. You pay only for the time your code executes and the resources it consumes (measured in gigabyte-seconds). This is ideal for unpredictable workloads, microservices, and automation tasks.

At its core, Azure Functions relies on a trigger and a binding. A trigger is what causes the function to run. Common triggers include: - HTTPTrigger: Fires when an HTTP request is received (e.g., from a web app or REST API call). - BlobTrigger: Fires when a new blob is created or updated in an Azure Storage container. - QueueTrigger: Fires when a message arrives in an Azure Storage Queue. - TimerTrigger: Fires on a schedule (like a cron job). - EventGridTrigger: Fires when an Azure Event Grid event occurs. - CosmosDBTrigger: Fires when a document changes in a Cosmos DB collection.

Bindings are a declarative way to connect your function to other Azure services without writing connection code. There are input bindings (read data from a service) and output bindings (write data to a service). For example, a function triggered by an HTTP request might use an input binding to read a document from Cosmos DB and an output binding to write a message to a queue.

When a trigger event occurs, Azure Functions runtime (running on the Azure App Service platform) allocates a sandboxed execution environment, runs your code, and then tears it down after execution (or keeps it warm for a few minutes if you use the Premium plan). The runtime automatically scales out by creating more instances of your function app as the event rate increases.

Azure Functions has two main hosting plans relevant to AZ-900:

Key components of a function app include: - Function App: The container that holds one or more functions. It provides the execution context (runtime stack, environment variables, etc.). - Triggers and Bindings: Defined in the function.json file or via attributes in code. - Host Configuration: The host.json file configures runtime behavior (e.g., global timeout, concurrency limits).

In an on-premises environment, to run code in response to an event (e.g., a file being dropped into a folder), you would: 1. Provision a server (physical or VM). 2. Install an operating system and any required runtime (e.g., .NET, Node.js). 3. Write a Windows Service or scheduled task that polls for the event. 4. Handle scaling manually by adding more servers. 5. Pay for electricity, cooling, maintenance, and staff.

With Azure Functions, you skip steps 1-4 entirely. You write the code, define the trigger, and deploy. Azure handles the rest. The cost model shifts from capital expenditure (CAPEX) to operational expenditure (OPEX) with pay-per-use billing.

To create a Function App in the Azure portal: 1. Navigate to 'Create a resource' > 'Compute' > 'Function App'. 2. Provide a name, subscription, resource group, and runtime stack (e.g., .NET, Node.js, Python). 3. Choose the hosting plan (Consumption, Premium, or Dedicated). 4. Configure storage account (required for triggers and logs). 5. Review and create.

Using Azure CLI:

az functionapp create --resource-group myResourceGroup --consumption-plan-location westus --runtime dotnet --functions-version 4 --name myFunctionApp --storage-account mystorageaccount

This creates a function app on the Consumption plan. You can then deploy code using func azure functionapp publish or through continuous deployment.

A mid-sized e-commerce company processes thousands of orders daily. Each order triggers a series of actions: validate inventory, charge credit card, send confirmation email, and update the warehouse system. Traditionally, this was handled by a monolithic application running on a dedicated server, which was expensive and hard to scale during peak seasons like Black Friday. The team migrated to Azure Functions. An HTTP-triggered function receives the order from the web frontend. It validates the payload, then uses output bindings to write to a queue (Azure Queue Storage) for further processing. A separate Queue-triggered function picks up the message, processes payment via a third-party API, and writes results to a database. A third function sends the confirmation email via SendGrid. The system scales automatically: during low traffic, only a few instances run; during a flash sale, Azure spins up hundreds of instances to handle the load. Cost is a fraction of the old server bill because the company pays only for execution time. The team monitors everything with Application Insights and sets alerts for failed payments or slow responses. One common mistake: not setting a longer timeout (default 5 minutes) for payment processing that occasionally takes longer, causing silent failures. They switched to Premium plan for those critical functions.

A social media startup allows users to upload photos. The backend must create multiple thumbnail sizes (e.g., 150x150, 300x300) and store them in a CDN. Previously, they used a VM with a cron job that polled a folder every minute. This wasted resources and introduced latency. They replaced it with a Blob-triggered Azure Function. When a user uploads a photo to Azure Blob Storage (via the app), the Function is triggered. It reads the image, uses a library (e.g., ImageSharp) to resize, and writes the thumbnails back to a different container. The function runs only when a photo is uploaded, scaling to thousands of concurrent uploads. Cost is minimal – the free grant covers millions of executions. However, they hit a cold start issue: the first upload after a period of inactivity took several seconds. They enabled 'Always Ready' instances in the Premium plan for the thumbnail function to keep it warm. Another pitfall: they originally used the Consumption plan with a 5-minute timeout, but some large images took longer to process. They refactored to process images in chunks or increased the timeout to 10 minutes (max for Consumption). The result: 50% cost reduction and faster time-to-market.

A SaaS company stores user activity logs in Azure SQL Database. By policy, logs older than 90 days must be deleted to comply with data retention regulations. They used a scheduled task on a VM, but the VM had to run 24/7, costing $50/month. They replaced it with a Timer-triggered Azure Function that runs daily at 2 AM. The function connects to the database via a connection string stored in Application Settings, runs a DELETE query, and logs the number of deleted rows. The function runs for about 30 seconds each day. Monthly cost: a few cents. The team also added a second function that runs weekly to archive older logs to cold storage (Azure Archive Storage). This is a classic example of using serverless for simple automation tasks. A common mistake: not handling time zone differences – the timer trigger uses UTC, so they had to adjust the schedule accordingly. Also, they initially forgot to set the function to be retried on failure, so if the database was unreachable, the cleanup was missed. They added a retry policy in the function code.