One of the key tenets of Digital Transformation and moving to the cloud is the notion of scalability. Attention to the smallest and seemingly pedantic details will pay dividends when it comes time to spin up a bunch of new servers or cloud instances.
How Hard Could It Be?
Surprisingly, naming anything can be a matter of great deliberation. Our parents had this issue when we came into the world - does the child inherit a name of another family member or blaze a new trail with a unique name? The same careful planning and logic goes into naming hosts in your infrastructure.
There was a time when we just named our hosts random things like “knicknackpaddywack” and its counter part “giveadogabone” (thanks to one of our Customer Success Engineers, Isaac Onigman, who actually had two servers with these names for the example). These kinds of pet names can get a bit unwieldy and definitely don’t give someone who may be working with you any idea of what the machine actually does, where it’s located, or if there is only one or many of them.
Injecting Some Pragmatism Into The Naming Process
Naming a server in your infrastructure should follow some basic rules to ensure that you are set up for success in the future. Much like the DNS is represented as a tree for the sort of macro-Internet, a similar structure can be devised for laying out a naming structure that explains what a machine does, where it’s located, and which instance it represents.
Typically, for my own stuff, I want to know if a machine is production or development, what kind of service is running on the box, and where it is. When defining where a machine is, I will put a number after the IATA location code of the nearest airport to that datacenter - you never know when you may add more of the same box in that site.
Root zone --> | example.com. | |||
Server Type --> | prod. dev. | |||
Service --> | web. app. service. | |||
Location + Instance | bos1. bos2. lax1. lax2. | |||
In this example, I have two types of environments: production and development. There are three service types: web, app, and service. I have two locations: Boston and Los Angeles, which each have two identical machines. Now there is a hierarchy in place that allows me to name my resources with all of the pertinent information I need to know at a glance.
Ultimately, preference will play a big part in how you or your company decides to lay this all out but having a plan in place from the beginning never hurts.
Preparing For Scale + Redundancy
By sticking with a naming convention, the process of naming future machines becomes that much easier. As organizations grow, so does the stack that keeps those organizations up and running. Automation and containerization of services naturally benefits from this kind of organizational effort as machines are constantly being spun up or spun down depending on needs.