Code to Cloud: DevOps for .NET

Azure Functions are powerful for building serverless applications, but when you start integrating them with storage accounts, queues, APIs, and VNets, errors pop up quickly. In this guide, I’ll cover the most common Function App errors with error codes, symptoms, and step-by-step troubleshooting . ⚡ 1. Cold Start Delay Symptoms: First request is very slow (Consumption plan). Error Codes: No explicit error code, only high initialization time in logs/App Insights. Fix: Use Premium/Dedicated plans instead of Consumption. Enable Always On (for App Service plan). Add a timer trigger to keep app warm. ⚡ 2. Function Timeout Symptoms: Request cut off after 5 minutes. Error Codes: 503 Service Unavailable , FunctionTimeout . Fix: Update host.json → increase functionTimeout . Use Durable Functions for long-running tasks. Move to Premium plan for higher timeout limits. ⚡ 3. Trigger Binding Errors Symptoms: Function never fires, startup logs show errors. E...

If you’re a .NET developer and hearing about Azure Cosmos DB for the first time, think of it like this: 👉 Imagine a super-powered cloud database that: Automatically scales to handle millions of users. Lets you store data as JSON documents instead of fixed tables. Works globally with very fast response times . Doesn’t need you to manage servers, storage, or upgrades. Cosmos DB = a NoSQL database that plays really well with .NET. 🔑 Core Concepts (Simple Terms) Database Account → Think of it as your big box in Azure that holds everything. Database → Like a folder inside the box. Container → Like a table (but more flexible). You put your data here. Item → One JSON document (like a row in SQL, but JSON). Partition Key → A way to tell Cosmos how to spread your data across multiple storage units so it can scale. 👉 Example: If you’re storing Orders , you might use CustomerId as partition key. This way, all orders for a customer are stored together. ⚡ Step 1: ...

Over the past 4 parts, we’ve built individual patterns with Azure Service Bus: Part 1 → Queues + Worker Services Part 2 → Topics + Subscriptions (Pub/Sub) Part 3 → DLQ + Retries + Monitoring Part 4 → Sessions, Duplicate Detection, Transactions 👉 In this final part , we’ll combine all these concepts into a real-world e-commerce system . 🏗️ Architecture Overview Imagine a simple e-commerce platform where customers place orders: Customer → Order API → Service Bus (Topic) ↘ Inventory Service (subscription) ↘ Billing Service (subscription) ↘ Email Service (subscription) ↘ Analytics Service (subscription) Order API → accepts orders and publishes events to a Service Bus Topic ( orders-topic ). Inventory Service → updates stock levels (requires ordering → uses Sessions). Billing Service → charges customer (requires...

So far, we’ve covered: Part 1 : Queues + Worker Part 2 : Topics + Subscriptions Part 3 : DLQ, Retries & Monitoring 👉 In Part 4 , we’ll explore three advanced features: Sessions → ordered, FIFO processing Duplicate Detection → prevent double-processing Transactions → atomic send/receive across operations 🔹 1. Sessions — FIFO Message Processing By default, Service Bus does not guarantee ordering — messages can arrive out of order if multiple consumers run. 💡 Sessions let you group related messages (conversation, workflow) so they are processed in order by a single consumer. Example Use Case Order workflow : Step 1 → Payment authorized Step 2 → Inventory updated Step 3 → Invoice generated All steps for the same OrderId must be processed in sequence. Enabling Sessions When creating a queue or subscription, set RequiresSession = true . az servicebus queue create -g myRg --namespace-name mysbnamespace -n orders-session-queue --enable-session true ...

👉 Now in Part 3 , we’ll focus on: 🔎 Dead Letter Queue (DLQ) — what it is and how to handle it 🔄 Retry strategies — built-in + custom 📊 Monitoring with Application Insights — so you always know what’s happening in production When building microservices, things will fail — bad data, network hiccups, downstream services offline. Instead of crashing, Service Bus gives you: Retries → automatic redelivery of failed messages DLQ (Dead Letter Queue) → final resting place for poisoned messages Monitoring → visibility into failures, retries, and latency Let’s break each one down with .NET examples. 🪦 Dead Letter Queue (DLQ) 🔹 What is DLQ? Each queue and subscription in Service Bus has a Dead Letter Queue . Messages go to DLQ when: Max delivery attempts exceeded Message expired (TTL) Explicitly dead-lettered by the app 📍 DLQ path: <queue-name>/$DeadLetterQueue <topic-name>/Subscriptions/<sub-name>/$DeadLetterQueue 🔹 Example: Reading DLQ ...

In part 1 we built a Queue-based system : API → sends orders to a queue Worker → consumes and processes them That works for point-to-point communication. But what if multiple services need to react to the same event ? For example: Inventory Service → update stock Email Service → send confirmation email Billing Service → charge the customer 👉 That’s where Service Bus Topics & Subscriptions shine! 🌟 Topics & Subscriptions: What They Are Topic → like a “broadcast station” where messages are published. Subscription → independent queue that receives a copy of each message. A single message → can fan out to many subscribers . 💡 Each subscription can also apply filters to receive only certain messages. 🏗️ Architecture OrderApi (Producer) → OrdersTopic ↘ InventorySubscription → InventoryWorker ↘ EmailSubscription → EmailWorker ↘ BillingSubscription → B...