Serverless Computing Concepts

Serverless computing is a cloud execution model where the cloud provider dynamically manages the allocation and provisioning of servers. The name "serverless" is a misnomer—servers still exist, but the developer never sees, manages, or provisions them. The core business problem serverless solves is the overhead of infrastructure management. In traditional on-premises or even IaaS models, teams must provision VMs, configure networking, apply OS patches, monitor disk space, and plan for capacity. This distracts from writing business logic. Serverless eliminates that overhead entirely. The developer writes code (or configures workflows) and defines what event triggers that code—an HTTP request, a timer, a new file in blob storage, a message in a queue. Azure then automatically runs the code on a managed compute resource, scales it to handle demand, and charges only for the resources consumed during execution. This is ideal for event-driven workloads, microservices, APIs, and automated tasks that run infrequently or unpredictably.

Azure offers two primary serverless compute services: Azure Functions and Azure Logic Apps. Azure Functions is a serverless compute service that runs code (in C#, JavaScript, Python, PowerShell, etc.) triggered by events. Azure Logic Apps is a serverless workflow service that uses a visual designer to orchestrate and automate business processes without writing code. Both follow the same fundamental mechanism:

#### Azure Functions Plans

#### Azure Logic Apps Plans

In an on-premises environment, to run a similar event-driven job (e.g., resizing images when uploaded), you would need:

With serverless, you write a function that triggers on blob creation, upload it to Azure, and Azure handles everything else. No server to patch, no capacity planning, no idle cost. The on-premises equivalent is like owning a car that you keep running in the driveway just in case you need to drive somewhere; serverless is like using a ride-sharing app—you only pay when you ride, and the car is maintained by the company.

In the Azure Portal, you create a Function App (the container for your functions) via "Create a resource" > "Compute" > "Function App." You specify the runtime stack, region, and hosting plan. Inside the Function App, you can create functions using the portal's code editor or upload deployment packages. For Logic Apps, you create a Logic App resource and use the designer to add triggers and actions.

Using the Azure CLI, you can create a Function App with:

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

For Logic Apps via CLI (limited), you typically use ARM templates or PowerShell.

An online retailer uses Azure Functions to process incoming orders. When a customer clicks 'Place Order,' an HTTP request triggers a function that validates the order (check inventory, apply discounts), writes order details to a SQL database, and sends a confirmation email via SendGrid. The team configures the function with an HTTP trigger and sets the authorization level to 'Function' (requires a key). They deploy the function using Azure DevOps. During Black Friday, traffic spikes to 10,000 orders per minute. The Consumption plan automatically scales to hundreds of instances, processing each order in under 200 ms. The cost for that day is about $50—far less than provisioning VMs to handle peak load. What goes wrong? If the function has unhandled exceptions (e.g., database connection timeouts), it may fail silently. The team must implement retry logic and monitor Application Insights for failures. Also, if the function takes longer than the default 5-minute timeout for long-running orders (e.g., generating PDFs), it times out. They solve this by using Durable Functions (an extension for orchestrating long-running workflows) or increasing the timeout to 10 minutes.

A social media app allows users to upload profile photos. Each upload triggers a blob-triggered Azure Function that resizes the image to 150x150 pixels and stores the thumbnail in a separate container. The function is written in Node.js and uses the Sharp library. The team sets up the function with a Blob trigger on the 'uploads' container. The function runs only when a new blob appears. During a promotion that drives 50,000 uploads in a day, the function scales automatically. The cost is minimal—each execution takes ~500 ms and uses 128 MB memory. The problem: if the original image is deleted before the function runs (a race condition), the function fails. The team adds error handling and uses blob leases to ensure the blob is not deleted during processing. Another issue: cold starts cause a 2-3 second delay for the first upload after hours of inactivity. Users notice a lag. The team mitigates this by enabling the Premium plan with pre-warmed instances, or by using a warm-up trigger (a timer function that runs every few minutes to keep the host alive).

A healthcare SaaS company needs to delete patient records older than 7 years to comply with data retention policies. They create a timer-triggered Azure Function that runs daily at 2:00 AM. The function queries a Cosmos DB database, deletes old records, and logs the number of deletions. The function runs on the Consumption plan—it executes for about 30 seconds each night and costs less than $0.01 per month. What goes wrong? If the function encounters a transient error (e.g., Cosmos DB throttling), it may fail to delete all records. The team implements retry logic with exponential backoff. Also, if the timer trigger's schedule is misconfigured (e.g., using UTC instead of local time), records may be deleted at the wrong hour. They test the function with a manual invocation and check the logs.