Functional names for servers are IMHO one of the worst possible options, because functions drift over time.

Have individual hw named in unique way that isn't related to functionality it runs, then use CNAMEs specific to functionality - i.e. never point a DNS client at "freddy.dc.somecorp.com", you point it at "dns01.dc.somecorp.com".

The decision on what machines need unique names, not just pseudorandom IDs or similar crap, is well described by another comment here https://news.ycombinator.com/item?id=26054487 - which I like to put as "named systems are the systems you care about"

In fact, I'll go with seemingly unpopular opinion that there are only pets, never cattle. The pets just happen to have components, but at some level of the stack you're hitting a precious pet. Even if said pet is "us-east-1 Lambda service"

There is a good point to the drift of functions. You just need to run this one thing, and you do have that server which could just run it. It's a very real thing.

Where I see this most often is with companies that place a unusual high cost on servers, virtual machines or containers. In those cases I normally just application servers, that's a good a description as any. The only difference is that I won't thing twice about deleting a server called app01 and recreate it using Ansible, Puppet, docker-compose or whatever deployment tool that customer uses.

In my mind there aren't "pets" any more, and if there is that's a mistake that needs to be corrected. The customers I deal with who have pet servers are the most dysfunctional and the ones with the most challenges, both technically and organisational.

Why can't you rename the host if its function changes? Like if "the 1U box with asset tag XY1Z234" goes from being a web server to a DB server, why not reinstall it and call it db03?

I think the approach of naming the host "freddy" works for small installations (and all installations in 1990 were small), where reinstalling a single server is a manual process and impacts your capacity, and where humans remember "Oh, freddy is the one with a very large hard drive." If you've got any sort of automation, let alone virtualization, you should be keeping facts about hardware somewhere other than people's heads and so you can index them by the actual identity of the hardware - the fact that web04 had a large disk last year is remembered by a field on your inventory entry for XY1Z234, not by any human. And reinstalling web04 as db02 is just a matter of running a script from the comfort of your work-from-home laptop - certainly no need to visit the datacenter.

I think this lines up with your point about pets being higher levels of abstraction - I wouldn't point any DNS client at dns01, since that's a specific server, I'd point it at a virtual IP that can be bound (possibly multicast) by any dnsNN server that happens to be up. That virtual IP is the pet and the API surface, and it belongs to no actual server.

Maybe it depends on how big pockets one used to have, and how willing one was to follow vendors jealously declaring their software should be the only thing running on the server.

In my experience, unless a server was a VM host (or, these days, k8s cluster), it was rare that it would be single function. We just didn't have the money to allow such waste of resources. So unless you had single-software with enough requirements to hog the whole box (usually DB servers), then everything tended to have multiple functions, and reimaging was rarer event.

So I prefer to have "Freddy the web serving system", which might contain several machines named in style of R04-24.SFO.i.contoso.com ;) - because "freddy the web serving system" is the part that I care, and individual components enter everyday care only in the metrics of capacity planning dashboard.

> I'll go with seemingly unpopular opinion that there are only pets, never cattle.

This is emphatically not true beyond a certain point, perhaps around 500 boxes or so. My last job involved working on a fleet of about 15,000 hosts; I can promise that extremely few of the servers were precious pets. They really were cattle, and we would blow away and reimage them into different functions (with hostnames matching the function) moderately frequently.

Ehh, it's actually a topic for a yet-unfinished article of mine, but note that I pointed that "us-east-1 lambda service" is still a pet.

In the case you described, whatever drives the replacement system is the pet - the so-called cattle are just "components" that became interchangeable for the bigger "pet" system. As another commented called it, you need good names at the edge - where the edge for me is the level where you care about the system. We used to care about individual components of a computer and those would be effectively "pets" of the time. Nowadays, you do not give name to a DIMM in your server nor take extra care to ensure it works. And so on, till you reach the level you actually have to care, and that's where you need to name it (IMO) because that's your pet, even if it's composed of what people call cattle.

As for hostnames matching functions - I found much more use when making hostnames reflect basic type of hw and physical location, and would keep the name as long as the location didn't change. The rest depended on what functions were currently applied to the machine.

I used to name physical servers like pets (greek gods or whatever) and virtuals like cattle (function), with the idea that, yes, function of physical machines can change over time...

But the problem with that logic is that the name is not only attached to the metal, it's set (and mostly so, I'd argue) in software, as the OS hostname. And then what happens next is that the motherboard of that precious pet melts down and you scramble to move those drives to a spare, and now you have two metals with the same name.

It just doesn't work so well.

And your fancy random or pseudorandom looking naming scheme is cool and fun until someone new comes in and asks you wtf colchicifolium is...

Name machines on purpose. If the purpose changes, the OS will likely follow as well. If not, renaming shouldn't be that big of a deal, or, to put it another way: if you can't rename, you can't reinstall, and then you'll fail.

Now naming hardware is the "fun" part. when is the last time you did an inventory of your motherboards? or is it disks we're naming? the raid array or individual ones? how about memory sticks? or do you only name precious server cases? ;) after all, that is where the label ends up...

Used to name arrays, at one point had a hell of a problem because we found out that we had no way to consistently name, and thus communicate, PCI-X I/O-bays (it was a big POWER server...)

But if a pet "melts", well, the pet died. You moved the functions over to another pet. Whether it's a move from Zeus to Jupiter, or rebuilding your precious cattle management system on eu-central-1 after us-east-1 burned down and you got slapped with data locality requirements, is less relevant ;)

If you can easily move function between pets, it's not a pet, it's cattle. :)

Cute naming schemes are a holdover from the days of physical servers when location, function, etc were subject to change so an immutable machine name couldn't contain them. Now that most things are virtual and easily created/destroyed there's no good reason _not_ to name functionally. The most common refrain I've heard in defense of these archaic naming practices is that "we don't want the hackers to know which server does what" but if they've managed to get your root DNS zone file or a shell on a box then you're already pretty far gone anyway (not to mention that nmap exists). All it does is impede productivity and create the illusion of security.

If you are dealing with assets in a physical environment then obviously the above doesn't apply.

As a side note: a long time ago (before I knew what I was doing) I ran a Windows Server environment for my dad's business. The main server was Jake and the off-site backup was Elwood.

> Now that most things are virtual and easily created/destroyed there's no good reason _not_ to name functionally.

Uh, my servers with at least 256G of RAM and a raid60 of more drives than you have virtual machines can't easily be moved around.

> If you are dealing with assets in a physical environment then obviously the above doesn't apply.

Yes, baremetal, the only way to guarantee performance!

> Yes, baremetal, the only way to guarantee performance!

Single function bare metal, that is. At which point, the boring functional naming scheme re-applies easily.

If you're running multiple different functions on a single box, how are you guaranteeing any performance for any single function? How does that differ from using a hypervisor with similar limiting features?

> How does that differ from using a hypervisor with similar limiting features?

Depends on what you think is the most costly: kernel control of processes, or hypervisor control of kernels controlling processes.

Based on my experience, no hypervisor is worth the trouble if you have the budget for dedicated servers.

> If you're running multiple different functions on a single box

The thing is, you don't do that unless you must.

You'll need a mapping for the server names anyway. If you have a large datacenter, I hope it's stored as configuration of your infrastructure as code tool, if it's small, you won't need to check it every time.

Anyway, is prod-web01 that server with an outdated web server that you keep because of that one system that couldn't migrate, the one with a Java server that runs those proprietary tools, the one with IIS that runs that FOSS code that the developer decided to write in C#, the one supporting your main applications or the one you insulated in a special network because it hosts a powerful API that you don't want to expose?

"prod-web02" implies that this is the second web server in a cluster of web servers. That makes a lot of sense in 2021, where "prod-web02" is likely an AWS instance or a docker VM that is doing nothing but serving web pages, and which exists in some cloud server where you will never see the physical machine it is running on.

This was written in 1990, though, and there was no cloud, and VMs were quite rare things, (and we had to walk to school uphill, both ways, in the snow). Machines were physical things, and no one had the budget to buy an entire computer to be the second production web server - a machine ran a lot of different daemons that did a lot of different things, and the roles and responsibilities of a given physical piece of hardware would change as time went on. Which is still true today, but today it's just that a machine runs a lot of docker containers instead of running a lot of daemons, and we don't care where the docker containers are running, whereas back then we very much cared what machine it was running on, because sometimes we had to go to that machine and reboot it or kick it or install more RAM.

At the time, I was working at Alcatel (before it was Alacatel-Lucent, before that became Nokia), on a 450Gbps switch which was used for things like routing satellite TV feeds or handling distribution from big fiber backhauls, or running LANe for small nations. On the third floor, we had several racks of these switches in "the lab" which we used for testing and development work. While you could push a new software load from the comfort of your desk, if you borked things badly enough you'd sometimes have to go downstairs and plug a serial cable into the front of the control card so you could go poke around and force the card into a sane state.

So, when a new hire came in, they might say, "Hey mrweasel, I uploaded a bad load to Spock, and it's stuck in a boot loop. Where can I find that physical machine?" And you'd say, "Head down to the third floor, turn left out of the elevators, walk to the second last row of racks. On your left there should be switches named "Picard", "Riker", "Deana", etc..., and on your right should be "Kirk", "McCoy", and friends. Spock is third on the right between McCoy and Uhuru."

That conversation is way more confusing if all of these machines are named "test01-test20". You couldn't even name them that - there were lots of different products in different areas of the lab, so you'd need the product name in there, and they'd be "rsp7670-test01" through "rsp7670-test20".

And, when you want to push a new build from your desk, it's way less likely you'll mistype "picard" when you want to update "data", but it's quite easy to accidentally clobber "rsp7670-test05" when you mean to overwrite "rsp7670-test06", which was sure to summon an angry developer to your desk asking why you just killed their 48 hour validation testing, 45 hours in.

"or running LANe for small nations."

I had the joy of working on several ATM to the desktop campus networks using LANE and an ATM WAN using LANE to connect several thousand locations for an organization belonging to a large nation state. Thanks for triggering some horrible memories. ;)

I spent an entire weekend, dialed in by modem from Canada to a certain oil exporting middle eastern country, trying to figure out why the control plane for the ATM WAN that ran LANE for all their hospitals and 911 services was down. Fun times. :P