IT Infrastructure Nomenclature: Environment names

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Hussein Badakhchani's Blog | August 30, 2007   9:26 PM | Comments (2)

Building on my last blog on nomenclature I want to discuss the naming of environments. By an environment I mean all the infrastructure that belongs to a functional group of a project, for instance the User Acceptance Test environment or the Production environment.

A typical enterprise stack may consist of a Web Server, WebLogic server, perhaps a Digital Signature Messaging System or some Message Oriented Middleware like MQ and a database. Lets assume for simplicity that our environments have dedicated stacks, so my Functional Test environment is not sharing it's database or any other infrastructure with my User Acceptance Test environment. What are the options for naming my environment? Well you could just give it an arbitrary name based on an abbreviation of it's function and number to keep it unique. This is a fairly common practice and we end up with names like UAT01 and PRD01. Such a naming scheme is perfectly fine if you have a single project and you don't reuse the environment for other projects but what if you have multiple projects and multiple environments, what problems can you expect with your basic naming scheme?

Well for a start there is no way of telling which environments belong to which projects from the name alone, "So what," you might think and as you're probably a miserable developer, who has lived inside an enclipse shell for the last couple of years producing very buggy code, your limited vision is unsurprising. Lets demonstrate the cost to the project whith this simple dialogue:

• Support Caller: Can we change the apache configuration for the Micky Mouse project.
• Support Engineer: Erm, ok what environment are you talking about?
• Support Caller: The test environment.
• Support Engineer: Which test environment, Functional Test or UAT?
• Support Caller: Functional Test.
• Support Engineer: We have 10 FT environments which one?
• Support Caller: Erm, I'll get back to you on that.

Ok, this example maybe a little contrived and you're probably thinking why doesn't the defect tracker/ticketing system have all this information in it but it is a real scenario and a common one in meduim sized businesses. The point is we haven't considered encoding the project name as metadata in the environment name and this piece of information is a key requirement not just for the support team but for anyone in the project that uses the environments.

As with naming your machines the first step in naming your environments is to identify your metadata requirements. In a recent exercise for one client we agreed on the following requirements:

1. The function of the environment should be present as a two character abbreviation e.g pd = Production, ft=Functional Test, ut = User Acceptance Test.
2. All environments that belong to the "Hafez" programme will be identified by the numeral 1.
3. The two projects in the Hafez programme, "Enterprise security" and "Processing engine" will be identified by the numerals 1 and 2 respectively.

We can express these requirements in Backus-Naur form:

<Environment Name> ::= <Environment Function><Programme ID><Project ID>
<Environment Function> ::= "FT" | "UT" | "PD"
<Programme ID> ::= "1"
<Project ID> ::= "1" | "2"

These basic rules allowed us to name all the environments for the programme consistently, uniquely and in and easily identifiable fashion, for instance PD12 is the production environment for the processing engine project which is part of the Hafez programme.

While an environment naming convention is useful it really becomes poweful when we start to derive the names of key infrastructure artificates from our environment names. Lets list some of these artefacts and their derived names, we will stick with WebLogic artefacts for now. You may want to try wrtiting out the general rule for each artefact in Backus-naur form for yourself:

As you can see we have now consistently named listen addresses (hostnames), key stores and key aliases all from our environment name. Anyone can work out the name of the admin server for a given enironment based on our nomeclature. If you want to inspect the identity key you know what it's alias should be. We can also derive names for database schemas, unix users and host of other infrastructure artefacts from the seed name, the environment name.

The benefits of a well thought out nomenclature are numerous and include:

1. Simplifies environment proving and automated validation of environments.
2. Simplifies the task of communicating and understanding the infrastructure architecture.
3. Maintains naming consistency across the programme.
4. Quicker creation of standardised specifications for new environments.
5. Facilitates automation of environment provisioning.

The last two points are where my interests lie, but if your going around touting yourself as an I.T Architect, I.T Technologist, I.T Architectural Technologist, guru, software imagineer, system-medic, Creative Management I.T Dude or some other exotic, bogus job title you should consider all the benefits before making up that random naming scheme on the plane back from some dodgy industry do or in a 10 minute teleconference with the offshore development team.

Comments

• Hoos: I had a similar dialog with one of the developers for a weblogic domain and I had to log on to 2 different weblogic domains to find out which environment the developer is talking about. So having some sort of naming convention should improve the situation...

  Posted by: lalitkumar.dandekar on September 4, 2007 at 3:33 AM

• Lalit, another common scenario is this one:

  Support Caller 1: Can we change the Apache configuration for the Micky mouse project on uat. Support Engineer 1: Sure, done Support Caller 2: We are having problems on UAT03, we can't reach the application. Support Engineer 2: Support Engineer 1 which UAT environment did you update? Support Engineer 1: Erm UAT.....

  You are right of course, for the nomeclature to be of any use all stake holders must be aware of it and of the environements they are using.

  Posted by: hoos on September 4, 2007 at 5:12 AM