Naming conventions for servers
The rant series of this blog will be incomplete if I wouldn't mention the naming conventions for servers, especially since I've never even seen a convention which would make at least some sense in any company.
The three prevailing naming conventions which are used in companies are:
A well-defined and documented pattern which made sense ten years ago when it was written by the system administrator who left the company eight years ago. Since then, nobody knows the location of the documentation and nobody really understands the convention, trying simply to guess it based on the actual names of servers.
Common sense works for a few things (
...-DB02should probably have something to do with databases), and fails for others (what is this
An often informal convention where names of planets, Greek gods or animals are used instead. Then, some persons don't understand why their Java apps are hosted on
Python014, while their Python apps are somewhere else.
A convention which consists of auto-incremented, random, or arbitrary chosen number which convey no information whatsoever. The funny thing is that it never corresponds to the IP, so instead of one meaningless thing (the IP address), we now have two, just to add a bit of complexity.
But couldn't we do better?
When discussing servers naming conventions with system administrators, they usually explain that at some stage of their career, they tried two things, and both failed:
Choosing meaningful names which correspond to the underlying service hosted by the server. So a server which hosts Microsoft SQL Server 2012 becomes
MSSQL2012-01and a server which hosts the SharePoint 2010 portal becomes
And then, the company moves from Microsoft SQL Server to Oracle Database and from SharePoint to some Java application, and names become completely awkward, but nobody dare change them, because nobody knows what could be the consequences and how many of those names are already hardcoded by developers in their code.
Choosing a good pattern which responds exactly to the current needs and makes it possible to have very clear and explicit names for 35 machines which are currently deployed.
Then, two years later, everyone blames the author of the convention for inventing something which is absolutely impossible to work with, now that the company is hosting 500 machines.
So they start using the names from Greek mythology, which, being completely meaningless from the beginning, remain meaningless forever, avoiding bad surprises later.
At Pelican Design & Development, we made a mistake of having a (overly) complex pattern used for naming both servers and end-user machines. Surprisingly, it worked well and remained valid for years (but we weren't scaling to thousands of servers either), but it had its flaws, such as the fact that the name contained the location (the name of the data center and the location within the data center). The major problem with the convention is that those long names were completely cryptic to any outsider (and frankly it was even cryptic to me, given that I documented the pattern.) I was sure we can do better. And better we did. When the opportunity came to move to Linux infrastructure, I decided to abandon any naming patterns and to keep it simple stupid.
Today, servers are named according to their role. Trust application, for instance, is hosted on, surprise, surprise,
trust-http-failover, the MongoDB database being on
trust-db-failover; would I migrate Trust to PostgreSQL, the machine name won't be affected. If you want to locate Iris service, you should be expecting it on servers which start by
iris. In the same way,
dns-dhcp hosts guess what? Right, our DNS and DHCP services.
We have some issues with the names, such as when it comes to giving descriptive names to developer machines. Currently, it's
dev2, etc., but this is just ugly, and I can never remember which machine is mine. Names such as
dev-arsene are wrong too, since a machine is not affected to a specific person. I start having a suspicion that there is no right answer for such cases, but any suggestion is welcome.
In general, I'm pretty sure everyone can do an effort when naming their servers in order to have meaningful, explicit names. So instead of
BAY7-STB25-R14, please name your primary Active Directory backup server
ldap-backup-primary, because frankly, nobody likes to work with
BAY7-STB25-R14 and nobody remembers what is hosted on
Poseidon, and I'm not even talking about
Artemis in the data closet (is it even online?)