Architecting for self-discoverable Azure resources with Azure tagging and naming conventions
Many moons ago, as a Cloud engineer/ Architect, I recall spending countless hours trying to maintain a vast number of Azure resources which meant tracking resource names as they are provisioned and decommissioned. As part of the DevOps Pipeline to provision apps, there is a need to reference Container Registry, Storage, App Configuration and other resources, and so, it is necessary to provide the name of the resources. Azure requires you to name resources to be globally unique and this means if the names were taken, I need to provide a different name (while making sure I follow the company’s naming guidelines) and make sure they are updated in the DevOps Pipelines. It is not that I don’t appreciate this because I absolutely love the ability to name Azure resources and access those resources, but it also meant I need to somehow be guaranteed that I have access to those unique names.
Thus, I started exploring other means of identifying Azure resources without caring about the name itself and thought of using tags. Azure tags are just key/value pairs that can be applied to most Azure resources and one common use case is to use it to identity resources for cost management today. For our purpose, we are using it to help identify resources as well. Note that there are some restrictions such as character limits and each resource, resource group, and subscription can have a maximum of 50 tag name-value pairs per this writing. However, for my need, this is sufficient.
From an organization perspective, I decided that I wanted to have 3 identifiers or keys — stack-name for the name of the resource, stack-environment to identity the environment of the resource and stack-owner which contains the email address of the team responsible for the resource — although this third tag does not directly impact our discussions for now.
Now that we have the concept, let’s talk about an example. In this setup, I have 2 Azure Container Registries for both Dev and Production. I would provide the stack-name value of shared-container-registry for both resources, and stack-environment as dev and prod for each environment. The self-discovery part of this whole setup would be that everyone would understand that the stack-name would never change. If we had to delete the Azure Container Registry in any environment and provision a new one with a different resource name, we will still use the same stack-name and stack-environment.
A simple script to perform self-discovery might look like the following with the Azure CLI and PowerShell. We pass in the stack-name and stack-environment.
In some organizations, there will be multiple teams, and so it might make sense to add a third filter such as stack-owner which means teams can still make use of the common naming convention but pass in their specific team’s email address and get their own resources.
From this perspective, we are abstracted from the names of our resources and are focused on ensuring our stack-names are unique within our organizations. We can even have auto-generated resource names which means if our resources are publicly addressable, it would not mean anything to anyone externally even if they accidently stumble upon those resources.
