Principles for a clear and obvious Naming Convention

On the Resources Naming Conventions in Enterprise IT

When (1)Naming, (2)Filing and (3)labeling are done right for your resources, we can assume that you have a well defined environment. The problem is to agree upon what “done right” is.

For (2)Filing and (3)labeling, your platform will generally propose you some tools to help. You still have to decide how you use them, but the feature’s design will probably suggest some pattern.

In OCI, there is Compartments & Tags👌and we will discuss about some ideas to make the best use of them later.

But for (1)naming, that’s up to you to decide about your strategy: cryptic IT naming convention can ruin all the benefits of a careful filling and labeling strategy ❌

Let’s talk about our naming practices in IT.

At some point in his career, any ops people have named the servers after planets ☄️, greek gods 🔱⚡️or superheroes 🦸‍♀️ 🦸‍♂️ names, sometimes a mix of all of the above. I am guilty of still administrating the town of Springfield and the Simpsons characters in my home network. 😅

And I am sure there is more than one system administrator that named all the servers after the Game of Thrones characters names.

It may be fun and cristal clear for you and your core ops squad, but you eventually acknowledge that a marvel theme for your servers was not the best idea, when the new team member reboot Hulk in the middle of the day genuinely thinking that this server was just a random lab experimentation👌. That’s correct in some ways, Hulk is just an experimentation that gone out of control. But this non-sense ends up written in a post mortem report, eventually read by the boss of your boss. 🤦🏻‍♂️

Explaining this post mortem to a pointy haired boss have the potential for a great Dilbert strip 😂

The opposite behavior is to overreact with too much codification. That’s how you end up with server names like this: OSGTNA1S2, VFRI23OPR003

‪Still nobody have a clue at first sight about what these resources are and what they do, unless you already practice these names for some time. At best there is little difference from the planet names, and you probably go back and forth to the CMDB (if you happen to have one up-to-date).

🎁 Bonus: you wasted 10 man-days to produce the initial naming convention proposal, endured a fair number of meetings and email chains to have everybody agreed upon it. Yet, every new service addition represent a major challenge to find the trigram that will fit with the whole. 🤦‍♀️

🙅🏻‍♂️ Enough. You probably don’t need a naming convention that takes 4 hours to read, 4 weeks to master and generates names that can be used as an RSA private key. Not for naming cloud logical objects at least.

This actual “art” of naming conventions is a legacy of constraints that are mainly not relevant anymore, certainly not when working with cloud logical object :

• there was no easy way to attach metadata directly on a resource, so we tried to codify it in the name,
• restriction on allowed character type and number, prevented plain words usage.

Your resource name is not your metadata store anymore, you have tags for that.

Why not calling your first desk, just “desk1”? 🤔— That’s much more descriptive. If you need more context about this desk, just put some tags on it. That’s where you want your metadata, not embedded on the name of the resource: “Desk1: grey, room 5, bought in 2020, used by John Doe” 🆚 DESK1WH20R5JDO.

Usual pushbacks are all variations from the following three:

• « I do some magic filtering on the name and perform operations using grep, awk, cut & sed »
• «I need that precise codification to speed my troubleshooting process.»
• « I want to know everything about the resource just by reading its name »

Let’s be pragmatic and adopt a middle ground position between OVNDE13PR1 and VCN1.

It is ok to have some descriptive elements in the name of a resource, but there is no need to over-codify everything in it: you will actually loose in clarity.

Modern CMP (cloud management platforms) do not rely on resources name: a universal unique identifier is used for references (uuid), and the display name becomes just another metadata element.

With current cloud technologies, the display name property often don’t have to be unique across the entire platform and have room for long naming. 50 chars is pretty common, with some solution allowing up to 255 chars.

Here is some principles for a clear and obvious naming convention, to eventually solve (1)naming:

1️⃣ Define clearly the lingo related to your technology stack, the acronyms you use for objects, features and concepts,
2️⃣ Simply name the resource after its purpose, in plain word,
3️⃣ Add naming-segments in the resource name for information related to the resource purpose, with terms from your lingo
4️⃣ When possible, enforce the resource context with a filing structure that represent your organisation’s structure.
5️⃣ Put any other information in Tags!