I find that I always re-iterate how I name things. This is especially hard I think when naming functions when programing or servers when infrastructuring (if that was a valid verb).

But, I think I have found a rule of thumb now when it comes to servers. Isn't this super basic stuff?, you ask. And of course it is, but in my experience the basic things are some times hard to get right. And cumbersome to fix in the future.

And maybe for you it does not matter that much, perhaps you just have like 10 servers. But I argue that to have a good naming scheme is part of how you are able to scale when needed.

When you name a server you want the name to include just enough information. Enough so that when it turns up in a log or an alert you have enough information to act.

I try to include the following in a server name: * location, like data center or cluster * environment, like production or staging * type, like web server or reverse proxy * identification or counter number, like random characters or an iterated number

The above might not work for you and I might overlook something. But, this is what I've come up with as a start.

I like to have each part of the name to be about three of four characters joined with dashes. So, location-environment-type-identification.

If, heavens forbid, you have to run Windows Server you also need to account for the fact that you can't have more than 15 characters in the server name due to limitations from the 1980s. So, I simply chant “serenity now” and accept this fact. Then always name servers with 15 characters. No more, no less.

Why bother with a name convention

Lets say you have a centralized logging solution and all logs are sent to that. And lets say you have 5 servers running the same web server. If all servers are named something “web” and perhaps even with an iteration like “web-01” you might be good for a while, but what if these servers resides in different parts of your infrastructure. Then, the logs are not telling the full picture.

If the name includes some tidbits about what it is (or serve), where it is and who it is you can build better automation and alerts with the server name as a key. Another example of why it is good to have a naming convention is that if perhaps one location has an issue, you will immediately see that pattern emerge in the logs and alerts.

Location

The location might be the actual host where an instance is located. But, in this context I'm thinking more of an infrastructure where you work with different availability zones and data centers. And if you also deploy your work loads at different providers the data centers and availability zones of course differs.

So, either you include the name of the provider and datacenter in the location. Or you create your own locations that are pointers to the so to speak real locations.

As an example, if I use Safespring as a provider and I create a server in one of their three datacenters, lets say Stockholm South. How would I abbreviate this into the location part of the name?

Well, “Safespring Stockholm South”, could be abbreviated. However, the amount of the letter “s” makes this hard. A usual way to abbreviate is to choose the first letter or letters of the words. In this case it would result in “SSSS”. And, how do I protect against a name change? As an example a couple of years ago City Network change their name to Cleura. What if Safespring re-brands in the future?

So, I argue that we need to create our own namespace for the location of our servers.

Let's assume we use two datacenters at Safespring and one from Cleura. We could simply create our own of location names like this: * DC01, Safespring Stockholm South * DC02, Safespring Stockholm North * DC03, Cleura Karlskrona

Or of course instead abbreviate location like with an L or Loc: * LOC01, Safespring Stockholm South * LOC02, Safespring Stockholm North * LOC03, Cleura Karlskrona

However, I really do like it when each part of a name has a length of three or four. So, I would choose to use the “DC01” or “L01” to save on length. Also, if you want to include locations that are not a physical location like a datacenter but instead maybe a cluster, I would use the “L01” abbreviation since “DC” implies datacenter. Perhaps even L001 to allow for 999 locations. But, I think that 99 locations are enough for most.

This makes it possible to include location in the name of a server or service in a scalable way.

Environment

It is necessary to include the environment that the server is part of. The obvious reason is of course that it would become quite easy to make terrible mistakes otherwise. Like shutting down the wrong server because you thought it was just a development environment server.

So, as with location, you should create a name convention. Two common environment types are staging and production. These could be abbreviated to s and p to keep it short.

Given the example for location names we could name a server dc01-p to mean “Safespring Stockholm South production environment”.

It might be hard to only allow one character for the environment, but I think it is a good practice. Then we can use more characters for the type part of our name when needed and still keep the 15 character limit for Windows Server.

I mean, p could be production, s staging, d could med dmz and so on. One just have to decide which letter will represent each type of environment one has.

Type

The type of server can also be tricky. One quick way is to set the type based on the service running on the server. If it is a web server running on it call the type “web”.

RabbitMQ could become “rmq” and Apache Airflow could become “airflow”. But that is too long in my opinion and does not have a given three or four character abbreviation.

So again, we need to come up with a nomenclature that fits our use case. Web and SQL database servers are quite easy to choose type name for.

RabbitMQ could also be shortened “msq” for message queue. And Apache Airflow could be shortened to flow or batch (since it is a batch workflow kind of service). As long as we keep the rule to three characters when dealing with Windows Server we can allow us to be more creative with the type nomenclature when needed.

What you really need to consider is to perhaps not mix names of a particular brand of a service with what the service is providing. Because, applications rebrand at times too. And RabbitMQ it is a message queue application, but there are others like it too. If we let the type be less about the brand name and more about what type of service we are using we improve the agility of the server name convention we build.

Identification or iteration

I tend to like the iteration number at the end because it is easy to verbalize which server you are talking about with team members. But, you run into the risk of duplicated names and using the same number on different types of servers. There might be a “sql-001” and a “web-001”. Or a “p-web-001” for a production server and “s-web-001” for a staging server.

When I create servers with OpenTofu or Terraform I use the https://search.opentofu.org/provider/hashicorp/random/latest to generate a UUID for the server I'm creating. I push this UUID as an environment variable to the server as well. It can be used to verify your records of what servers you have created. Not at all as an identity of the server but as a simple way of checking your records.

A UUID is made up of five parts separated by a dash, like so: 38f25e0a-23d4-4b02-8d8a-4d666ee05c08. I use the second part as the identifier. Since UUIDs are very, very unique a reckon it is very unlikely that these four characters will ever be the same for the servers I create.

The reason to use UUID parts is that it is quite natural to verbalize 23d4. You can say “twenty three dee four”, or “dee four” for short. If the full server name is dc01-p-web-23d4 you could say “we have an issue with web server twenty three dee four” or “we have an issue with our production web server dee four” and everyone would have little to no trouble to grasp which server you are talking about even in a crappy MS Teams meeting.

A unique identifier opposed to a iteration number makes it easy to search for the server in internal ledgers or when searching through metric or log management systems.

Conclusion

So, there you have it. A lot of words about naming servers. My server name would end up something like this for a web server: lo01-p-web-23d4

and for an configuration management tool like Ansible, I could name the controller server: lo02-m-cfg-f2j2 or perhaps even lo02-m-ansible-f2j2 since it is running on Linux and I could expense with the longer name.

Also, one can opt to simply use omit the “lo” from “lo02” of course and just treat the first part of a name as the location and thus save two more characters. So, it could become 02-m-ansible-f2j2. It is more a question of readability in this case.

This is simply my take on this matter. This is not the only way to name servers and I am probably missing some thing that I should think about when naming servers. However, that is normal because this is an iterative process. As is most processes.

If you have any questions or want to comment on this, you'll find me on Mastodon with the handle jdurehed

Joakim Durehed