6 ms·

Cloud Naming Convention (2019)

43 points by etxm 5y ago

gouggoug 5y ago
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).
- wutwutwutwut 5y ago
  > If you have 3 environments, dev staging and prod, you want resources in these environments to be named _exactly the same_ in each environment. So your production database server has the same resource name as your dev database server? Good luck running that on Azure. Re your edit: When people have strong views ("absolutely not") and rants about it and yet does not seem to grasp what the article about, I think the opinion of those people should be ignored. Consider that.
  - gouggoug 5y ago
    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.
    - wutwutwutwut 5y ago
      When people skim through something in a sloppy way and then focus on writing a rant about it I just don't take their view seriously. If people can't be bothered to carefully digest information, I just assume that they don't know what they are talking about. You may be right or wrong, but I would just choose to listen to people who did their homework instead.
      - alexanderdmitri 5y ago
        Seeing as these are the only two comments you've made on this thread, it seems like you're not ignoring what you claim should be ignored and taking all this a bit too seriously. Whether it makes sense to add the stage name to a resource name is a decision that is informed by a wider context that includes hosting environment, deployment pattern and configuration approach. It can make sense in some situations and can be a bad idea in other situations.
- plasma 5y ago
  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.
aliswe 5y ago
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.
- GordonS 5y ago
  Also, with externally addressable Azure resources, the resource name is used as part of the FQDN name, and you cannot change the hostname later. Which might impact on how you choose to name resources.
pwrplus1 5y ago
I was disappointed that this article was not about naming actual clouds.
- samizdis 5y ago
  Ha! I was similarly disappointed. But you might find this a good starting point, if you've not come across it before: https://en.wikipedia.org/wiki/International_Cloud_Atlas https://en.wikipedia.org/wiki/International_Cloud_Atlas
  - pwrplus1 5y ago
    No more reliance on GPS for me!
ukoki 5y ago
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
- FridgeSeal 5y ago
  I swear some companies do this out of some perverse habit: one place I worked at used to prefix repos, internal modules, infrastructure names, etc with the name of the company. Which was so frustrating because we all work here, we know what it’s called, it doesn’t add anything, there’s no sister-company we share resources with, all it does is make it harder to distinguish between 2 similarly named, but entirely too long internal applications.
  - pjot 5y ago
    I worked with a company that did this as well - they even went as far as prefixing their _slack_ channels with $(companyName)…
- k__ 5y ago
  I had the impression, the types get in the name exactly because they can't change.
- darkwater 5y ago
  I cannot agree on this more. Also things you should never put in the name of a resource: its provider. I mean, why do you want to put in every Google Cloud resource the GGL prefix? And last, if we are talking cloud let use tags to describe most of the useful metadata and make them 1St class citizens, although the name will always stand out more.
- jgalt212 5y ago
  How do you feel about Hungarian notation?
deleted 5y ago
[deleted]
FridgeSeal 5y ago
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.

43 points by etxm 5y ago

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

wutwutwutwut 5y ago
> If you have 3 environments, dev staging and prod, you want resources in these environments to be named _exactly the same_ in each environment. So your production database server has the same resource name as your dev database server? Good luck running that on Azure. Re your edit: When people have strong views ("absolutely not") and rants about it and yet does not seem to grasp what the article about, I think the opinion of those people should be ignored. Consider that.
- gouggoug 5y ago
  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.
  - wutwutwutwut 5y ago
    When people skim through something in a sloppy way and then focus on writing a rant about it I just don't take their view seriously. If people can't be bothered to carefully digest information, I just assume that they don't know what they are talking about. You may be right or wrong, but I would just choose to listen to people who did their homework instead.
    - alexanderdmitri 5y ago
      Seeing as these are the only two comments you've made on this thread, it seems like you're not ignoring what you claim should be ignored and taking all this a bit too seriously. Whether it makes sense to add the stage name to a resource name is a decision that is informed by a wider context that includes hosting environment, deployment pattern and configuration approach. It can make sense in some situations and can be a bad idea in other situations.
plasma 5y ago
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.

aliswe 5y ago

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.

GordonS 5y ago
Also, with externally addressable Azure resources, the resource name is used as part of the FQDN name, and you cannot change the hostname later. Which might impact on how you choose to name resources.

pwrplus1 5y ago

I was disappointed that this article was not about naming actual clouds.

samizdis 5y ago
Ha! I was similarly disappointed. But you might find this a good starting point, if you've not come across it before: https://en.wikipedia.org/wiki/International_Cloud_Atlas https://en.wikipedia.org/wiki/International_Cloud_Atlas
- pwrplus1 5y ago
  No more reliance on GPS for me!

ukoki 5y ago

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

FridgeSeal 5y ago
I swear some companies do this out of some perverse habit: one place I worked at used to prefix repos, internal modules, infrastructure names, etc with the name of the company. Which was so frustrating because we all work here, we know what it’s called, it doesn’t add anything, there’s no sister-company we share resources with, all it does is make it harder to distinguish between 2 similarly named, but entirely too long internal applications.
- pjot 5y ago
  I worked with a company that did this as well - they even went as far as prefixing their _slack_ channels with $(companyName)…
k__ 5y ago
I had the impression, the types get in the name exactly because they can't change.
darkwater 5y ago
I cannot agree on this more. Also things you should never put in the name of a resource: its provider. I mean, why do you want to put in every Google Cloud resource the GGL prefix? And last, if we are talking cloud let use tags to describe most of the useful metadata and make them 1St class citizens, although the name will always stand out more.
jgalt212 5y ago
How do you feel about Hungarian notation?

deleted 5y ago

[deleted]

FridgeSeal 5y ago

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.