Host Name naming conventions

​The first rule of naming conventions is that there isn't, nor will there ever be, a single best way to define a host name. The best you can do it to pick a standard that seems to work for your particular situation and stick with it for as long as it is useful.

The ideal host name provides just enough information to help identify the device but not so much information that the name limits the flexibility to accommodate future requirements.

The ideal host name provides just enough information to help identify the device but not so much information that the name limits the flexibility to accommodate future requirements. It is a [standard industry practice](http://www.ibm.com/developerworks/aix/library/au-name_standards/) to overload the name of a server with many specific physical details. However, as the role of a server or a network device becomes more ephemeral, overloading a hostname with things like physical location, whether it is a virtual or physical device, or even ownership can become a problem in the future.

An industry standard
Here is one suggested standard from IBM.

Node Name Component	Number of Characters	Example Values
Location Code	3	bos = Boston dal = Dallas phx = Phoenix
OS Type	1	a = AIX l = Linux o = OS/400 v = VIO Server w= Microsoft® Windows®
Environment	1	a = Acceptance Testing d = Development p = Production t = Testing x = Disaster Recovery
Application Code	3	vio = VIO Server nim = NIM Server sap = SAP mqs = MQ Series ora = Oracle db2 = DB2 ifx = Informix
Sequence ID	2	A two-character identifier to distinguish multiple instances of a node type. This two-character identifier may contain the following characters: 0-9, A-Z, a-z

dtwldora05.ibm.com would represent node 5 of an Oracle database, being used for development, running on linux, in Detroit.
This looks like a pretty good standard but it could be improved. Let’s consider a couple of these situations.

Q: What happens if the server is retired and the application is moved to Google Compute Engine?
A: It’s a new server and therefore would get a new host name.
​
Discussion: This is a correct answer but you need to ask yourself what was the purpose of including the location code? Typically, this is to provide some hint to the physical location of the device. This matters to the operations team but does it matter to the end user? If you shift focus to the actual consumer, specifying city level granularity might be too restrictive. I think Amazon zones are a good example of the level of granularity we need to be considering. Thinking in terms of regional geography is more important than identifying specific locations. Therefore, tracking regional geography may be sufficient. 

Q: What benefit is there in tracking OS Type?
A: It helps the operations team easily identify the operating system and therefore know the skills needed to administer the machine.

Discussion: Again, a good answer if your environment consists of many operating systems. However, if there is a standardization on a particular type of OS (e.g., Linux) this doesn’t add much value. The case could be made that if you switch a server from Windows to Linux, you have a different server and therefore need a new host name. Correct, but does the OS really matter to the end user? I would argue that it may be time to switch to a Host Type designation.
Shifting the focus from OS to Host Type provides a more accurate and flexible reflection of what the device does. For a physical server the following might apply:

p = Bare metal server
v = Virtual host (bare metal + hypervisor)
c = Container host (bare metal + container engine)
g = Guest image (OS image running on a VM or Container)
n = Network device (bare metal + networking software) 

Q: What benefit is there in tracking Application Type?
A: It is important to know the application role of a server for the same reason you need to know the OS. It helps to identify the skills needed to fix any issues.
Discussion: Here I would argue for maintaining the flexibility to change the purpose of the server or the applications running on the server without having to change the host name. The same can be said for production status. It isn’t uncommon for a staging server to be pushed into a production role pre for a development server to be moved into staging. Therefore, I think you could eliminate both the Application Code and Environment from the host name definition.
Remember, this discussion is about the device host name. Application DNS names are a different matter. These additional names for a device are simply aliases and they should be more descriptive, especially if you are implementing DNS based application discovery.

Initial Recommendation

Node Name Component	Number of Characters	Example Values
Geographic Code	2	us = USA, la = Latin America, eu = Europe, ch = China
Host Type	1	p = Bare metal server, v = Virtual host, c = Container host, g = Guest image, n = Network device
Sequence ID	4	A random four-character identifier to distinguish multiple instances of a device. This four-character identifier may contain the following easy to distinguish characters: [abcdfghjkmnprstvwxyz] and [0-9].

Examples

Host Name	Description
uspxa9s.migratory.io	Bare metal server xa9s serving the US region.
usg7xrh.migratory.io	Guest image 7xrh serving the US region.
usntfy30.migratory.io	Network device tfy30 serving the US region.

Conclusion
Seven characters leaves a lot of ambiguity! This is by design. Computers are general use tools and should be treated that way. By maintaining the flexibility to repurpose and device for nearly any purpose as needed, you give yourself flexibility to meet changing requirements without having to resort to complicated migration projects. Need to stand up a new server? You only need to know the region it is supporting and its general role. I suppose that as more and more environments migrate to being completely defined by software running on standardized commodity hardware the only necessary information might be the geography and a random unique identifier.

So where does this leave all of other important information about a device? This is best stored and managed in some type of Configuration Management System tied to your Continuous Deployment infrastructure.

Second thoughts
What would the simplest, most flexible, but still useful host name scheme look like?

Node Name Component	Number of Characters	Example Values
Geographic Code	2	us = USA, LA = Latin America, EU = Europe, CH = China
Sequence ID	5	A random five-character identifier to distinguish multiple instances of a device. This five-character identifier may contain the following easy to distinguish characters: [abcdfghjkmnprstvwxyz] and [0-9].

Examples

Host Name	Description
us1z527.migratory.io	Bare metal server 1z527 serving the US region. Running MySQL.
us1z527.migratory.io	Docker container 1z527 serving the US region. Running MySQL.
us1z527.migratory.io	Docker container 1z527 serving the US region. Running Crate.

​Three server migrations to very different platforms but still maintaining the same host name. At the end of the day, you have a computer doing some work. What it looks like, where it is installed, and the specific applications it utilizes don't really matter.

Permutations on a 5 character string made up of 30 possible characters = 17,100,720 unique possibilities 
4 char = 657,720 
3 char = 24,360  
2 char = 870  

You could simplify even further if you wanted but 5 characters are easy to remember and give plenty of headroom to grow.

Example code
The following code snippet could be used to dynamically create a hostname at the time a system image is being created.

Test Code
$ GEO=$"us" && OLD=$HOSTNAME && SEQ=$(cat /dev/urandom | tr -cd 'a-hj-np-z1-9' | head -c 5) && echo $HOSTNAME " => " $GEO$SEQ
Returns: ubuntu => usyfvds

Implementation
​$ GEO=$"us" && OLD=$HOSTNAME && SEQ=$(cat /dev/urandom | tr -cd 'a-hj-np-z1-9' | head -c 5) && sudo sed -i "s/$OLD/$GEO$SEQ/" /etc/hostname && sudo sed -i "s/$OLD/$GEO$SEQ/g" /etc/hosts && sudo reboot