Configuration as Code for Infrastructure

Use Terraform or Bicep to manage queue infrastructure alongside service configuration.

In this lesson, you will learn how to codify your messaging infrastructure alongside your application logic using Bicep to ensure your background workers and their underlying queues are always in sync.

When building distributed background systems, manually provisioning a queue—or worse, relying on "default" settings—leads to configuration drift. If your worker code expects a specific dead-letter policy or message time-to-live (TTL), but the infrastructure was manually tweaked in the portal, your system will suffer from runtime failures that are notoriously difficult to debug.

"Configuration as Code" treats your cloud resources as version-controlled artifacts, just like your C# source code. By using Bicep (a domain-specific language for Azure), you can define a Service Bus queue and reference its parameters directly in your deployment pipeline.

Consider this Bicep snippet for a background work queue:

resource backgroundWorkQueue 'Microsoft.ServiceBus/namespaces/queues@2022-10-01-preview' = {
  name: 'order-processing-queue'
  properties: {
    lockDuration: 'PT5M'
    maxDeliveryCount: 5
    defaultMessageTimeToLive: 'P14D'
    deadLetteringOnMessageExpiration: true
  }
}

By keeping this file in your project repository, the infrastructure evolution is tied to the code evolution. If your background worker logic is updated to require a longer lockDuration to handle complex multi-tenant processing, you update the Bicep file in the same Pull Request.

This approach eliminates the "I updated the code but forgot to update the queue timeout" scenario. When your CI/CD pipeline triggers, it applies these changes to your infrastructure before the new code is deployed. This ensures that the environment is always prepared to handle the specific performance characteristics—such as message retries or poison message handling—that your C# consumer currently expects. By treating your queues as immutable components of your application architecture rather than "external settings," you create a reliable, repeatable environment for your background tasks.

Key Takeaway: By defining your queues in Infrastructure-as-Code files within your repository, you guarantee that infrastructure configurations evolve in lockstep with your background worker logic, eliminating deployment-time mismatches.