4 ms·

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, def

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).

ecshafer 5y ago
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.
- burnished 5y ago
  I think that would be 'cattle' for these purposes, and you sort of glossed over the 'pet' example.
- lostcolony 5y ago
  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.

ecshafer 5y ago

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.

burnished 5y ago
I think that would be 'cattle' for these purposes, and you sort of glossed over the 'pet' example.
lostcolony 5y ago
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.