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

🚀 Executive Summary ## 🎯 Key Takeaways ## Is Azure Gaslighting Me? Navigating the Shifting Sands of Best Practices ## The “Why”: From Resource-Centric to Workload-Centric ## Three Ways to Cope When Your “Best Practices” Expire ## Solution 1: The Quick Fix – Retrofit Your ARM with Bicep Modules ## Solution 2: The Permanent Fix – The Full Bicep or Terraform Rewrite ## Solution 3: The ‘Platform’ Fix – Abstracting with the Azure Developer CLI (azd) 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. 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. 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. 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. 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. 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: 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. 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. 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: 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. 👉 Read the original article on TechResolve.blog If this article helped you, you can buy me a coffee: 👉 https://buymeacoffee.com/darianvance Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse CODE_BLOCK: { "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 } } } } Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: { "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 } } } } CODE_BLOCK: { "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 } } } } COMMAND_BLOCK: # 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 Enter fullscreen mode Exit fullscreen mode COMMAND_BLOCK: # 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 COMMAND_BLOCK: # 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 - 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.