When Software Attacks!

Configuring diagnostic settings for Azure services using bicep

If you’re hosting your application infrastructure in Azure and consolidate the diagnostic and audit information from your services into Log Analytics or elsewhere, it’s pretty easy to do using Bicep. It’s not very well documented, however, which is the reason for this post. A quick description of our problem If we’re building an application using Azure services then it’s important to think about telemetry. In simple terms, we have two sources of telmetry: Our application code should be instrumented to emit telemetry, either using Open Telemetry, or the Application Insights SDK (this isn’t an otel article - whichever works for you); The Azure services also generate metrics, audit data and logging.

Deploying an Azure Container App Environment within a virtual network using bicep

When working on a project recently I needed to deploy a Container App Environment within a virtual network in Azure. Thanks to the joys of internet search, I started off reading the wrong bits of the official documention and got incredibly confused, and much of the community content about this uses out of date schemas and code. This article is so I don’t need to go through that again, and hopefully it will help others, too.

Using bicep to define Service Bus scaling rules for Azure Container Apps

I recently needed to set KEDA scaling rules on an Azure Container app that used the number of messages in a Service Bus queue. There’s plenty of info out there on the internet about scaling rules, but not when it comes to Service Bus, so I’m writing up what I learned here. Problem Space A recent project made use of Azure Container Apps for backend services, driven through messages placed on Service Bus queues.

Importing bicep lint output as test results in Azure DevOps pipelines

Bicep is a great improvement over ARM Templates but doesn’t remove the need to validate our code at build time. I could continue to use the ARM-TTK and validate the generated template, but bicep has it’s own built in rules. Getting build errors in a way that can provide meaningful information in my CI/CD tooling is an interesting challenge. A quick problem description We are using Azure DevOps for build and release automation.