Introduction
When companies start experimenting with the Azure cloud, the often start by going to the portal and just configure the resources they need from the portal. This is done most often without any governance on the Azure landscape. The power and danger of having this kind of power within the click of a button will create a lot of value quickly, and will hit organizations back in a later stage when the Azure landscape is starting to grow.
A lot of the things that are being messed up in the beginning can be correctly easily afterwards. By going to the portal, updating the Infra as Code templates or by Azure Policies most settings can be corrected at scale. However, some things can’t be changed without doing a migration of the data. One of these things that can’t be changed without a redeployment is the naming of a resources.
What is a naming convention?
According to Wikipedia, a naming convention is defined as follow: A naming convention is a convention (generally agreed scheme) for naming things. And in that definition the challenge is directly described: Generally agreed scheme. Because who is going to define the scheme in the organization, and once agreed who is going to enforce and monitor the naming convention.
Some notes from the field
In order to apply a successful naming convention in Azure, I’ll share some experience from the field.
Step 1: Understand the goal of the naming convention
Naming convention is there for a reason. In order to come to the best naming convention you need to understand the value that it’s adding. For me there are multiple reason, but the most important one is that I like automation. I’ve worked for large organization where we needed to maintain and deploy Azure resources for hundreds of developers. And to do this efficiently you want to automate everything to the max. Needing to ask: How would you like to name it? is then becoming a time consuming exercise. Mostly because people will come with different suggestions like: Myteamsstorage account, or johndoest.
Next to that it looks more professional, and it can help in structing the environment regarding to ownership and cost. There are more (and maybe even better) ways to do so, like tagging, but it sure can help.
Important to mention is that the goal can vary per organization. In a big dynamic organization, you want to automate everything and therefor need naming convention. But for small organizations it might be that you use the naming convention for identification of the resources, and automation is not that important (yet).
Step 2: Assign a owner
Naming convention is part of Governance, and governance for me starts always with one thing: Who is the owner? The reason behind this is that there will be a moment, a point in time that the naming convention does not work. This is not a question if it will happen, but when. And when it happens, someone need to decide. This decision you want to have centralized because it might have impact on the whole organization.
Step 3: Identify the key pieces of information
This part is crucial to define the naming convention. What information do I need in my resources? And maybe equally important, which information do I not want in my resources. This is different of every organization and there is in my opinion not a golden truth. But there are some things to consider when doing this.
First thing to consider is: Can the information be changed? For example, if you assign a team name to the resource, is there a change that the ownership of the resource will be transferred to another team? If the answer on the question Can the information be changed is yes, it should not be in the naming convention but in tags.
Second thing is, which kind of information do I want to share in the naming convention. For example, do you want to include the organization name (or an abbreviation) in the resource? This is sometimes useful when multiple organizations use the same tenant and it also helps in making the naming unique. The naming of Azure resources must be unique per region or sometimes even globally. And therefore adding a company abbreviation can be useful.
The Microsoft official documentation1 has some suggestions on which components to add. My advise is to not follow this blindly. It depends per use case, per organization and there is no golden truth.
Some things should in my opinion always be there. These are:
- Resource type
- Environment (dev, test, acceptance, production etc. )
- Index number
Third thing, the order of the convention. In other words, what do you put first, second, third etc. This can be helpful to group resources based on the naming convention. The Microsoft example puts resource type in front. However, that means that resources are being grouped on type, not on use case/solution. So think what the naming convention will do the sorting, and if that is the way you want it.
Fourth thing is if you want a readable naming convention, or consistency. Some resources like a storage account can only have numbers and letters. Naming conventions with a dash will then not work for all resources. I personally like consistency, and therefor use always use naming conventions which are applicable for all Azure resources. This decreases the readability, but my personal advise is to use tags for identification of the resources, not the naming convention. The various rules for naming per resources can be found here: Resource naming restrictions – Azure Resource Manager | Microsoft Learn
Step 4: Documentation
Once you defined the naming convention, it’s important to document this properly. Especially in the beginning when enforcing is not in place. With documentation you can communicate and educate the organization. Make sure you document the rationale, so that in later stage it is still clear why things are the way they are.
Step 5: Enforcement
Last but not least, the enforcement of the policy. It does not matter how good your define your strategy, how good you document and how good you communicate. People will use different names, period. Therefore it’s important that enforcement is in place. When automation is in place, you can do this in code like terraform & bicep. However this might not cover all use cases. Therefor it’s advices to write azure policies to enforce this.
Summary
A naming convention is in my opinion mandatory to set-up a good, professional Azure environment (and other environments off course). It is important to understand how naming works in Azure and define the goal and what you want to have in your naming convention. Without enforcement naming convention is basically useless. But when used properly it can be a very useful way to have your automation to the max.
Sources
To come to this blog, I’ve used the following sources, used some of the code as inspiration and altered it when I felt that it was required:
