Challenges with Azure Resource Naming Convention Maintenance in Bicep and Infrastructure as Code

d2peak and the community discuss the challenges of maintaining Azure resource naming conventions in Bicep and azd workflows, weighing Microsoft’s outdated tools against custom solutions and automation.

Challenges with Azure Resource Naming Convention Maintenance in Bicep and Infrastructure as Code

Author: d2peak

Overview

Developers using Bicep and the Azure Developer CLI (azd) often run into problems with keeping Azure resource naming conventions consistent and up-to-date. d2peak raises key concerns about Microsoft’s current tooling and guidance, and asks how the community approaches these issues.

Key Pain Points

• Outdated Abbreviation Lists:
  • The abbreviation JSON in the azd-starter-bicep repo and the Azure Naming Tool haven’t been updated for over a year, lacking recently added resources.
  • The most up-to-date abbreviations are only available as HTML tables on Microsoft Learn, with no downloadable machine-readable format.
• Difficult Automation:
  • Without a maintained JSON or similar file, keeping naming consistent across codebases becomes manual and difficult to automate.
  • Scraping, as a workaround, is frustrating and unsustainable.
• Uncertainty in Source of Truth:
  • The Azure REST API specs are referenced as the origin for naming restrictions, but contributors note that official abbreviations for resource types (as seen in Microsoft docs) are lacking within these specs.

Community Solutions and Workarounds

• Custom Bicep Modules:
  • Many contributors, including d2peak, use custom modules or helper functions to generate consistent resource names, such as resourceNames.storageAccount(org, env, location, discriminator).
  • Example custom functions in Bicep are shared for community adoption.
• Manual Reference:
  • Developers often keep their own internal copy of resource abbreviations and update them as needed, sometimes by copying from Microsoft Docs manually.
• Terraform AVM Naming Module:
  • Several users recommend AVM naming modules for Terraform as more up-to-date, but some prefer not to rely on third-party modules for critical naming logic.
• Azure Policy Recommendation:
  • Naming restrictions can also be enforced with Azure Policy, including custom policies deployed via Bicep.
  • However, policies only enforce, not generate, names.
• Concerns About Breaking Changes:
  • Some speculate Microsoft may avoid frequent updates or changes to abbreviations to prevent breaking changes, since many resources cannot be renamed without recreation.

Discussion Highlights

• The lack of a maintained, downloadable abbreviation file is broadly seen as a limitation for automation and large-scale deployments.
• Contributors express a preference for maintaining their own modules/functions rather than relying on unmaintained third-party resources.
• Azure Policy is useful for enforcement, but not for generating consistent names.
• The community would welcome an official, machine-readable, continually updated data source for resource abbreviations and naming rules.

References

• AzD Bicep Starter Abbreviations
• Azure Naming Tool Resource Types
• Microsoft Learn - Resource Abbreviations
• Azure REST API Specs
• Custom Bicep Naming Functions Example

Takeaways

• Maintaining up-to-date and automated Azure resource naming is an ongoing challenge with the current tooling provided by Microsoft.
• Developers often rely on their own scripts and modules, or reference outdated files, leading to fragmentation.
• There is a clear need for a machine-readable, officially maintained source of naming standards to support automation.

This post appeared first on “Reddit Azure”. Read the entire article here