Expanding a bit on the previous post, constructing a naming convention in Azure can be challenging. In AWS, most resources are identified by the system internally with a GUID, and the human-friendly name is a tag. In Azure things are, um, less elegant.
Start With the Defaults Link to heading
The Azure docs present a decent template for naming resources. Their example looks like this:
pip-sharepoint-prod-westus-001
{resource type}-{workload}-{environment}-{region}-{instance}
Of these, I would consider {resource type}, {region} and {instance} to be mandatory, and Azure recommends some
subset of the following tokens in the middle:
- Organization name
- Business unit or department
- Workload, project, application or service
- Deployment environment
Seems pretty straightforward, right? Oh, if only. There’s a lot of other considerations that are going to affect the final format.
It’s a Struct Link to heading
The best way to think about an Azure naming convention is as a struct or database record. It has - as a field
separator, and the values in between are the fields. This has some implications:
- Order of the fields matters
- The individual fields should not be freeform but come from a list of allowed values
- Obviously the text of a field can’t contain
-as a character - They can’t change over the lifetime of the resource, because changing the name requires recreating the resource
Azure doesn’t give you any simple way to enforce this (there are complex ways) but you could construct a simple script or PowerShell function to emit a properly formatted Azure resource name based on a few inputs.
You should use Azure’s internal terminology wherever possible. For instance, there is a list of recommended resource type abbrevations.
Similarly, use Azure’s region codes (eastus instead of useast or ue).
Think carefully about whether a field is mandatory or optional, and if optional what you will do if the field is not
used. Will you omit it entirely, or give it a value of nul or xxx or similar? This occurs most frequently with a
{region} field, as Azure has both regional and global resources, but could also happen with an {environment} or
{instance} field.
Tags Exist Link to heading
Azure doesn’t trumpet tags anywhere near as much as AWS, which is a shame; they’re a powerful feature. Tagging strategy is out of scope for this article, as it doesn’t have the same limits, but when creating the naming strategy keep in mind that many forms of metadata about a resource (such as metadata related to organization structure or cost centre) are better placed in tags - especially if they will change over the lifetime of the resource.
Remember the Target Audience Link to heading
Azure resource names, in general, are for humans. If you have an external system that needs to identify Azure resources, use the ARM APIs to access all the properties of that resource. The ARM resource properties should be considered the single source of truth; you should not be parsing the resource name for individual fields and acting based on their values.
This may seem at odds with It’s a Struct, but the purpose of treating your resource names like a strongly typed record
is for consistency. People can easily spot a resource name that doesn’t follow a standard pattern, and will quickly
internalize a list of the allowed workloads or environments. Because of this, you shoudn’t have differing naming
conventions for different types of resources, or different business units. There are some cases where this is unavoidable -
Azure Container Registries and Azure Storage Accounts, for instance, cannot have - characters in their names. A foolish consistency
is the hobgoblin of little minds, said Emerson, but aim to cleave to a standard. Where you are forced to deviate, do
it sparingly and with copious documentation.
That said, you may find yourself working with some third-party SaaS product that can only access the Azure resource name (for instance, some code security scanners or log analyzers). In such a case, having a rigidly defined name format at least gives you some options.
Hidden Minefields Link to heading
Scope and Uniqueness Link to heading
Nearly every Azure resource has its own limitations on length and allowed characters, and also a specific scope in which it must be unique. This can range from as narrow as “unique within a parent resource” (i.e. subnets in a Virtual Network) to “unique across all of Azure” (i.e. App Services).
In that vein, the {instance} field recommended by Azure is there to distinguish between multiple resources that would
otherwise have the identical names. Azure uses numbers for this field, but numbers are just one type of
uniqueness token, and I don’t recommend them.
Whatever you use for a uniqueness token, you should have it in your naming convention and use it even for singleton resources. Suddenly needing a second copy of a singleton resource happens more frequently than you think, and is a fundamental aspect of Immutable Infrastructure.
Length Link to heading
Azure resource name length limits vary from 15 characters (Windows VMs) to “long enough to write a short note to grandma”. Your naming convention should aim to comply with the most common resources you’re likely to deploy, with well-documented exceptions for resource types with shorter limits.
One undocumented limitation on Azure resource names is that since many of them are also DNS hostnames, names longer than 32 characters can cause DNS resolution problems. The reasons for this are complex, but briefly many DNS lookup optimizations assume that DNS hostnames are never longer than 32 characters, even though this is outright wrong.
What this implies is that subtracting the mandatory fields and their - separators, you’ve only got about 16 characters
left for things like environment, workload, application, etc. and the - field separator will gobble up more of those.
this is not necessarily a bad thing; it forces you to think carefully about exactly what needs to be in a name, and what
can be relegated to a tag.