The perfect Azure naming convention
This post is the 2nd in the naming convention series . With this post I want to share my approach to naming Azure resources. Why a naming convention is important is already covered by my previous post . However I do believe that some background is required to understand this approach. So, lets dig in.
Naming convention background
A proper naming convention is one of the main methods for building and maintaining Cloud infrastructure as cattle and not as pets. Supporting the transition from the traditional approach of treating infrastructure as pets “unique snowflakes” with names and emotional attachments, to a Cloud native model whereby if a problem with infrastructure is found the infrastructure in question (or its configuration) is “simply” destroyed and replaced (infrastructure as code). This approach is a must to provision and manage the complex and rather large amount of components & configurations the current day Cloud resources are consisting of.
In addition Azure resource names are immutable (meaning that they cannot be changed after creation) and in some cases not reusable for a set period of time (purge protection). So it is crucial to name resources with longevity in mind and to avoid extensive rework and downtime in later stages.
Therefore the purpose of this this naming convention is to ensure resource names reflect a logical structure allowing for all kind of automation, scripting and Infrastructure as Code to find, read and process this complex and large amount of resources & configurations with as little and simple logic as possible. Ensuring proper performance, low effort maintainability and drift control.
Resource tagging, a naming conventions best friend
By prioritizing automation operators might get into trouble processing resources by their names. Therefore any naming convention should always be implemented in conjunction with a proper tagging strategy . Since most resources can be tagged with up to 50 resource tags which are mutable and are unlike the resource names not subjected to limiting naming rules and restrictions an operator is be able to filter, search, find and process resources based on their tags effortlessly (check out the following screenshot examples). Resulting in a best of both worlds scenario. And of course tagging is the first step to implementing cost management but thats a different story :).
Example: Filtering resources
Example: Search resources
Example: Visual summary view
Naming convention explained
Technically this naming convention arranges components sizewise but to simply visualize it the components are arranged in the form of a stacking doll, a.k.a a Matroska . Therefore I like to call this the Matroska approach.
Starting with the biggest component, and moving to an ever smaller one. Up to the point of the sub-resource (examples of sub-resources are noted below) as sub-resource is the smallest component for this naming convention. Practically this naming convention is very similar to the metric system .
Some sub-resource examples:
- A network card part of a virtual machine
- A disk part of a virtual machine
- A managed identity of a resource
Because organizing of resources in a Matroska manner also ties into the order of Azure logical containers (management groups, subscriptions and resource groups) the actual order slightly changes depending on what is considered an environment. Is an environment defined as a subscription or as a resource group? Or in some cases even as a management group?
This is how the Matroska naming convention would look like when a subscription defines an environment.
The following image show an implemented example of this approach. It consists from a workload called Digital Solutions, with a production environment which contains a payment processing application that runs a virtual machine that has a network interface.
Lets go ahead and try to implement the Matroska approach, putting this example to practice.
Workload naming convention in practice
In addition to the Matroska approach I keep the following common guidelines in mind:
- All words must be in lower case
- With the exception of hyphens (-), spaces and special characters are not allowed
- Where possible, kebab-case should be used. Hyphens can be removed for services where only alphanumeric characters are allowed e.g. Storage Accounts
- Recommended abbreviations for Azure resource types
should be used for the
<service-name-suffix>and<sub-resource-name-suffix>
Subscriptions as environments
If a subscription is considered as an environment the Matroska naming convention should be as follows:
<workload-name-affix>-<environment>-<application>-<service-name-suffix><instance-number>-<sub-resource-name-suffix><sub-resource-number>
Example:
Resource groups as environments
If a resource group is considered as and environment the Matroska naming convention should be as follows:
<workload-name-affix>-<application-suffix>-<environment>-<service-name-suffix><instance-number>-<sub-resource-name-suffix><sub-resource-number>
Example:
Environment Acronyms
To support the above elaborated naming convention the I have defined the following environment acronym’s. Currently I have limited these to the following two versions. A single letter and a 3 letter one.
Single letter:
Three letter:
Closing statement and further reading
Thanks for reading this post, if you haven’t please check out previous post on this subject and I cant wait to share my next post of this series. If you are interested please check out following documentation from Microsoft on this topic.
- Resource abbreviations
- Resource tagging
- Resource naming -> In my opinion this example naming convention is outdated but the rest is still relevant
- Resource naming rules