Argh, I have to Name it?!

One of the least enjoyable activities on any project is coming up with names. There are two camps on this topic: those who throw caution to the wind and just do whatever and those who obsess over if the name is exactly perfect – there’s little middle ground. When it comes to Azure, this gets even worse – resource names have various and inconsistent restrictions with respect to length and allowed characters – it seems Microsoft was in the former camp. Actually, there are some good technical reasons for the inconsistency in certain situations, but nonetheless it culminates in an internally inconsistent standard when you try to implement one yourself. You’d think at this point in our computing lives we’d be well past having arbitrary restrictions on names, but then again – when did we get real(ish) long path support in Windows?

When coming up with a standard for your organization or project, here are a few goals to consider or questions your overall approach should address:

  • How do we know what environment it’s in?
  • How do we know where it’s physically located?
  • How do we know which instance number it is, in a multi-instanced scenario (e.g. members of a cluster)?
  • How do we know what project or product this is for?
  • How do we know what business unit / company this is for (more applicable for larger orgs)?
  • How can we provide global uniqueness, when required?
  • How can it be consistent?
  • How do we know what this thing is actually doing?! – This is the important one!

With that list in mind, I highly recommend focusing on the last bullet. There are ways to address most of the others without consuming characters in the name. Let’s consider a few strategies which ultimately are going to boil down to how you manage your subscriptions.

Some Common Approaches

Encoding Lookup / Redundant Data

This approach uses a coding to shorten information and provide global uniqueness. It could look like {Component}[{InstanceNumber}]{ResourceTypeCode}{ProductCode}{EnvironmentCode}{RegionCode}. As an example, a name like usercontentstg0F01FF. This is breaks down to: Component = user  content, Instance Number = N/A, Resource Type Code – stg for storage account, Product code, 0F for “My Awesome Product”, 01 for the development environment and FF for Australia East.

In and of itself, this name is pretty useless if you take it on face value, however consider that the environment and product are present in the subscription name.  We could simply toss them, but there’s that global uniqueness problem. This approach comes with the benefit of reserving a good portion of the name for the intent or purpose at the cost of readability. You can also save characters by encoding the resource type since that information is plainly visible in the portal as well.

Works Well In:  Highly structured subscription / resource group layouts where the organization of each is largely in line with Microsoft’s naming convention.

Randomized Suffix

This method focuses entirely on the resource purpose and randomizes the tail of the name to provide the required uniqueness, e.g. {Purpose}{RandomString}. For example a name like “usercontentA81F” would be some type of resource that deals with user generated content. Again, you’re relying in the subscription name and tags to provide any additional data while focusing on the intent in the name and using an arbitrary mechanism to provide global uniqueness. The characteristics of this approach are similar to the prior, however even more space is provided for the resource purpose since the random string can be fixed length.

Works Well In:  Highly structured subscription / resource group layouts where the organization of each is largely in line with Microsoft’s naming convention.

Short Codes

This scheme utilizes abbreviations or short codes to provide relevant information about the resource as well as provide global uniqueness. This is basically the approach taken in an older post from Ronnie Hegelund. While this does make things very readable, it comes at the cost of 1.) internal inconsistency (some resources are character set constrained) 2.) little space for the purpose. So to riff on the aforementioned post which poses {Environment}-{Purpose}-{component}-{geographic zone}-{datacenter}-{company}-{service}  as the scheme, let’s revise it to {purpose}-{component}[{instancenumber}]–{service}-{environment}-{region}.

Consider the example myapp-mycoolsvc-appsvc-p-usw2 which is an app service for “my cool service” within the “myapp” product running in US West 2 and in the production environment. I changed around the original format so that the region is the general region abbreviation rather than wasting an extra character to separate out the zone from the data center. I also tacked on the instance number – this usually becomes important in IaaS scenarios.

While this approach is by far the most human consumable, it comes with some drawbacks of its own. First, it results in names that are typically too long – storage accounts, VMs and a few other resource types have absurdly short names (14-24 characters) and this makes the useful part of the name exceptionally short. Secondly, it becomes internally inconsistent when we deal with things like storage accounts, which can’t use hyphens. Personally, I think the hyphens are just a waste of space so consider dropping them from the start. Secondly, how do we address the length problem? Well, that gets us back to the subscription and resource group layout. If they provide a lot of the information such as the environment, name of the app, etc. there’s really not any purpose in including it in the resource name aside from making it globally unique which there are other ways to accomplish.

Works Well In: Environments where the subscriptions are larger in scope, such as a subscription per environment across the organization or even a single subscription throughout the organization.

 

The Stuff That’s Actually Useful

Of course all the good stuff is at the bottom! Instead of coming up with every possible permutation of naming conventions, why not use a spreadsheet?! I’ve created a sheet you can use to experiment with naming approaches you can download and play with on your own. There are a few caveats which are outlined in the readme but it’s a good basis to start with so you can come up with a solution that works for your organization.

 

 

About The Author

Leave a Reply

Your email address will not be published.