My Authors
Read all threads
✊An opinionated thread about designing your #Cloud #datacentre — Principles for a clear and obvious Naming Convention 👇

I am planning to run a series about cloud design. Follow me for more 😍

Feedback & suggestions are very welcome. Please comment & share the wealth via RT 👍
Thoughts here are not specific to #OCI and can be applied to any #Cloud or on-premise #infrastructure to some extent.
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 myself 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 your core ops squad, but you will 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 thinking 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 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: 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.

🎁 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, just put some tags on it. That’s where you want your metadata, *not embedded on the name*: `“Desk1: grey, room 5, bought in 2020, used by John Doe”` 🆚 `DESK1WH20R5JDO`.
Usual pushbacks are all variations from:
- «I do some magic filtering on the name & 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 platform) 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 are 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 organization’s structure.
5️⃣ Put any other information in Tags!
Missing some Tweet in this thread? You can try to force a refresh.

Enjoying this thread?

Keep Current with Çetin Ardal

Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!