When you’re managing multiple server in multiple region for multiple application, it’s difficult to keep tract on what’s happening where. In my company, an amazing convention is followed. Being curious, I search how rest of the world does it and got some amazing ideas from the folks who manage hundreds of instances in AWS. Consequently, I settled to the following convention:

<location>-<machine-type>-<focus>-<NN>-<deployment-type>, where each of them may have any of the following values:

• Location: nearest airport of the datacenter where it’s located
• Machine type: 2 digit code for servers. It might be any of the following:
  • LB: Load Balancer @AWS
  • LM: Lambda @AWS
  • DS: Dyno Server @Heroku
  • DC: Dyno Container @Heroku
  • EB: Elastic Beanstalk @AWS
  • AI: [email protected]
  • L/H/M: For laptops, hosting servers, mobiles (used as personal usage or development time usage)
• Focus: it might be Index/PHP/Wordpress/NodeJS/Company-name
• NN: Numeric entry
• 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 = Not to confuse with UAT. It’s for test servers which are yet to be introduced to organization (e.g. tested by DEVOPS)

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 SanFransisco region so using the nearest airport code
• DY → It’s a dyno prepared by heroku
• INDEX → Simple php based script to redirect user to another url
• 01 → Numeric entry for similar focus group
• P → Production server