Why Having an Azure Naming Convention Will Only Slow You Down!
Introduction
In my experience most IT people believe that a naming convention is needed everywhere to ensure a consistent structure in resource names.
One of the root causes of this, I believe, is the NetBIOS protocol (1983) which limits a computer name to 15 characters and does not provide a built-in way to associate metadata to a name.
Computer/server names
Having been limited to only 15 characters for all information for decades has spawned numerous attempts by IT people to cram as much information into those 15 characters has possible.
Common needs include:
- Short company name or prefix (s, ms, etc.)
- Prefix denoting server or client (cl, pc, s, svr etc.)
- Placement in data center or rack or VM host (dk1, nl2, etc.)
- Primary use (db, sql, web, host, mail)
- Numeric serial 3-6 numbers, possibly with 0-padding (000123, 456)
- Environment (prod/test/dev) (p, t, tst, prod)
- Liberal use of dashes
From the list above here are some possible combinations:
- mssvrmail01
- s-sql-01-dk1
- svr-dk1-host-42
- svrnl2mail12
- ms-pc-000123
- dk1-web-452
- prodweb01-dk1
Except maybe for the primary use of a server, none of these elements provide any value what so ever for the users of a system.
If you need to access a server directly (hopefully very rare), you need to know the full name anyway, and at that point you probably also know what the server does.
If a server is moved to another host or data center, would we then have to change it’s name?
Based on this I would recommend the following (very simple) naming convention for clients and servers:
Server + serial number, e.g. server1, server2, …, server42.
Naming will be unique across the entire organization and names are super easy to remember and relay over a phone.
Azure naming conventions
In Microsoft Azure there are numerous naming rules for example:
Primary source: docs.microsoft.com/en-us/azure/architecture/best-practices/naming-conventions
| Resource type | Scope | Naming rules | Length | Examples |
|---|---|---|---|---|
| Resource group | Subscription | ^[-\w\._\(\)]+$ |
1-90 | |
| Tag | Associated Entity | ^[^<>%&\\\?/]+$ |
1-512 (key), 1-256 (value) | { "owner": "user@company.com" } |
| Virtual machine | Resource group | Alphanumeric and hyphen | 1-15 (Windows), 1-64 (Linux) | server42 |
| Web app | Global | Alphanumeric and hyphen | 1-60 | myapp.azurewebsites.net |
| Storage account | Global | Alphanumeric | 3-24 | mydata.blob.core.windows.net |
| Container Registry | Global | Alphanumeric | 5-50 | |
| Service Bus Namespace | Global | Alphanumeric and hyphen (must start with a letter) | 6-50 |
Resources with a global scope will result in public endpoints, these should always be lowercase.
Suggestions
Businesses will very often try to create a global naming convention, i.e. one which should be applied on all resources. This will often if not always result in a lowest common denominator approach like:
- 1-15 characters
- alphanumeric (must start with a letter)
- lowercase only
- globally unique
I addition name must include information about:
- Company name (shortened)
- Resource type
- Environment type
- Region (data center)
- Product/service/solution name
- Serial number
This results in names like:
- drgr001dimension
- rg001dimension
- web001dimension
- sqlsharepoint002
Consequences of naming conventions for resources
Naming with lowest common denominator with required parts will
- Severely limit the ability for DevOps engineers to use names which make sense to them and/or their team.
- Introduce unnecessary readability issues – all lowercase compound words are much harder to read than camelCase, pascalCase or hyphened-words.
- Add redundant information – we already know what a resource is.
- Confuse people: What’s the standard? How do I apply it? Why? I can’t read that??!?!
Also, resources auto-generated by Azure like managed disks ([VM name]_OsDisk_1_25fbb34c5b074882bcd1179ee8b87eeb) or supporting resource group for Azure Kubernetes Service (MC__[Resource group name]) will not follow the naming conventions.
The maintenance/abbreviation nightmare
As mentioned above a naming convention will undoubtedly contain a number of prefix/suffix abbreviations which will have to be both understood and maintained.
In many cases a fixed length has also been enforced as a requirement. This makes matters a lot worse as common abbreviations for certain resources are two letters while others are three or maybe four. What do we do with the white-space? Or how do we shorten an already established abbreviation.
Have a look at the following table:
| Name | Two-letter | Three-letter | Longer |
|---|---|---|---|
| East US 2 | eastus2 | ||
| West Europe | we | weu | |
| North Europe | ne | neu | |
| Denmark | dk | dnk | |
| Virtual Machine | vm | ||
| Virtual Network | vnet | ||
| Network Interface | nic | ||
| IP Address | ip | ||
| Subnet | |||
| Database | db | ||
| SQL Server | sql | ||
| MySQL Server | mysql | ||
| PostgreSQL Server | postgres | ||
| Web App | ` | web | |
| PowerShell | ps1 | ||
| Resource Group | rg | rgr | |
| Service Bus | sb | bus | |
| Firewall | fw | ||
| Application Gateway | gw/lb | waf |
Now come up with two-letter and/or three-letter meaningful and (preferably) unambiguous abbreviations for the following Azure resources (very incomplete list):
- Logic App
- Function App
- Cosmos DB
- IOT Hub
- Notification Hub
- Event Hub
- Event Grid
- Application Insights
- Stream Analytics Job
- Databricks
- HDInsight
- Blockchain Service
- DevOps Project
- Storage Account
- Data Lake Storage
- Search
- Front Door
- Container Registry
And when your done do the same for 3rd party Azure resources (very incomplete list):
- Bitnami Elastic Search
- Bitnami Kafka
- Bitnami LAMP
- SAP HANA
- Barracuda WAF
- Apache Solr
- Chef Automate
- Moodle
- Sitecore
Maintenance/abbreviation conclusion
This will never scale. It is impossible to come up with meaningful abbreviations for just a subset of the resources above, let alone scaling to more resources as they become used/needed in Azure.
Debunking naming conventions
Fact:
Resource groups can only be viewed under resource groups or in a table with an explicit “Resource group” header
Conclusion:
No need for suffix/prefix for name like “rgr-” or “-rg”.
Fact:
Resources with a public endpoint already have an FQDN which accurately describes what they are.
Examples:
| Resource type | Public endpoint |
|---|---|
| App Service (web/logic/function app) | name.azurewebsites.net |
| Traffic manager | name.trafficmanager.net |
| Storage account | name.blob.core.windows.net |
| Azure SQL | name.database.windows.net |
| Public IP (load balancer, VM, App Gateway etc.) | name.location.cloudapp.azure.com |
| Cosmos DB | name.documents.azure.com |
| Service Bus | name.servicebus.windows.net |
Conclusion:
No need for suffix/prefix for type like “web-” or “-db”.
Examples
Resource Groups
The screenshot below shows a list of resource groups in an Azure subscription. The table shows by default the resource type icon, name, subscription, and location of the resource group. Note that resource groups can be filtered on:
- Name
- Location
- Subscription
- Tags
Azure Portal Resource Groups View
Resource Group Conclusion
Adding confusion naming pre- or suffixes to a name will not in any way make a resource group easier to find.
Resources
The screenshot below shows a list of resources in an Azure subscription. The table shows by default the resource type icon, name, type, resource group, location, and subscription of the resource. Note that resources can be filtered on:
- Name
- Subscription
- Resource group
- Type
- Location
- Tags
Azure Portal Resources View
Resources Conclusion
Adding confusion naming pre- or suffixes to a name will not in any way make a resource easier to find.
Why a naming convention slows you down
While having a naming convention on a small team where everyone’s on board might work for you, having a company-wide naming convention will only confuse and irritate people. In my experience I have never seen a naming convention which has satisfied anyone but the three people who came up with it. Everyone else wants to change it so support their specific view of the world. Given that most people aren’t around forever it’s quite possible that the naming convention will be an invention of somebody who is no longer with the company.
Documentation
You need a way to document the naming convention which ensures people see it and follow it - and keep up to date with changes. This requires a lot of work.
Maintenance
If you - as most organizations do - land on a naming conventions fix pre- and suffixes for resource types, you will have to update this whenever there are new resource types being made available - and given the pace at which Microsoft adds features to Azure, this will at minimum be several times a year.
Talking, talking, talking
The worst part about having a naming convention is that no matter how many times you say it, people will think it’s up for debate. Chances are that only the few people who decided on the naming convention will appreciate it (and maybe not even them(!)) - the rest of the organization will most likely hate it and try to fight it or at least bicker about it whenever possible. This is a complete waste of everybody’s time.
Verification/Enforcement
When should a naming convention be verified/enforced? A number of options presents themselves:
- On create
- Scheduled checks
- Never (trust)
Ad 1: Requires custom software which can create any type of resource. No users can be allowed to create Azure resources through either the Portal, PowerShell or CLI.
This is clearly not ideal for a number of reasons:
- Severely limits peoples ability to create new Azure resources
- Huge development/maintenance task in creating yet another unnecessary custom tool
Ad 2: Requires custom software which can scan all Azure subscriptions and check for naming convention mismatches. This is maybe more appealing than (1) as Azure Automation can be used with a PowerShell script, however we would once again take upon us a development/maintenance task.
Ad 3: Requires nothing except we would have to educate/inform the developers.
This is not ideal either as we would have to spend a lot of time with each developer before giving them access to actually deploy stuff to Azure.
Verification/Enforcement summary
To make matters worse for any kind of enforcement/verification to work one would probably need a combination of all 3 above, i.e. limit creation to using specific tools with naming convention checks, Azure Automation scheduled verification, and training developers in naming before letting them loose.
Verification/Enforcement conclusion
All in all it does not seem feasible or worth it to even try to verify/enforce any kind of naming policy, which makes the whole premise of having one void.
Why not having a naming convention will speed you up
When individual teams are given the freedom to pick names they will not have to consult anyone to get started. With no naming convention there will also not be a naming convention which has changed, resulting in no need to retroactively change names which is mostly not possible in Azure (a resource must be deleted and recreated with the new name).
Finding a resource
Finding a resource by name – and thus determining its type, location, and resource group is very easy using either PowerShell:
Get-AzResource -Name <name> | Format-Table
or the Azure CLI:
az resource list --name <name> --output table
Having shorter meaningful names will also make running these commands a lot faster.
Solution
The solution to the naming convention problem has to be the tagging feature in Azure. All resources including resource groups can have a set of tags (key/value pairs) which contain required metadata information.
Naming vs. Tagging
Azure allows adding tags to all resources with the following limitations:
- At most 15 tags
- Tag name (key): 1-512 characters
- Tag value: 1-256 characters
Tags can be enforced on all resources using Azure Policy.
Tags can be used to filter/search/group resources both in the portal and in billing.
This allows to put all information which cannot be contained in a name into tags.
Required (optional?) tags
We suggest that all naming convention information is moved to tags:
| Tag | Example |
|---|---|
| Owner | user@domain.com |
| Environment | Production / Test / Development |
| Cost center | 123456 |
| Product | Company Web Site |
Conclusion
To conclude I truly believe that no naming convention should be required on any Azure resources except for the ones simple restrictions already enforced by Microsoft.
Here’s my suggested naming convention: Use meaningful names!
Only other limitation which should be blatantly obvious: No profanity or humor.
Instead a very limited set of tags should be enforced using Azure Policy.