Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cloud Naming Convention (2019)

stepan.wtf

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Cloud Naming Convention (2019)

#21

Post by smitty1e »

surfsvammel wrote: post #10
gouggoug wrote: post #2

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, where…

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

Bottom line is that the systems tend no to give a GIVE what the names are, so long as they resolve to information.

The naming conventions are for the humans to reason about the system, and help the new hire not trigger an outage.

Getting the "proper" amount of information in there is the acme of skill.

Re: Cloud Naming Convention (2019)

#23

Post by GordonS »

aliswe wrote: post #5

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.

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.

Re: Cloud Naming Convention (2019)

#24

Post by pjot »

FridgeSeal wrote: post #15
ukoki wrote: post #14

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…

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 l…

I worked with a company that did this as well - they even went as far as prefixing their _slack_ channels with $(companyName)…

Re: Cloud Naming Convention (2019)

#25

Post by dcow »

raffraffraff wrote: post #7
gouggoug wrote: post #2

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, where…

Globally namespaced resources (like s3) would disagree with you.

Internally at Amazon people are expected to spin up entire separate AWS “conduit” accounts for different environments. So this only applies if you’re running everything out of one account, which is bad form.

Re: Cloud Naming Convention (2019)

#26

Post by pbar »

dcow wrote: post #25
raffraffraff wrote: post #7

Earlier quoted context omitted.

Globally namespaced resources (like s3) would disagree with you.

Internally at Amazon people are expected to spin up entire separate AWS “conduit” accounts for different environments. So this only applies if you’re running everything out of one account, which is bad form.

To their point, S3 buckets must be uniquely named globally, across all of AWS

Re: Cloud Naming Convention (2019)

#27

Post by alexanderdmitri »

wutwutwutwut wrote: post #9
gouggoug wrote: post #8

Earlier quoted context omitted.

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.

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.

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.

Re: Cloud Naming Convention (2019)

#28

Post by dcow »

pbar wrote: post #26
dcow wrote: post #25

Earlier quoted context omitted.

Internally at Amazon people are expected to spin up entire separate AWS “conduit” accounts for different environments. So this only applies if you’re running everything out of one account, which is bad form.

To their point, S3 buckets must be uniquely named globally, across all of AWS

Yeah, can’t escape things with global namespaces.

Re: Cloud Naming Convention (2019)

#29

Post by kjaftaedi »

gouggoug wrote: post #2

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, where…

This is such a terrible idea.

When looking at log files you need to know which node is having a problem. It's also helpful to know what environment was responsible for a security alert at a glance. It's also helpful to know if the instance that is running is the same one that had the incident, or whether it's a brand new node and the old one is gone.

Naming servers the same name loses a ton of valuable information and provides almost no benefit. It is just inviting people to make mistakes, and creating a nightmare for your noc/soc and siem response teams.

Re: Cloud Naming Convention (2019)

#30

Post by jgalt212 »

ukoki wrote: post #14

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…

How do you feel about Hungarian notation?
Post reply on HN