The "environment" absolutely should _not_ be part of the name of the resource.<p>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.<p>If you have 3 environments, dev staging and prod, you want resources in these environments to be named _exactly the same_ in each environment.<p>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.<p>What makes a workload a "dev" workload is dictated by its configuration (which database host it talks to for example).<p>When the environment is being coupled in the configuration of your workloads, inevitably a developer will end up writing code like:<p><pre><code> if env == 'dev' then use_database("dev.example.com")
</code></pre>
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:<p><pre><code> 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
</code></pre>
Instead, if your "dev" environment must talk to a "dev.example.com" database, create a variable called "DATABASE_HOST".<p>And for each environment, set the "DATABASE_HOST" to the value of the database this specific environment needs to talk to.<p>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.<p>The code above then simply becomes:<p><pre><code> use_database(DATABASE_HOST)
</code></pre>
and _this_ ^ will scale with an infinite amount of environments.<p>_Configuration_ defines the "environment" _not_ the name of the environment.<p>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).