There are only two hard things in Computer Science: cache invalidation and naming things.

– Phil Karlton

Coming up with a consistent naming scheme that makes it easy to identify a given service or piece of hardware is difficult, more so when you want to include the providr of the server as well. Having read a range of blog and forum posts alongside the Microsoft Azure resource naming docs (see references at the end) I’ve come up with the following naming scheme that will allow me to easily identify anything within my home and cloud lab environments.

<purpose>-<numeric_identifier>.<location>.<provider>.<domain>

Modifying this slighting to include the ‘environment’ allows us to define domain names for services before they are assigned a friendly or helper name.

<service>-<numeric_identifier>.<environment>.<location>.<provider>.<domain>

As you can see from both of these templates they are driven by the concept of suffixes that cover the key pieces of information it is useful to highlight about a service alongside a prefix that identifies the specific equipment or service.

The <domain> suffix identifies the organisation that the entity is contained within this could be homelab.gdn or in the case of my lab technerd.cloud. I’d recommend registering a domain name through a registrar for your environment, you don’t have to register any externally available services but it will make configuring anything you want a lot simpler.

The <numeric_identifier> is an incrementing counter generally 2 digits 01 that identifies the specific instance of the purposed hardware.

Provider

Provider of the hardware or service, generally is one of cloud, colocation or on-premise.

Suffix	Description
aws	Amazon Web Services
gcp	Google Cloud Platform
azure	Microsoft Azure
oci	Oracle Cloud Infrastructure
do	Digital Ocean
home	Home
lab	Lab
core	Core Network (inc inter-site)

Location

Geographical region or country the service is in, for cloud providers this is their region.

For any infrastructure that is within my lab/home/core providers then this is based on the UN/LOCODE for the given country and location with an incrementing number following this for a given site within that location (this allows for multiple and expansion/testing), i.e. a site in London, UK the location would be gb-lon-1.

Services within other providers infrastructure or platforms use their region identifier as the location i.e. a service in the AWS eu-west-1 region would have the location as eu-west-1.

Environment

Environment the hardware or service is deployed in (mainly only relevant of services).

Suffix	Description
dev	Development
tst	Testing
stg	Staging
prd	Production

Purpose

The purpose of the physical / virtual hardware useful to quickly identify what the hardware is. Whilst this table includes purposes that are 3 characters in length I have no hard max length and just use what makes sense for the given hardware or service.

Note: This is not an exhaustive list of purposes and highlights some of the core ones that i’ve been using at the start of the lab setup.

Suffix	Description
rtr	Router (physical or virtual)
sw	Switch
esx	ESX Virtualisation Host
dns	Domain Name Server
lb	Load Balancer
pdu	Power Distribution Unit
ups	Uninterruptible Power Supply
web	Web Server

Examples

The following table contains a set of examples that identify a range of physical, virtual hardware and services and how their full DNS name is generated.

Record	Description
rtr-01.gb-lon-1.core.technerd.cloud	Router 01 in the GB London 1 site as part of the core network
rtr-01.nl-ams-1.core.technerd.cloud	Router 01 in the Netherlands Amsterdam1 site as part of the core network
sw-01.gb-lon-1.home.technerd.cloud	Switch 01 in the GB London 1 site as part of the home network
esx-10.gb-lon-1.lab.technerd.cloud	ESX Virtualisation host 10 in the GB London 1 site as part of the lab network
dns-01.gb-lon-2.lab.technerd.cloud	DNS 02 server in the GB London 2 site as part of the lab network
web-02.prd.eu-west-1.aws.technerd.cloud	Web 02 server in the production environment hosted in the eu-west-1 region of AWS
web-01.stg.eu-west-1.aws.technerd.cloud	Web 01 server in the staging environment hosted in the eu-west-1 region of AWS

References

• https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming
• https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-abbreviations
• https://mnx.io/blog/a-proper-server-naming-scheme/
• https://unece.org/trade/cefact/unlocode-code-list-country-and-territory