IT Infrastructure Nomenclature: Machine names

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Hussein Badakhchani's Blog | August 11, 2007   1:34 AM | Comments (0)

Those of you who read my last entry will know that I had started a debate with our Unix team in order to create a coherent set of naming conventions for our machines. I have worked in a lot places where little thought is given to the naming of infrastructure artifacts with predictable results.

The benefits of an enterprise wide nomenclature for infrastructure artifacts are manifold and include:

• All artefacts are named in an consistent and identifiable fashion.
• Enhanced clarity in cases of ambiguity. All stakeholders will be able to communicate information regarding the environments without risk of confusion.
• Avoids naming collisions.
• Simplifies the understanding of infrastructure architecture.
• Lays the foundations for automating infrastructure environment provisioning.
• Provides additional information, metadata, about the named artefact.

Encoding the correct metadata in the name of an artifact is the probably the most important step when creating your nomenclature. If you get this step right all the other benefits will follow, so take your time and make sure you include all the stakeholders in the requirements gathering process. Here are a few suggetions for metadata that you may decide to encode in a machine name:

• Programme or project identifier.
• Machine function.
• Environment identifier.
• Machine identifier.

For instance, say you have purchased six machines for a project code named "Ferdowsi". Each machine fullfils a function in your n-tier architecture so you have a Web server, application server and database server. These machines will be deployed to your test and production environments, lets look at one possible way of naming them. We will start by expressing our metadata in Backus-Naur form.

<Machine name>::=<Programme Id><Machine function><Environment Id><Machine ID>

<Programme ID>::="fr"

<Machine function>::=="ws"|"ap"|"db"

<Environment ID>::="1"|"2"

<Machine ID>:==<digit>

Lets describe the metadata in more detail as well as some of the constraints we want to place on them. The programme ID is two characters in length and idicates that these machines belong to the "Ferdowsi" project. If we had machines that were shared between programmes/projects we would drop this identifier from the machine name. Including the machine function in the name of the machine is a common and useful practice. Again we used a two length abbreviation of the full function name, so for Web server we derive "ws" and so on. The environment id is number that translates to environment to which the machine is deployed so. In our case 1="Production" and 2="Test". Finally the machine id is a digit assigned to identify the machines within there environments, so our machines are named as follows:

I don't want this entry to be interpreted as a prescriptive piece, I'm not telling you how to name your infrastrcture artifacts, rather it should help the reader to consider moving away from arbitrary naming practices and open possibilities for deriving the names of all the other artificates across the enterprise such as hostnames, file names for certificates, ketstores, logs, weblogic domain names, etc, etc.

Too many architects overlook nomenclature and as a result they inject and unhealthy dose of entropy into their systems. Finally with the nomeclature in place you can begin to automate the provisioning of your enterprise stack, from networks and operating system to applications.

Comments