I was disappointed that this article was not about naming actual clouds.
Cloud Naming Convention (2019)
11–20 of 32 posts
Re: Cloud Naming Convention (2019)
#12The "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, where…
I agree with the sibling comments that you should have the environment name in the resource name - that way you can directly know whether the host you're connected to/the monitoring alert/etc. are prod or not.
Re: Cloud Naming Convention (2019)
#13The "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, where…
I tend to agree with this pattern as long as the commands you're running let you explicitly state which environment you're running these commands against so there's never any confusion by the human running the commands or the human reviewing CI logs.
With Kubernetes / Helm you can have all of your resources named the same in each environment, each with their own set of same named env vars that follow what you've described but whenever you do anything that interacts with your cluster you can add a `-n prod` namespace flag so that each environment runs in its own isolated namespace.
Also for good measure it's not a bad idea IMO to add _dev, _test, _prod to the name of your database just as a double identifier. It still meshes well with the strategy of using a DATABASE_URL. I like using the full URL instead of just using the DATABASE_HOST since the password will be different across environments and I'd rather only have to set 1 env var instead of 2+.
In a sibling comment someone mentioned this pattern doesn't work for monitoring in different environments but it does work. You can set an APP_ENV env var and then filter based on that. The same thing applies for logging. You can tag / filter your logs on the APP_ENV too.
Re: Cloud Naming Convention (2019)
#14Resource 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
Re: Cloud Naming Convention (2019)
#15Resource 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…
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.
Re: Cloud Naming Convention (2019)
#16[deleted]
Re: Cloud Naming Convention (2019)
#17I’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.
Re: Cloud Naming Convention (2019)
#18Resource 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…
I had the impression, the types get in the name exactly because they can't change.
Re: Cloud Naming Convention (2019)
#19Resource 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…
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.
Re: Cloud Naming Convention (2019)
#20The "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, where…
Globally namespaced resources (like s3) would disagree with you.
This always bites me. I wish it could be opt out. I'm fine namespacing my s3 buckets with my region and account and I rarely ever use s3 domains