When you’re managing multiple server in multiple region for multiple application with multiple cloud vendors, it’s difficult to keep tract on what’s happening where. In my company, an amazing convention is followed. Being curious, I searched how rest of the world is doing it and got some amazing ideas from the folks who manage hundreds of instances in AWS/Azure. A good started point would be this article in wikipedia.
Managing servers have 2 aspect: You know the nitty-gritty details of the server (e.g. manually created AWS EC2 instance) so you treat them as pet. Or, you just know that you have bunch of servers that do the same thing (e.g. servers created during autoscaling) or different things for microservices (e.g. containers in kubernetes), so you’re managing them as cattle. You can name your pets, but you can’t name every cow in cattle. So, you need to have separate way of dealing with names. Consequently, I settled to the following convention:
<location>-<machine-type>-<focus>-<NN>-<deployment-type>[-tagname], where each of them may have any of the following values:
- Location: nearest airport of the datacenter/server where it’s located. It must be a valid 3 digit IATA code (heavily inspired by CloudFlare)
- Machine type: 1 digit code for personal devices, 2~3 digit code for servers, 4 digit for server-groups. This gives us the opportunity to align user devices and servers in same convention.
The codes for servers might be any of the following:
- L/V/H/M: For Laptops, Virtualbox-hosted-os, Hosting servers, Mobiles (used as personal usage or development time usage)
- LB: Load Balancer @AWS
- LMD: Lambda @AWS
- DY: Dyno Server/Container @Heroku
- DL: Droplet @DigitalOcean
- EB: Elastic Beanstalk @AWS
- AMI: Amazon Machine Instance @AWS
- ENNN: 4 digit code for E number, used for identifying cattle. Corresponding food of the E code should be used during documentation as code-name.
- Focus: it might be Index/PHP/Wordpress/NodeJS/Company-name/OS-name
- NN: Numeric entry, should be unique and autoincremented in focus area
- Deployment-type: How it’s deployed, possible values:
- P = Production with high availability
- D = Development time machine, low cost instances preferred
- U = UAT purpose machines, high availability preferred in low cost
- S = Sandbox, can/should/must be destroyed after concept testing is done
- T = Trial purpose to test something. Be sure about not to confuse with DEV server. It’s for test servers which are yet to be introduced to organization for a specific purpose (e.g. tested by DEVOPS engineer).
- X = Defunct. Usually when a server is taken out of system, it’s given a new name so that we can answer how many D/U/P servers are active in the system
- [Tag name]: This is optional, but highly beneficial when we’re running multiple container in a single host. There we have to name each container uniquely but the unique names will be attached to the unique host name easily.
For example, for an application “Wallpaperify”, I need a landing page which will redirect to a facebook page. I am using a heroku dyno for it and using their php-buildpack to setup required softwares. Therefore, I named this slug as: SFO-DY-INDEX-01P. Explanation is as follows:
- SFO → Deploying this to San Fransisco region so using the nearest airport code
- DY → It’s a dyno prepared by heroku
- INDEX → Default landing page
- 01 → Numeric entry for similar focus group
- P → Production server