Solved: Anyone noticing shifts in Azure best practices around scaling, monitoring, or automation?

#devops #programming #tutorial #cloud

🚀 Executive Summary

TL;DR: Azure’s best practices for scaling, monitoring, and automation are rapidly evolving from a resource-centric to a workload-centric philosophy, causing traditional methods and ARM templates to become outdated. Engineers must adapt by leveraging modern tools like Bicep for modularity and readability, or abstracting complexity with the Azure Developer CLI (azd) for streamlined platform engineering.

🎯 Key Takeaways

Azure is fundamentally shifting from a resource-centric to a workload-centric philosophy, pushing for definitions of applications or solutions rather than individual resources, which impacts existing ARM templates and scripts.
Existing ARM JSON templates can be pragmatically modernized by injecting new Bicep modules using the ‘templateLink’ property, allowing for incremental updates without a full rewrite.
The Azure Developer CLI (azd) enables platform engineering by bundling IaC (Bicep), application code, and CI/CD configurations into repeatable packages, abstracting deployment complexity for developers.

Azure’s best practices for scaling, monitoring, and automation are constantly evolving. A senior engineer breaks down why your old methods are failing and how to adapt with practical, real-world solutions.

Is Azure Gaslighting Me? Navigating the Shifting Sands of Best Practices

I got the page at 2 AM. A classic. “Autoscaling failed for prod-web-cluster-01.” I rolled over, grabbed my laptop, and sighed. This was the third time this month. The scaling logic was based on a tried-and-true ARM template and a PowerShell script we’d used for years. It was supposed to be bulletproof. But when I dug in, I found the new VM SKU we’d adopted didn’t expose the same performance counter metric name as the old D-series. The script was polling for a ghost. It felt like Azure had moved the goalposts while I was asleep. That Reddit thread I saw last week suddenly hit home—I’m not the only one feeling this constant, low-grade architectural whiplash.

The “Why”: From Resource-Centric to Workload-Centric

So, what’s really going on? It’s not just about new features. Microsoft is fundamentally shifting its philosophy. For years, the “best practice” was resource-centric. You managed a VM, a SQL DB, a VNet. Our ARM templates were sprawling JSON files that meticulously defined every single resource and its properties. It worked, but it was brittle and verbose.

The new world is workload-centric. Azure now pushes us to think in terms of applications or solutions, not just a bag of resources. This is the driving force behind tools like Bicep, Azure Container Apps, and the emphasis on Landing Zones. They want us to define the “what” (I need a containerized web app with a database and monitoring) and let the platform handle more of the “how.” This shift is why your old scripts and templates are starting to feel rusty—they were built for a different era of cloud management.

Three Ways to Cope When Your “Best Practices” Expire

You can’t just stop production for six months to refactor everything. We’re engineers, not academics. Here are three practical approaches I’ve used to deal with this, from the quick-and-dirty to the strategically sound.

Solution 1: The Quick Fix – Retrofit Your ARM with Bicep Modules

Let’s be real: you have a massive library of battle-tested ARM templates. A full rewrite for that legacy monolith isn’t happening this quarter. The good news is, you don’t have to. You can inject modern Bicep modules directly into your old ARM JSON templates.

This approach is perfect for adding a new, complex resource like an Azure Container App or a properly configured Log Analytics workspace to an existing deployment without touching the 90% of the JSON that still works. It feels a bit hacky, but it’s a pragmatic bridge to the future.

Here’s what it looks like in your azuredeploy.json:

{
  "type": "Microsoft.Resources/deployments",
  "apiVersion": "2020-10-01",
  "name": "addModernMonitoring",
  "properties": {
    "mode": "Incremental",
    "templateLink": {
      "uri": "[uri(variables('bicepModulesBaseUrl'), 'monitoring/logAnalytics.bicep')]",
      "contentVersion": "1.0.0.0"
    },
    "parameters": {
      "workspaceName": { "value": "prod-la-workspace-eus" },
      "retentionInDays": { "value": 90 }
    }
  }
}

Pro Tip: Store your compiled Bicep modules (as ARM JSON) in a central storage account or registry. Using templateLink like this keeps your main ARM template cleaner and promotes reuse of your new Bicep logic.

Solution 2: The Permanent Fix – The Full Bicep or Terraform Rewrite

For any new project, or when you finally get the green light to pay down technical debt on a critical system, you do the full rewrite. You bite the bullet and convert those 5,000 lines of JSON into 500 lines of clean, readable Bicep or HCL. This is the “right” way.

The benefits are immediate: your code is modular, you get amazing tooling in VS Code (linting, IntelliSense), and you can finally reason about your infrastructure without your eyes glazing over. It’s not just about new syntax; it’s about a more robust and maintainable way of working.

Aspect	Old Way (ARM JSON)	New Way (Bicep/Terraform)
Readability	Verbose, nested functions, string concatenation.	Clean, declarative syntax. Looks like code, not a data file.
Modularity	Possible with linked templates, but clunky.	Native module support. Simple and powerful.
Tooling	Basic validation. Errors are often cryptic.	Rich VS Code extensions, pre-deployment validation, “what-if” analysis.
State Management	Azure is the state. Can be slow and unpredictable.	(Terraform) Explicit state file gives you planning and control. (Bicep) Uses Azure’s state but the `what-if` command is a huge improvement.

Solution 3: The ‘Platform’ Fix – Abstracting with the Azure Developer CLI (`azd`)

Sometimes, the problem isn’t just the IaC language; it’s the entire workflow. If you find your team constantly reinventing the wheel for CI/CD, monitoring, and app configuration, it’s time to think bigger. This is where you stop being just a cloud architect and start becoming a platform engineer.

The Azure Developer CLI (azd) is a fascinating move in this direction. It’s an opinionated tool that bundles your IaC (Bicep is the default), your application code, and your deployment pipeline configuration into a single, repeatable package. A developer can clone a repo, run azd up, and get a fully provisioned and deployed environment in Azure without ever writing a line of Bicep or a single YAML pipeline.

It’s defined by a simple azure.yaml file at the root of your project:

# azure.yaml
name: my-web-app-and-api
services:
  web:
    project: ./src/frontend
    language: js
    host: appservice
  api:
    project: ./src/api
    language: dotnet
    host: containerapp

Warning: This is a major shift. You are intentionally hiding complexity from developers. This is powerful, but it requires that your azd templates are rock-solid, secure, and follow your company’s governance rules. You are building the “paved road” for your organization; make sure it leads to the right destination.

Ultimately, the “best practice” is the one that allows your team to ship reliably and safely. These shifts in the Azure ecosystem aren’t meant to punish us; they’re a reaction to the growing complexity of the cloud. Our job is to understand the “why” behind them and choose the right tool—whether it’s a quick patch, a proper rewrite, or a whole new platform—for the job at hand.