We always had the location in the name. It really helps when you have multiple data centers. If a machine was to move from one data center to another, it would be renamed (or more probably rebuilt).

Each DC had a different business usage, so knowing that immediately gave you context of what that machine should be doing.

We also would also have the environment (prod or dev) in the name. It just gave you an immediate understanding of the sensitivity of the machine and therefore stopped/warned folks from doing crazy things in prod.

Of course, YMMV, but I've always been a fan of names which give you context. Too much can be annoying but a little goes a long way.

Sure. And I would add that application identifiers can be a different problem domain. `app-dev.houston-1.example.com` would be a perfectly reasonable name for an application, whether it resolves to a host or a load balancer or a CDN endpoint or whatever. The underlying machines I still don’t really care about; they will register their availability in the cluster or whatever automatically, or else they’ll get names like “db” and “web” in the docker-compose file, or what have you. But sure, where a human might reasonably need to enter a name for a resource in order to access it, a brief descriptive name makes sense.

Yep, this is my position. As soon as you do it, people are going to (1) try and squeeze more stuff in and then (2) the names become configured somewhere and diverge from whatever the original purpose was.

Another requirement is you want the names to be a sparse address space: there should never be confuse-able or mistypable characters which drop you into another computer name - so systems like r0001, r0002, r0010 etc. should be right out.

Finally you also want the name to be human pronounceable: if everything's going well, it'll never be said. When things are not going well though, you want it to be something that can be communicated verbally if you need to - i.e. over the phone, or across an office.

Hence, word-lists are ideal as hostnames. Keep them short to around 2-3 syllables. They must be meaningless (and thus also not imply meaning). Any other information you need should come out of the CMDB. If you need more specific info hanging around, then you DNS and CNAME's to set up aliases for things like trying to SSH into "the machine at these rack coordinates" and keep that information updated from your CMDB.

I agree with everything you said here. I also have another rule: I never reuse a machine name. If a machine gets retired, the name it had is retired along with it.

I started doing that after a hard-to-diagnose problem that resulted from restoring a configuration file that referred to a machine that had been retired, but the name was reused, making it refer to the wrong machine.

There's a tension here between the two user groups who need to interact with the name: whatever software system manages the things, and human beings.

I worked on a system that had dozens of small-form-factor linux computers, that served as gateways for a fleet of thousands of bluetooth environmental sensors. Because of the nature of the facility construction, it was considerably easier to provision devices before deployment, then record location and other meta-data later. So the unique ID (a 16-digit hexadecimal number) in the system was completely disconnected from the metadata, but the common name of the device was defined almost entirely from the metadata. That also meant that while the unique ID was immutable and described a unique computer, the common name more described a location and purpose that a computer could be deployed to. Even so, that distinction lived waaay up in the facility management software design, and in practice, the only people even aware that the unique ID existed and was a distinct number from the "name", were the people tasked with provisioning the device for deployment.

Plenty of orgs have multiple people named "Steve", a few even have multiple people named "Stephen A. Ambrose", but no good org has multiple employees with the same employee ID number. And to further that analogy, no good org expects its employees to completely ignore the human name in favor of the employee ID.

I agree. I used to name my machines using metadata, but that became problematic after a while. When machines move or are repurposed, then you either have a misleading name or you have to rename the machine. I prefer to avoid both of those situations.

That's why I switched to names that have no relationship with the particulars of the machines they are assigned to.

It's incredibly useful to categorize hostnames. It won't encompass all possible information, but enough to know at a glance what you're dealing with. Hostnames end up in all sorts of places, backup files, monitoring systems etc, and being able to tell a webserver from a switch and prod from test makes life easier to everyone.

The argument that equipment change location and uses sounds to me like an environment where disposing and creating new hosts is much too hard. The lifetime of a host should be simple and well defined such that no one is tempted to make such changes without decomissioning.

The last company I worked switched to such a scheme for their servers, and it was not a good experience. The person who spearheaded it regretted the change.

The problem was that you still have to consult a key in order to decipher the hostnames, and since the names were all similar to each other, mistakes were an everyday occurrence.

Since you had to refer to documentation anyway, using more unique names would have reduced error and confusion.

Same experience here.

The metadata database for hosts starts looking an awful lot like DNS after a while.

Ideally, endpoint devices are enrolled and provisioned automatically. Decommissioning is a few clicks. Service hosts are deployed and destroyed via ansible or orchestration.

Backups, monitoring, logging, SIEM, etc. are integrated with the CMDB such that events and managed hosts are linked in both directions.

If anything, I’m spoiled on having automated systems making lifecycle terribly easy. I would concede that’s a blind spot in my perspective; many organizations aren’t going to be similarly equipped. If such an organization is managing more than a few dozen devices, however, they may have bigger problems than naming.

As it should be. Thus far, the people who advocate for the abolishing of host names have been the same people who lack lifecycle processes. I don't think this is a coincidence. Most people tend to solve the problems they can grasp, and it is hard to see what you lack.

> Name things uniquely, and as little beyond that as possible

I think that points to UUID or an incrementing counter, but the incrementing counter may be harder to ensure uniqueness depending on how names are created (which can change in the future).