from Hacker News

Cloud Naming Convention (2019)

by etxm on 7/24/21, 4:27 AM with 30 comments

by ukoki on 7/24/21, 11:37 AM
Resource types in the name is a pet peeve of mine. They should not be part of the name. An RDS instance can never be anything other than a database, no need for 'database' or 'db' or 'rds' in the name. Likewise a Kubernetes cluster can never be anything other than a k8s cluster. It doesn't need 'cluster' suffix.
Terraform makes this redundancy especially obvious because you already include the type in any references to resources eg.
google_container_cluster.payments_cluster.something
by FridgeSeal on 7/24/21, 12:12 PM
I’d argue for having environment-if you do specify it in your resource name- should be at the start, and ideally capitalised differently: in the awful event you somehow find yourself in some kind of environment where dev and prod services are inexplicably listed together, you probably want it to be as clear as possible which one you’re accessing/reading/etc.
Personally I think applications should be blind to environment and have the relevant configs passed to them and said environments should be as well-separated as possible. Ideally in different accounts. With different URL’s. That are co-inaccessible.
by aliswe on 7/24/21, 6:50 AM
this falls when azure allows a-z0-9 hyphens and underscores on most resources, a-z and underscores (no hyphens or digits) on some resources, and on others, only a-z and like 20 characters.
that's not a fault with the article, though.
by gouggoug on 7/24/21, 6:38 AM
The "environment" absolutely should _not_ be part of the name of the resource.
Coupling the notion of "environment" with your workload (be it in their name or their configuration files) is an anti-pattern that I wish people stopped following.
If you have 3 environments, dev staging and prod, you want resources in these environments to be named _exactly the same_ in each environment.
Whatever your workloads are, wherever they run, they themselves should never _be aware of the environment they run in_. From a workload's point of view the "environment" and its label (dev, staging or prod) do not matter. What makes a workload a "dev" or a "production" workload are their respective configuration and the way they differ, _not_ the name of the "environment" they run in.
What makes a workload a "dev" workload is dictated by its configuration (which database host it talks to for example).
When the environment is being coupled in the configuration of your workloads, inevitably a developer will end up writing code like:
```
  if env == 'dev' then use_database("dev.example.com")
```
This won't work at all at scale as people start adding new environments (imagine, "qa","test", "dev_1", "alphonso's_test", "etc") as developer will start adding more and more conditions:
```
  if env == 'dev' then use_database("dev.example.com")
  if env == 'qa' then use_database("qa.example.com")
  if env == 'dev_1' or env == 'alphonso' then use_database("dev_00.example.com")
  // ... add more and more and more conditions
```
Instead, if your "dev" environment must talk to a "dev.example.com" database, create a variable called "DATABASE_HOST".
And for each environment, set the "DATABASE_HOST" to the value of the database this specific environment needs to talk to.
For example, for your "dev" environment DATABASE_HOST = "dev.example.com", and in your prod environment DATABASE_HOST = "prod.example.com". Here we clearly have a "dev" and a "prod", yet "dev" and "prod" are merely a "labels" for us humans to differentiate them, but the _configuration_ of these environments is really what defines them.
The code above then simply becomes:
```
  use_database(DATABASE_HOST) 
```
and _this_ ^ will scale with an infinite amount of environments.
_Configuration_ defines the "environment" _not_ the name of the environment.
edit: I realize the article is talking about your cloud provider resources and people might be running multiple "environment" resources in a single account. The above applies to "workloads" talking to these "cloud provider resources", not to the resources themselves, since, of course, you can't have 2 DBs named the same under one single account (obviously the names would collide).
by pwrplus1 on 7/24/21, 9:52 AM
I was disappointed that this article was not about naming actual clouds.