This is classic "pets" vs "cattle". At small scale, it's "Frank the frontend is down, let's get him working again because otherwise our users can't do anything", up to "front017.xxy is down, take it out back and shoot it".

I wonder if the notion of machines naming conventions being just about where to locate it on the rack, or which AWS data center it lives in, require further levels of abstraction about "pet" and "cattle".

Only sorta. Software devs can and should treat their machines as cattle, yes. But the guys actually maintaining the racks shouldn't. They have finite space, definite machines, and when one is down they have to identify it and go fix it.

(Meanwhile moving further down, if the hardware guys are having to name ethernet or power ports on the wall due to their various temperaments, something is wrong. And moving up, it's reasonable for devs to name their services, but a signal of an issue if the VP has to know them)

There's a level of abstraction underneath which you should not be aware of to do your job...but someone likely has to (it's not quite turtles all the way down, but it probably ends with physicists and theory rather than cold hard fact).

It is still better to have a clearly descriptive name policy than pet names. Maybe if you only have a half dozen machines. But with physical machines its better to have something like Region-Datacenter-Row-Rack-shelf-vendor-OS or something like that, so you are looking for EPNYA13CDL and not Dionysus. So that location and attributes of the machines are readily apparent. That way you immediately know its an External Facing, Production server, in New York, Row A, Rack 13, Shelf C, Dell Machine, running Linux.

So I'd view "descriptive names" as a separate discussion.

The point with the analogy is not how you name them, but whether you identify them at all. I really don't care about the name of the machine that died while running my distributed service; I shouldn't ever have to know it. It should automatically be culled and replaced.

The person working in a datacenter really does care about the name of the rack that is faulty; they have to find and replace it. That rack can be named "RM22-R3-5", a super descriptive identifier, or "Tennyson", because the whole room is Elizabethan authors and poets; point is, he DOES need to identify it.

The whole cattle vs pets is about identification and uniqueness, not about whether the identity is self-descriptive or not.

I think that would be 'cattle' for these purposes, and you sort of glossed over the 'pet' example.

I wish people would stop talking about cattle and pets. If you have or know someone who has worked in animal husbandry, you know it's a fragile metaphor.

My uncle owns a dairy farm with ~50 or so head of cattle.He gave each of them names and when one gets sick, he takes care of it.

Of course this is not a big industrial farm, but even so... not even actual cattle are as "cattle" as we're expected to treat computer-cattle -- and thanks to virtualization, computer-cattle are largely pretend anyway.

It's not only a shaky metaphor from the sentimental aspect, it's a downright bad one from the economic point of view. Individual cattle are expensive, and as a result, it makes economic sense to invest in their care. Even a ruthless person would not let a sick cow go without having a professional take a look to see if there was a way to restore it to good condition, but heartless or broke people often do decline to pay for veterinary care for a pet.

My relations own a pig farm with 10k pigs, they don't have names.

Fun story, my employer once had a contract with a huge pig farm like that and whenever we went on site we had to strip nude and shower off and then dress in clothes they provided, so we didn't contaminate the pigs with anything.

Yup, having to kill and discard all your product by hog cholera is not a joke.

Dairy cows are not usually referred to as cattle.

Of course they are, at least in my experience working at a dairy feedlot with thousands of head of dairy cattle.

Huh, I guess you're right. My context was family farms in the northeast/mid-Atlantic, where cattle always meant beef.

IIRC this was litigated by k8s years ago, hence we don’t have pet sets. But the metaphor is still in use because it’s so vivid and memorable. Is there a recommended replacement metaphor?

Garden vs Farm

Restaurant vs Cafeteria

Espresso vs Drip

Cafe vs Starbucks

Backyard BBQ vs McDonalds

I actually think that garden vs farm is a good choice. The others are a bit funny to me :)

Another thing to consider is international cultures. There’s been concern around calling servers cattle and saying to just shoot them in the head during work meetings. Some cultures may have issues with that.

Can confirm, when you have a small number of cattle at least some of them end up with names.

It's an effective and well-understood term.

A name generator makes the cattle herdable. Humans may remember zombie-wombat-kitten but not 3991. You might not ever interact with the machine directly but if you are hunting down an issue from log files it reduces cognitive load.

The important thing is cognitive load is the key thing, as is the possibility of confusion. Zombie-Wombat-Kitten is going to get shortened to ZWK, and hopefully there's no Zombie-Wombat-Keeper (or Zebra-Wagon-Kelp or Zombie-Wombat-Cat for those that just remember zombie-something-small-furry-animal). There's also little/no semantic meaning from that name. api-box-3-991 lets you know what type it is, and the relative vintage, so at a glance, it's not a version 2 box (which would be named api-box-2-991), and it's fairly late in the series, #991 vs #100.

Personally I like the second since we're having cattle not pets, but it's your fleet and this is rather bike-shed-y. :)

I mean, naming machines is cute on the one hand, but on the other, once you scale up / out, who will remember that Neptune is from finance and the Pleiades is management? Like with microservices, it's probably better to name things for what they do or where they are instead of coming up with aliases, else you have to maintain a translation table.

When scaling up - hard- or software - it's better to be clear than clever.

I've seen this multiple times, and there seems to be a pattern emerging.

At first, people name the machines after the software they install on it. Then, when you get to about 4-5 machines, you start finding a "cute" naming convention (Constellations, Star Trek ships, mythological figures). As long as there is only a handful of machines, it's easier to remember which machine does what.

Then, as you start to scale up, between a few tens to a hundred, finding names gets harder, so you switch to a more standard naming conventions. Something that communicates the physical/logical location and the organizational unit, as well as an index for duplicates / replicas / redundant machines.

So I think it's fine to be clever as long as it's manageable. The moment it's going to start getting out of hand you can switch to a more scalable approach.

"Pets" vs "cattle" is the classic metaphor. When your pet is sick, you take care of it, when "mp-32h-12b" is down you take it out and shoot it.

yes, of course, we had a small legacy cluster where I named our 36-odd machines after star trek ships. Knowing full well that when we went to a "real datacenter with real racks", the names would be rack-number/slot-number. My big mistake was zero indexing the slots. Never again.

What? How can zero indexing be a mistake?

We had a guy zero index a stack of shared Colo racks in one of our DCs a decade ago.

I sent remote hands to pull a server for a customer that was done with their contract and another for failure not pay.

Got the wrong boxes, disconnected two customers, put the servers on the shelf and left for the weekend.

So I cut a ticket to the next remote hands guy and tell home to get the boxes back up and running and we'll deal with it Monday.

Cut another ticket to a third text Monday to pull the boxes. Yeah, you guessed it wrong boxes again. Same customers, what the fuck.

Have the boxes reracked and drive out there to do it myself. Count the servers, wrong label, do some digging around, 'OH'. Pull the right server. Loose two customers. Cut tickets for all racks to be relabeled starting from one.

People don't expect 0 index in the physical world. It's just too clever by half.

If you're the only person who works in the rack, no problem. I worked as a tech and wired up machines once upon a time, ran fiber to core infrastructure, was boots on the ground for any physical access to the rack that was required, etc. I would not be surprised to hear a story of someone counting from 1 from the back of the rack and unplugging machine "7" or something.

> If you're the only person who works in the rack, no problem.

It's still likely bad. Your brain is simply not wired to zero index physical objects.

Which makes sense, as there can't be "negative" objects, mostly.

Building floors are more ambiguous - there can be basement, ie "negative" floors. So, floors in continental Europe are generally indexed 0-based (basements ..., -2, -1, ground floor = 0, upper floors 1, 2, ...). A German friend of mine caused some confusion when she checked into her student dorm at a US college, and having being told that her room was on the first floor, asked whether there was an elevator, as she had heavy suitcases.

In French, the first floor is called "Rez-de-chaussée" and the uppers are what called "Etage". So it's actually 1 based.

But the etage above the Rez-de-chaussée is 1, correct? The Rez-de-chaussée then is 0. That is 0-based indexing.

  US  D  F
   3  2  2
   2  1  1
 __1__0__RdC
  B1 -1  je ne sais pas

There is no Etage 0. People will just confusingly look at you if you ever said that. And the "Je ne sais pas' is called "Sous-sol"

In a lot of elevators rez-de-chaussée is labelled 0. We just don't use that when communicating

You can have multiple basement levels, which get numbered again. 1er Sousl-sol, 2eme Sous-sol etc. The ground floor might not be explicitly labeled as zero but the number between "one up" and "one down" is still zero.

The racks I've worked with have the slots labelled already, starting from 1.

Confirmed. Cute doesn’t scale. At google, a building I was in had conference rooms named after craters on Mars. This didn’t work as well in practice as it sounded on paper.

Talk of naming conventions puts me in mind of https://youtu.be/y8OnoxKotPQ

we named our prototype chips after British nuclear test codenames and all machines used to be terminator characters :).

Best scheme I've seen for a small fleet of development boxes (hardware, not VMs) was naming them after elements. Very easy to determine the IP address on that subnet.

I like it but you still have to memorize the periodical table for this to work. And you waste more than half the address space?

I'll assume it's a feature to learn periodical table this way :)

How many computers do you think we had??

But then people go from the memorable “Ebola” cluster to asynccompletionloggernodeweb where even with names that supposedly explain the function all the name parts are utterly generic and related to implementation not purpose. Not that people should keep Ebola. It should name services with a little skill and based on purpose not implementation. “Log4JarScanner” not “goAsyncFilerTreeScanner”. Tho the repo name is go-tree-jar cause I suck at names. Another cost of rushing is names it becomes hard to refactor out. At least we have hierarchical dns and longer names now, so it can have he data center/as and not be 8 chars. God bless the people that have name rules like Us1aesas02 - ProcessPostEventNodeDaemonServ-0322.Dallas.internal.example.com is more legible.

At the last job I had, there were a dozen or so microservices named after Greek/Roman mythology. The names were all quite clever if you knew the stories behind them... Eurybates handled inter-service communication, Stentor yelled at Hermes to send out emails, Hephaestus handled our cloud infrastructure, Janus handles some frontend pieces. The problem was that not everybody knew the stories behind them so it got really confusing.

At some point we got tired of it and made a very firm "all services going forward must have normal, descriptive names" rule and ended up with such shocking names as "Metrics" and "Authentication".

Switching jobs to other startups, it seems like "cute" microservice names are going out of style. Thankfully.

I prefer to name them using related hotel room numbers. Machines in one lan get numbers from one floor, machines in another get numbers from a different floor. It’s not as romantic but when we trade places for a day you’ll at least be able to make some sense of the network structure, meanwhile I’ll still be trying to read the almanac.

Getting "Being John Malkovich" vibes from this comment.

That type of naming drives me crazy. A server name should be descriptive and easily understood without context or documentation. For example, "api_1" makes a lot more sense than "proteus".