Azure Counsel Podcast

About Azure Counsel Podcast

Azure Counsel Podcast brings you practical tutorials and deep dives into Microsoft Azure, serverless computing, Event Hubs, IoT, and cloud architecture. Learn how to build scalable, real-world applications using Azure Functions, Service Bus, Cosmos DB, and more. Perfect for developers, architects, and cloud professionals seeking hands-on guidance, automation tips, and workflow optimizations. Watch the full video of each episode on my Youtube channel: https://www.youtube.com/@azurecounsel

Publisher

Bhanu Prakash - Azure Counsel

Category

education

Language

en

Explicit

No

First episode

3 Oct 2025

Latest episode

29 Oct 2026

Latest episodes

21 episodes in the feed.

1. 

   29 Oct 2026

   Terraform vs Bicep for Azure Landing Zones: Which IaC Tool Should Cloud Architects Choose? Drift, State, Governance & Enterprise Scale

   Terraform vs Bicep for Azure Landing Zones: Which Infrastructure as Code (IaC) tool should cloud architects choose? Choosing between Terraform and Bicep for Azure Landing Zones is not as simple as saying “Azure means Bicep” or “multi-cloud means Terraform.” Both tools can provision enterprise Azure environments. The real architectural challenge is determining which approach your organisation can operate securely, recover reliably, govern consistently, and maintain over the next five years. In this Azure Counsel architecture deep-dive, we move beyond syntax comparisons and examine the real-world engineering decisions that shape an enterprise Infrastructure as Code strategy. We explore configuration drift, resource ownership, deployment failures, CI/CD security, team boundaries, brownfield adoption, governance blast radius, module evolution, and subscription vending at scale. If you are designing Azure Landing Zones or standardising how multiple teams deploy and manage Azure infrastructure, this episode gives you a practical framework for evaluating Terraform vs Bicep using evidence from your own environment. 🏗️ WHAT YOU'LL LEARN: TERRAFORM VS BICEP • Azure Landing Zones: How Terraform and Bicep fit into enterprise Azure platform architecture, governance, management groups, subscriptions, and shared platform services. • Infrastructure as Code (IaC): Why choosing an IaC tool is an operating-model decision, not just a question of language syntax. • Configuration Drift: What happens when engineers modify Azure resources outside the deployment pipeline, and how each approach handles reconciliation and resource ownership. 👨💻 WHO SHOULD LISTEN? • Azure Architects designing enterprise Azure Landing Zones • Cloud Architects evaluating Infrastructure as Code strategies • Platform Engineers building governed, reusable Azure platforms • DevOps Engineers designing secure infrastructure deployment pipelines • Azure Infrastructure Engineers managing large-scale environments • Technical Leads deciding between Terraform and Bicep • Engineers preparing for enterprise Azure architecture responsibilities and AZ-305-level design discussions 🎓 ABOUT AZURE COUNSEL Azure Counsel delivers practical, production-focused insights into Microsoft Azure architecture, cloud engineering, serverless computing, platform engineering, and event-driven systems. We go beyond introductory tutorials to explore the architectural trade-offs, failure modes, governance challenges, and engineering decisions that matter in real enterprise environments. Follow Azure Counsel for more deep-dives into: ✅ Azure Landing Zones and cloud governance ✅ Terraform vs Bicep and Infrastructure as Code ✅ Azure API Management and enterprise integration ✅ Azure Functions, serverless architecture, and managed identity ✅ Azure Service Bus and event-driven architecture ✅ Cloud architecture, reliability, security, and cost optimisation The deployment is the easy part. The operating model is the architecture. Follow the podcast to build a stronger foundation in Azure architecture and make better infrastructure decisions at enterprise scale. #Terraform #Bicep #AzureLandingZones #InfrastructureAsCode #MicrosoftAzure #CloudArchitecture #PlatformEngineering #AzureDevOps #AzureGovernance #AzureArchitect

2. 

   16 Oct 2026

   Azure Service Bus Prefetch vs Concurrency vs Flow Control Explained: Throughput Tuning, Backpressure, AMQP Credit Model, and Performance Under Load | Azure Counsel

   Microsoft Azure Service Bus is often treated as a simple queueing layer, but under the hood it behaves more like a controlled, adaptive streaming system built on credit-based flow control, buffering, and backpressure management. When throughput breaks in production, it is rarely a “queue issue”—it is almost always a misunderstanding of how Prefetch, Concurrency, and Flow Control interact under load. In this episode, Bhanu (Azure Architect & Developer Advocate) breaks down the internal mechanics that determine how messages move through Azure Service Bus and why systems slow down, saturate, or stabilize depending on configuration choices that most engineers never fully understand. We start with a real production scenario involving Service Bus, Azure Functions, and a downstream SQL database, where throughput degradation is incorrectly attributed to “Service Bus slowness.” In reality, the bottleneck is often downstream processing capacity feeding back into the messaging pipeline. You’ll then explore Prefetch as a buffering mechanism rather than a simple performance toggle. Prefetch pulls messages ahead of time into a local buffer to reduce latency, but misconfiguring it—especially treating it as equivalent to batch size—can cause receiver starvation. This is one of the most common but least understood causes of unstable throughput in production systems. We then break down Concurrency control, which governs how many messages are processed in parallel. Increasing concurrency does not automatically improve throughput. In fact, when combined with slow downstream dependencies such as databases or external APIs, higher concurrency often increases contention, leading to throttling, lock contention, and degraded overall performance. A key part of the discussion focuses on Flow Control in Microsoft Azure Service Bus using AMQP credit-based negotiation. Instead of pushing messages blindly, Service Bus continuously evaluates consumer readiness through credit windows. This ensures that message delivery adapts dynamically to consumer speed, preventing overload conditions before they happen. We then connect this to Backpressure, the most misunderstood concept in distributed messaging systems. Backpressure is not a failure state—it is a protective mechanism. It ensures that when downstream systems slow down, upstream message delivery naturally adjusts rather than collapsing under pressure. Through a tank-and-pump mental model, we visualize how Prefetch buffers messages, how concurrency determines processing throughput, and how flow control continuously regulates delivery speed. This combined system explains why Azure Service Bus often appears “self-stabilizing” under load rather than simply scaling linearly. A major insight from this episode is that Azure Service Bus does not operate as a passive queue. It behaves as an adaptive control system that continuously negotiates throughput based on real-time consumer performance. This is why it rarely breaks under load—but instead degrades gracefully when misconfigured. We also cover what happens when consumers slow down, when prefetch buffers are exhausted, and when no messages are available in the queue. These states are not failures—they are expected behaviors in a backpressure-driven architecture. By the end of this episode, you will be able to move beyond surface-level tuning and develop a mental model of Azure Service Bus as a flow-controlled system rather than a message buffer. This shift is critical for designing stable, high-throughput, event-driven systems. The video also includes a performance tuning demo and GitHub walkthrough available here: https://github.com/Azure-Counsel/ServiceBus/tree/main/PerformanceTuning (https://github.com/Azure-Counsel/ServiceBus/tree/main/PerformanceTuning)

3. 

   27 Aug 2026

   Azure Service Bus Idempotency Mistake: Why Duplicate Detection Fails in Production, Retry Storms, Redis Traps, and Real Distributed System Correctness Patterns | Azure Counsel

   Most developers assume Microsoft Azure Service Bus Duplicate Detection solves idempotency by design. The configuration feels reassuring: enable duplicate detection and the system will automatically prevent repeated processing of the same message. In production systems, that assumption quietly breaks. Nothing fails visibly. No exceptions. No retries. No DLQ spikes. No alerts. Yet the same business operation still executes multiple times—leading to duplicate payments, inconsistent order states, and silent data corruption across downstream services. This is the hidden failure mode of Azure Service Bus Duplicate Detection that only surfaces during production incidents, reconciliation mismatches, or financial audits. In this episode, Bhanu (Azure Architect & Developer Advocate) breaks down why duplicate detection is often misunderstood as a correctness guarantee, when in reality it is only a short-lived broker-level optimization. You’ll learn how systems that appear “idempotent by configuration” still fail under real-world distributed conditions such as retry storms, consumer crashes, lock timeouts, transient database failures, and replay scenarios during recovery workflows. The core issue is architectural: duplicate detection operates only within a bounded time window and only at the broker level. Once that window expires—or when messages are retried through alternate paths—it no longer provides protection. At that point, correctness depends entirely on application-level design. We walk through a real production failure scenario where a payment message is successfully processed, but the downstream database transaction times out. The consumer crashes before confirming completion. The message is retried after the broker’s deduplication window has expired, and the same operation is executed again—resulting in a double charge. No errors are thrown. No system components fail. But the business state is now permanently inconsistent. This is not a messaging failure. It is a distributed consistency failure. You’ll also see why increasing the duplicate detection window does not solve the problem—it only delays failure. In high-throughput or globally distributed systems, replay windows are always shorter than real-world failure recovery timelines. The video then transitions into what real idempotency looks like in production systems. Instead of relying on messaging-layer guarantees, correctness must be enforced at the data layer using patterns such as the Inbox Pattern, transactional idempotency tables, and deterministic state transitions. We also analyze common pitfalls such as using Redis as a standalone idempotency store. While fast and convenient, Redis introduces durability and race-condition risks under failover scenarios, making it unsafe as the sole source of truth for correctness in high-scale systems. By the end of this episode, you’ll understand the fundamental distinction between broker-level duplicate detection and true application-level idempotency. One reduces noise. The other guarantees correctness. This distinction is critical in systems where correctness matters: financial processing, order management, inventory updates, and distributed workflow orchestration. The companion repository includes a full working demo and implementation reference: https://github.com/Azure-Counsel/ServiceBus/tree/main/Idempotency (https://github.com/Azure-Counsel/ServiceBus/tree/main/Idempotency). In enterprise-grade architectures, idempotency is not optional. It is the boundary between reliable systems and silently corrupt ones. This episode is essential for anyone building event-driven systems on Azure who wants to avoid hidden duplication bugs that only appear under load, failure, or recovery conditions. ---------------------------------------------------------------Don’t forget to subscribe for more real-world Azure architecture deep dives and production-ready patterns: ⁠https://www.youtube.com/@azurecounsel (https://www.youtube.com/@azurecounsel)

Contact Azure Counsel Podcast

Guest appearances

Does not typically book guests

Based on episode analysis; this does not confirm that the show is currently accepting guests.