Naming conventions for servers, two years later

A few years ago, I wrote an ar­ti­cle ex­plain­ing how do I name servers. Since then, lit­tle changed, and con­ven­tions used in com­pa­nies are still in­sane. Men­tal­i­ty hasn't changed ei­ther, and it's still con­sid­ered pro­fes­sion­al to have ar­bi­trary, mean­ing­less names no­body could re­mem­ber.

The ben­e­fits of ex­plic­it, mean­ing­ful host names are, how­ev­er, high:

• An ob­vi­ous rea­son is that it re­duces er­rors. I stopped count­ing the num­ber of times where, us­ing cus­tomers' sys­tems, I con­nect­ed re­mote­ly to a wrong serv­er, and no­ticed my mis­take only half an hour lat­er. Those mis­takes have a very con­crete cost, not only in terms of wast­ed time, but also in terms of out­ages which could be caused by op­er­a­tions per­formed on a wrong ma­chine.

  Con­ven­tions which make it dif­fi­cult to dif­fer­en­ti­ate be­tween en­vi­ron­ments are par­tic­u­lar­ly harm­ful. And by dif­fer­en­ti­a­tion, I don't mean hav­ing a “p” for pro­duc­tion and “s” for stag­ing in a name such as “stxp4508-g2p-lac,” be­cause, frankly, most per­sons are to­tal­ly un­able to no­tice one let­ter dif­fer­ences in to­tal garbage. It should be need­less to ex­plain what could be the con­se­quences of run­ning com­mands on a pro­duc­tion serv­er, be­liev­ing that you're on a de­vel­op­ment ma­chine.

  Aside ssh-ing to wrong ma­chines, which one shouldn't do any­way in a com­pa­ny with a de­cent­ly ma­ture in­fra­struc­ture, the er­rors could also creep in when (1) chang­ing con­fig­u­ra­tion or (2) study­ing logs. Those are ex­act­ly two sit­u­a­tions where you ab­solute­ly need to avoid any dis­trac­tion caused by un­clear host names, and pre­vent any mis­takes be­tween dif­fer­ent ma­chines. Spend­ing an hour won­der­ing why there is a mis­match be­tween the bug re­port sent by a user and the ac­tu­al logs, and dis­cov­er­ing that you were look­ing at the logs of a dif­fer­ent ma­chine isn't a nice sit­u­a­tion.

• A more mi­nor rea­son is that it saves time even when no hu­man er­rors are made. When names are clear, if I want to tar­get a spe­cif­ic ma­chine, I just do it. When names are cryp­tic, I need to copy-paste the name from some­where. If it's a web page or an Ex­cel spread­sheet, this means that I need to open one. This also means that some­body, some­where, need­ed to cre­ate this page or spread­sheet, and needs to main­tain it.

• For some con­ven­tions, a change of a pur­pose of the serv­er or a change of own­er­ship could ne­ces­si­tate it to be re­named. Re­nam­ing a serv­er isn't an eas­i­est thing to do, giv­en the de­pen­den­cies (mon­i­tor­ing tools, apps). This usu­al­ly leads to the de­ci­sion to post­pone the op­er­a­tion, and, years lat­er, the serv­er still has an old name. If the con­ven­tion is ac­tu­al­ly used, the sit­u­a­tion be­comes er­ror prone by it­self.

  In the case of one cus­tomer, the names of ma­chines con­tained the ad­min­is­tra­tive names of the di­vi­sions own­ing the servers. When a serv­er changed own­er­ship, no­body could af­ford spend­ing sev­er­al days clean­ing the mess af­ter re­nam­ing it, so its orig­i­nal name was pre­served. When the serv­er per­formed a DOS at­tack on one of the in­ter­nal ser­vices, the team han­dling this ser­vice sent an alert to the team which should have been the own­er of the serv­er ac­cord­ing to its name. How­ev­er, this team, not own­ing this serv­er any longer, couldn't re­spond, and no­body knew which team was re­spon­si­ble now. It's only a week lat­er than some­one from the con­cerned team no­ticed some­thing strange hap­pen­ing.

• Fi­nal­ly, hav­ing a name of the con­cerned ap­pli­ca­tion in the host name makes it pos­si­ble to iden­ti­fy very eas­i­ly all the servers which are used by an ap­pli­ca­tion by sim­ply grep-ing the list of servers.

There are, how­ev­er, a few lim­i­ta­tions as well.

• While I be­lieve that this ap­proach scales well, I have used it in prac­tice on only a tiny in­fra­struc­ture: only sev­en­ty-five ma­chines, and only one per­son to con­trol their nam­ing. While us­ing the same ap­proach in a com­pa­ny with thou­sands of ma­chines doesn't scare me a lot, the hu­man fac­tor could, in­deed, be a se­ri­ous threat. It is tech­ni­cal­ly pos­si­ble to iden­ti­fy the nam­ing pat­terns and en­force them, but not for every ma­chine. For in­stance, my http- ma­chines or ma­chines which host data­bas­es have very uni­form names, but some just can't fol­low the rules. An ex­am­ple is a ma­chine which han­dles dy­nam­ic IP up­dates and is called dyn-updater. An­oth­er case is the ma­chine named pxe which serves as a PXE serv­er to re­build phys­i­cal ma­chines. Large com­pa­nies will have more of those very spe­cif­ic cas­es, and nam­ing and track­ing those servers could eas­i­ly be­come a mess.

• The change of ap­pli­ca­tion name would ne­ces­si­tate to re­name a lot of ma­chines. One so­lu­tion would be to use a co­de­name for a pro­ject, and a com­mer­cial name for the pub­lic. This clear­ly doesn't work in my case, where most pro­jects are open sourced any­way. More­over, I be­lieve that this dou­ble nam­ing cre­ates un­nec­es­sar­i­ly com­plex­i­ty for du­bi­ous ben­e­fits.

• This nam­ing con­ven­tion and Win­dows are mu­tu­al­ly ex­clu­sive (should I put that as a ben­e­fit, rather than a lim­i­ta­tion?) The fif­teen char­ac­ters lim­it is hit by all but most ba­sic ma­chines. For ex­am­ple, one of the in­stances host­ing this blog, http-blog-failover, con­tains eigh­teen char­ac­ters, that is three ex­tra char­ac­ters. I can­not see any way to keep the names sane while squeez­ing them in the Net­BIOS lim­it. They would nec­es­sar­i­ly be­come un­read­able and in­ex­pres­sive.

  The longest ma­chine name so far, http-bookshelf-www-failover, con­tains twen­ty-sev­en char­ac­ters. This is far from the six­ty-three char­ac­ters lim­it on Unix, but with the pos­si­ble ad­di­tion of do­mains, this would be­come pelicandd-http-bookshelf-www-failover which gives thir­ty-sev­en char­ac­ters. With ad­di­tion­al stag­ing en­vi­ron­ment, this could get us to pelicandd-http-staging-bookshelf-www-failover, that is forty-five char­ac­ters. The names of ap­pli­ca­tions should re­main short enough to ac­com­mo­date for po­ten­tial suf­fix­es or pre­fix­es.

To con­clude, if you have an in­fra­struc­ture man­aged by a small team where every­one is re­spon­si­ble enough to care about read­able serv­er names, and if you use Unix-based ma­chines only, there are few rea­sons not to use this nam­ing pat­tern. It makes your life eas­i­er, and makes it un­nec­es­sar­i­ly to have a ded­i­cat­ed map­ping sys­tem be­tween hu­man­ly read­able in­for­ma­tion and cryp­tic iden­ti­fiers which are used by mis­take as ma­chine names. If you do use Win­dows, then the schema is un­for­tu­nate­ly not for you; but, well, if you do use Win­dows, you have oth­er, more cru­cial prob­lems to solve, right?