DevOps: Naming Standards

Get this right early on and make your life easier.

One of the most important things you must get right in your organisation early on is your naming standards. As soon as you start creating infrastructure resources in your company, establish a naming standard and stick with it. This should apply to everything; your server names, microservices, security groups, vpc names, Jenkins job names, repositories, folder structure, etc. Before you create any resource have a naming standard for it, put it on a document and refer to it like a priest to a bible — Make sure everyone knows of its existence and make sure that they never create or automate anything without consulting it first.

There are many reasons why you want to do this but the most important is that if you have standards in place, then you can easily create solutions that apply to your entire company very easily.

A good analogy would be roads and cars. Most cars are not created to run in every terrain, we have roads where the cars can run smoothly and we have standards for what signs mean and rules that everyone can follow, otherwise devising a driving plan would be very difficult and chaotic.

In regards to your infrastructure, let’s just say for the sake of argument that you have to apply a change to all your twenty development servers. Now let’s say that all of them have a naming standard like this:

“name-dev”

Automating for the above is very easy, all you have to do is create a script that looks for all instances of *.-dev

Now let’s say that you didn’t establish a naming standard beforehand or you kind of did, but you didn’t make anyone aware of it and now you have something like this:

5 servers are named “dev-name”

5 servers are named “name-development”

10 servers are named “development-name”

Now you need to create a script that accounts for three possibilities, and since you haven’t established a standard yet, then maybe in the future you need to change your script for even more variation, this creates technical debt.

Searching for what is dev and what is not also becomes more difficult because you have to account for three distinct possibilities. Sure, you could solve this with complex and wacky regex, but then you are accommodating for chaos, which is not what you should aim for as it would mean you have to constantly update the script to account for changes.

Automation is a lot simpler and easier when you are dealing with predictable scenarios. You are responsible to create as much predictability as possible before you begin automating, otherwise you will pay the price in technical debt, time and confusion.

The best way to achieve this is with naming standards. You want an infrastructure that follows rules and deterministic naming, and most importantly you want everyone in the company to know where to find these standards and apply their own if needed.

These standards can be improved over the time, but the sooner the better, the more resources you name with the wrong standard, the more difficult it will be to change down the line.

How to effectively implement naming standards

Your naming standards should aim to satisfy the following:

1. Ease identifying the purpose, location and objective of the resource being named.
2. Ease the task of automating.
3. Eliminate, or vastly reduce the time that people invest in coming up with ways to name something — creative juices shouldn’t have to flow again and again to the same task — especially without improving on previous iterations.
4. Help categorising, itemising and finding resources in your company.

Ideas for Naming Resources

• At its most basic level resources should be “name-category”, for example for a server named phoenix in development environment you would call it phoenix-dev. You could have more than one category in the name, but always add the categories at the beginning or at the end, following always the same order and exactly the same naming style of the category. Any idiosyncratic variation (the name of the resource) should ideally be on either side, not in the middle.
• Resources that are logically grouped under a folder do not always need to include the category in the naming. So for example if you have a folder named dev and another one named production, you may not need to call the contents dev-filename.extension as the folder itself already accounts for that.
• Don’t add anything redundant to the name, for example if you work for company acme you don’t need to add acme to the name of every file you create in a folder or to every repository you create.
• If you need to add a second resource that shares the naming, add the number for this resource in the naming part, not in the environment type. So for example let’s say that you have server phoenix-dev and you want to add a second server with the same name, it is far better you call it phoenix2-dev than calling it phoenix-dev2. Anything that denotes category in a naming convention should never be altered in any way.
• If you come across a naming convention that is cumbersome to automate or doesn’t work so well to identify resources take steps to change it this very moment, the longer you take the more difficult it will be to change.
• Don’t adapt automation to a chaotic infrastructure that has no clear naming standards. Instead work to change your infrastructure to adopt naming standards as far as it is feasible to do so, even if it’s painful and time consuming at first, you will appreciate it down the line (or at least someone else will)
• Use logical groups, teams, projects or directories available in the tool where the resources are created effectively. Have standards for logically arranging repositories, jenkins jobs, tagging resources, etc.
• Have a tagging strategy for your resources and cloud provider.

Some Resources with Examples

AWS Tagging Strategies - AWS Answers

https://confluence.huit.harvard.edu/display/CLA/Cloud+Resource+Naming+Conventions