With a pet, you obsess over the name and meaning of the name. With cattle, as long as names don't collide or cause problems, you couldn't care less about the name.
Mostly because for automation it's easier to know what a system does by looking at the hostname. When you manage about 30 systems all over the place, that's the only reasonable solution (I do see people trying to give pet names to their production systems but it gets out of hand and they usually just maintain a directory of what system does what somewhere)
sql01 is good if you only use sql abstraction layers, otherwise you probably even want postgres01 and mysql01. Or even postgres-olap01 and postgres-oltp01, if that's what you do.
If had a pure mysql server I'd call it mysql01
But then I did realize a couple of things, that improve with meaningful names:
1) Alerts impact and scope. It's easy to know what are you seeing in your phone, if balancers, rds clusters, and instances have meaningful names.
2) Metrics visualization. Maybe the graph is the same, but a meaningful legend sometimes helps.
3) SSH connection. I like to auto-complete SSH, not to copy/paste ssh and write down extra parameters like different .pem files.
4) (Inter) team communication. The same that with graph legends, for humans, it's easier with names than with ids.
5) Custom commands parametrization. The same than ssh, I prefer to be able to write down the parameter (host name, service name) of my command, without getting out of the terminal, copy the ID or IP, get back, paste, verify...
6) Costs/Reports visualization.
7) Backup management. Let's say S3 parent for the backups of a instance/service. Backup reports too.
At the end, I think that I can have cattle mentality regarding Configuration Management, System patching, Version change, etc... BUT I still can get benefits from thinking a little bit element and service names.
At the beginning (of the cloud concept), I did read pet Vs cattle, and I did think IDs were the thing. Now I think that to scale to many customers or many environments, it's better with previous thinking. Being the little string of the alert in the phone, the biggest winer.
You never want to have to manually pick a name, or even stop to think about it, but using pure IDs for anything with a life longer than a day can get annoying.
If I know the hostname I or my team will be tempted to make one-off changes, breaking the whole "cattle" idea.
Inevitably, some bug will occur, and in my experience, it usually happens to occur on a machine (rather than all of them at once; I'm not saying this machine is special — the bug could have happened on any of them, and likely exists on all of them because they're all running the same code, but this particular machine ended up being the lucky one to serve that slightly unusual request).
Getting in and debugging the state of that machine, pulling logs, directing a coworker to look at CPU detail "frobnozz", etc. is all easier if I can easily speak or type out the machine's name. "3.dev.microservice" is much easier to type/speak than say, an IP address, an EC2 instance ID, etc.
(I fully agree on not making one-off changes, and not treating machines as pets. But I think that even after that, decent naming has a place.)
And even with cattle, the other way, I still think it's useful for the name to provide some information. I.e., 3.prod.microservice being the third or fourth instance of the production setup of "microservice" is better than say, some random entry from the periodic table of elements.
${project}-${dev/staging/web}-${web/db}
(which so far has covered my bases, I'm sure you can come up with any logical extensions if you are running load-balancers or other types of servers, add a number if you are running multiple frontends or clustered DBs, etc)
Even as someone who manages pets, I can't tell you how much time this has saved me from having to look up server names. I have done the generic "assign everything to a single machine## sequence" and it sucks ass. Was your production web server for this app machine32 or machine 54? What about the staging server? Can't even imagine the hassle of uuids as server names.
(of course so far I have done the pets thing in my internal network... but I can tell you that my father with a 40y career in managing servers for major corporations uses names like vmhost01/fsrv01/tvpc at home... which tells you what he thinks of that.)
But, hey we don't name infrastructure sites "Site 1" and "Site 2". They're "Milwaukee" and "Austin" and "DR". So if we do that, why name them "EMC-SAN-1" and "EMC-SAN-2"? We're going to retire that name eventually and there won't be a SAN 1 anymore. And what happens after "EMC-SAN-9"? So, instead why not "EMC-SAN-ARTEMIS" and "EMC-SAN-APOLLO" and "EMC-SAN-HADES"?
There's a distinction between physical names and logical names, too. What kind of long term nomenclature planning should we have? Look at hurricane names. The NWS does that so people remember which is which.
Though with all the milking machines hooked up the dairy cows probably look more like them visually speaking..
And these days servers might be more metaphorically close, increasingly, to just the beef itself. Decentralised, to somewhat stretch the analogy.
If they are any servers that cannot be auto created / destroyed without human oversight - or if their downtime breaks other resources along the chain (eg non-clustered DB server) then I'd argue those servers are a little more like dairy cattle.
He was tasty.
Most of the general purpose computers (and certainly the vast majority of devices with an IP) I deal with have real world interfaces, SDI ports and/or analog/digital audio connections. I'm not going to give my encoder in Nairobi a name that doesn't say "Nairobi Encoder" (PTR returns NRB-ENC001-obe, forward lookup for NRB-ENC001), same with encoder 2 at New Scotland Yard, and the same with the ntop/monitoring box I have in the New York office. I can't self heal equipment when a lorry drives into it, but I need to know that it's the Old Bailey monitoring box that's broken.
Thank you for implying that I didn't know exactly what I was responding to, and that I didn't read it carefully. The grandparent to my comment mentioned the cattle-pet distinction. The parent comment took that as some kind of statement of how common each situation is. I replied in a similarly loosely-connected manner, trying to reinforce the grandparent comment's point.
I fully understand that "cattle-owners" are less common, and that that's part of what the parent comment was saying. Reread the comment that they replied to, and reinterpret my comment as a reiteration of the grandparent comment, phrased in a different way.
That is also how I feel about Microservices these days. I may still name the service with a "pet" like symbolic name, but I treat them as cattle.
They can be split, repurposed, deleted, rewritten any day without much remorse or delay. No personal attachment.
But all servers are named as cattle.
But these days they may not even be cattle named as they are spun up and down so frequently in cloud environments that names makes no sense.
Pets -> Cattle -> Population?