In a business with tens of thousands of servers, it makes sense to have long complicated names.
I’m actually not convinced of this approach. It’s one of those things that makes perfect logical sense when you say it - but in practice “DBDWWHORCLHHIP01” is just as meaningless as “Hercules”. And it’s a lot more difficult to say, remember and differentiate from “DBDWWHORCLHHID01”. You may as well just use UUIDs at that point.
Humans are really good at associating names with things. It’s why people have names. We don’t call people “AMCAM601W” for a reason. Even in conversations you don’t rattle off the long initialism names of systems - you say “The <product> database”.
When I say long name I wasn’t implying meaningless ones.
Most business with a lot of machines uses long names where everything as a logical meaning.
[Site][service][Rack][User selected 8 chars name]
I mean you dont have to use such obtuse names. But if you have a lot of servers you have to have a long name or you will risk exhausting the available names.
I’m just saying long names dont have to be obtuse or confusing. You can use user selected names as a suffix to a more functional initial prefix. So that people who work this area of the infrastructure can have clear names but at the same time some other sys admin that never worked on it can still know where and who is responsible of the server.
My initial point is just that the namespace and length of hostnames mostly depends on what you want to do. For a homelab you dont need wide namespace. But for a large business using short names wouldn’t be practical either.
When I say long name I wasn’t implying meaningless ones.
Sooo, that example wasn’t exactly “contrived” - it’s based on a standard I see where I work.
DB - it's a database!
DW - and a data warehouse at that!
ORCL - It's an Oracle database!
HHI - Application or team using / managing this database
P - Production (T forTest - love the 1char difference between names!)
01 - There may be more than one.
This is more what I’m arguing against - embedding meta-data about the thing into its name. Especially when all of that information is available in AWS metadata.
[Site][service][Rack] makes sense for on-premise stuff - no argument there.
I’m just saying long names dont have to be obtuse or confusing.
I used to name systems after Star Trek ships, but switched to Farscape characters ages ago. Now I’m doing more practical names based on function.
At this point I’m just tired of the acronym salad we all tend to deal with at work
“Wait, was I supposed to bounce CDBWINPROD02 or DBCWINPROD02?”
Figured if I had a choice I would use more “human” names that allow the servers to have more of a “personality”
Perse for example has been having an issue with it’s bios and it’s been spending quite a lot of time in the underworld LOL
God I hate the “stuff as much information into a server name as you can with no separators in all caps” naming conventions…
In a business with tens of thousands of servers, it makes sense to have long complicated names.
For a homelab ? Not really.
I’m actually not convinced of this approach. It’s one of those things that makes perfect logical sense when you say it - but in practice “DBDWWHORCLHHIP01” is just as meaningless as “Hercules”. And it’s a lot more difficult to say, remember and differentiate from “DBDWWHORCLHHID01”. You may as well just use UUIDs at that point.
Humans are really good at associating names with things. It’s why people have names. We don’t call people “AMCAM601W” for a reason. Even in conversations you don’t rattle off the long initialism names of systems - you say “The <product> database”.
I think you choose a poor example.
When I say long name I wasn’t implying meaningless ones.
Most business with a lot of machines uses long names where everything as a logical meaning.
[Site][service][Rack][User selected 8 chars name]
I mean you dont have to use such obtuse names. But if you have a lot of servers you have to have a long name or you will risk exhausting the available names.
I’m just saying long names dont have to be obtuse or confusing. You can use user selected names as a suffix to a more functional initial prefix. So that people who work this area of the infrastructure can have clear names but at the same time some other sys admin that never worked on it can still know where and who is responsible of the server.
My initial point is just that the namespace and length of hostnames mostly depends on what you want to do. For a homelab you dont need wide namespace. But for a large business using short names wouldn’t be practical either.
Sooo, that example wasn’t exactly “contrived” - it’s based on a standard I see where I work.
DB - it's a database! DW - and a data warehouse at that! ORCL - It's an Oracle database! HHI - Application or team using / managing this database P - Production (T for Test - love the 1 char difference between names!) 01 - There may be more than one.This is more what I’m arguing against - embedding meta-data about the thing into its name. Especially when all of that information is available in AWS metadata.
[Site][service][Rack]makes sense for on-premise stuff - no argument there.Agree
Amen, feels cold and unimaginative
Home server larping as a real enterprise server.