Azure Functions Development

Azure Functions is a serverless compute service that executes code in response to events. It abstracts away the underlying infrastructure, allowing developers to focus on business logic. The service automatically scales based on demand, and you only pay for the compute resources consumed during execution. This model is ideal for workloads with variable or unpredictable traffic, such as processing file uploads, responding to HTTP requests, or handling queue messages.

At its core, Azure Functions runs on the Azure Functions host, a runtime that manages function execution. When a trigger event occurs (e.g., an HTTP request, a new queue message), the host receives the event and invokes the appropriate function. The host handles: - Scaling: In the Consumption and Elastic Premium plans, the host monitors the number of events waiting to be processed. It uses a scale controller to add or remove function app instances. The scale controller checks every 10 seconds for the Consumption plan, and can add up to 200 instances (default) per function app. - Binding: The host reads the function.json or attributes in code to determine input and output bindings. It creates and manages connections to Azure services (e.g., Blob Storage, Service Bus) automatically. - Lifecycle: On first invocation after a period of inactivity, the host experiences a cold start—loading the function code from Azure Files into memory, which adds latency (typically 0.5-5 seconds for C#, longer for Java). Once loaded, subsequent invocations are warm and fast.

- Hosting Plans: - Consumption Plan: Scales automatically, scales to zero when idle. Billed per execution (number of executions × execution time × memory consumption). Default memory: 1,536 MB. Execution timeout: 5 minutes (default), max 10 minutes. Cold start latency is highest. - Elastic Premium Plan: Pre-warmed instances reduce cold starts. Scales automatically but not to zero. Billed per second of instance usage. Execution timeout: 30 minutes (default), max unlimited (60 minutes for Linux). Supports virtual network integration. - Dedicated (App Service) Plan: Runs on VMs you manage. No automatic scaling to zero. Billed for the VM. Execution timeout: 30 minutes (default), can be increased. Best for predictable, high-throughput workloads.

- Host Configuration (host.json): Controls global behaviors: - maxBatches: For queue triggers, number of messages to process simultaneously (default 16). - batchSize: For queue triggers, number of messages to retrieve at once (default 16). - functionTimeout: Timeout for function execution (default 00:05:00 for Consumption, 00:30:00 for Premium/Dedicated). - queues.maxDequeueCount: Number of times to retry a queue message before moving to poison queue (default 5).

- Application Settings: Configure environment variables. Key settings: - AzureWebJobsStorage: Connection string for Azure Storage account used by the Functions runtime. - WEBSITE_RUN_FROM_PACKAGE: Set to 1 to run from a deployment package (reduces cold start). - FUNCTIONS_WORKER_RUNTIME: Language stack (dotnet, node, python, java, powershell).

Create a function app:

az functionapp create --resource-group myGroup --consumption-plan-location westus --name myFuncApp --storage-account mystorage --runtime dotnet

Deploy code:

func azure functionapp publish myFuncApp

View logs:

az functionapp logs tail --name myFuncApp --resource-group myGroup

Check application settings:

az functionapp config appsettings list --name myFuncApp --resource-group myGroup

A media company uploads thousands of images daily to Azure Blob Storage. They need to generate thumbnails and apply watermarks. They deploy a BlobTrigger function that processes each new blob. The function reads the image, resizes it, adds a watermark, and writes the output to another container. Using the Consumption plan, they pay only when images are uploaded. During peak hours, the function scales out to hundreds of instances, processing images in parallel. They set the maxDequeueCount to 3 to retry failed processing, and use a poison blob queue to log failures. They monitor with Application Insights to track processing time and failure rates. A common misconfiguration is not setting the AzureWebJobsStorage connection string correctly, causing the function to fail silently.

An e-commerce platform processes orders from a Service Bus queue. A ServiceBusTrigger function reads each order message, validates it, updates inventory, and sends a confirmation email via SendGrid. They use the Premium plan to avoid cold starts and ensure low latency. They configure a maximum instance count of 20 to control costs. They use managed identity to access the Service Bus and Azure SQL database, eliminating connection strings. They implement retry logic with exponential backoff for transient failures. The function uses output bindings to write to a database and send email. A common issue is hitting the Service Bus session lock timeout (default 1 minute) if the function takes too long, so they set the function timeout to 5 minutes and use maxAutoRenewDuration.

A financial analytics company runs a TimerTrigger function every hour to aggregate market data from an external API and store results in Cosmos DB. They use the Consumption plan because the workload is predictable and low volume. The function uses input bindings to read configuration from Blob Storage and output bindings to write to Cosmos DB. They use Application Insights to monitor execution duration and set an alert if it exceeds 4 minutes (near the 5-minute timeout). They discovered that the function occasionally fails due to a transient API error, so they added retry logic with a circuit breaker pattern. A pitfall is the TimerTrigger's CRON expression using UTC time, which can cause off-by-one errors if not accounting for daylight saving.