Cloud Naming Convention (2019)

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

I think it is helpful to include environment name - they show up in UIs, consoles, DNS names, etc, and provide the operator a sanity check what environment a resource is in at a glance.

From the article:

> As usual, there’s no silver bullet and the actual naming convention should always be tailored to your environment. The main point is having one! And I hope this post gives you a head start.

Eh. Sure, I slightly mis-read the article, it happens.

Just preface my block of text with a "tangentially, when it comes to 'workloads' ... [the rest of the block of text]", and now you have a generic comment, not about the article, but about something related.

I disagree. Sure it might be an anti pattern, but it’s also for safety. Everything which is production should be called production. I have seen this in the places I’ve worked for the last 10 years or so, and never seen code like: “ if env == 'dev' then ”.

There is a story of a bank who sent out cancellations in production of all their trades because of a mistake due to something like that. That was a costly mistake.

Production and test environments should not even be on the same network. And, ideally, in my opinion, whoever has acces to a production server should not have access to a test server, and the other way around.