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