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

Amazon Web Services In Plain English (2019)

web3us.com

Post reply on HN
Print view View original

51–60 of 93 posts

Re: Amazon Web Services In Plain English (2019)

#51

Post by dylan604 »

adambatkin wrote: post #8

IAM "Should have been called Users, Keys and Certs" That's funny. Because we have hundreds of developers using AWS every day, using IAM all the time, and never using a single IAM User. IAM is actually named extremely well. identity and Access Management. I can't think of a better name. And if your problem is that you just don't like acronyms, you probably picked the wrong industry.

>And if your problem is that you just don't like acronyms, you probably picked the wrong industry.

Maybe they should try the military? I hear they only use acronyms occasionally!

Re: Amazon Web Services In Plain English (2019)

#52

Post by dylan604 »

stingraycharles wrote: post #13
adambatkin wrote: post #8

IAM "Should have been called Users, Keys and Certs" That's funny. Because we have hundreds of developers using AWS every day, using IAM all the time, and never using a single IAM User. IAM is actually named extremely well. identity and Access Management. I can't think of a better name. And if your problem is that you just don't like acronyms, you probably picked the wrong industry.

Agreed. “Users, Keys and Certs” neglects the whole roles / permissions aspects of IAM, which in my experience is by far the larger part of IAM. The users & keys part is actually just a tiny part of it.

It just shows that someone is writing something from their personal perspective and thinks the rest of the world should conform to their view points. Also, it really sounds like a recent cloud "convert" trying to make hay as a thought leader (which is a phrase that makes me want to hurl), all the while revealing their ignorance as not fully understand the topic at hand. In other words, typical blogosphere crap (even though this isn't really a blog, just a syndrome).

Re: Amazon Web Services In Plain English (2019)

#53

Post by dylan604 »

flatiron wrote: post #18
dijit wrote: post #12

Earlier quoted context omitted.

Amazon Queue Service. Or pubsub.

Having them start everything with “Amazon” would put them in the “kde” league of everything stupidly starting with k for no reason other than to start with k.

yeah, but intentionally misspelling words to include a silent 'k' is a fun gimmicy thing. GNU does similar do they gnot?

Re: Amazon Web Services In Plain English (2019)

#54

Post by jmcgough »

mrfusion wrote: post #41

I still don’t get beanstalk? A drop in replacement for heroku?

Heroku is a good comparison. Beanstalk is a way to specify the resources you need without needing to understand aws very well - AWS automagically provisions things for you and replaces instances when they become unhealthy. Compare to CloudFront, which as the declarative way to specify what you need but requires you to know AWS in depth.

Re: Amazon Web Services In Plain English (2019)

#55

Post by hn_throwaway_99 »

chrsig wrote: post #43
hn_throwaway_99 wrote: post #33

The problem I have with these renamed is that by "simplifying" the name, they often cut out major pieces of functionality. The original names are at least "brandable" so that when I think of that name, I think of the entire suite of functionality. Some examples: 1. IAM -> Users, Keys and Certs. But other commenters have already pointed out this leaves out the whole roles, permissioning and policies that is really the…

I can certainly agree that some of those descriptions don't fully encompass what you're getting. Some of your points are more picking at the authors choice of simplifying language, rather than the effort to simplify the names themselves. Some of the names are completely uninformative though -- cognito for example doesn't convey anything about oauth. Neptune doesn't make me think graph database. Kinesis doesn't make m…

> Some of the names are completely uninformative though -- cognito for example doesn't convey anything about oauth.

That's kind of the point, though. A "brandable" name is something that generally evokes what the service does, but is not so limited that it only specifies the exact features at the time of initial release.

I mean, by the author's logic, Amazon itself should have been called Internet Book Store. Which name do you think would have been more successful?

Re: Amazon Web Services In Plain English (2019)

#57

Post by chrsig »

dylan604 wrote: post #50
chrsig wrote: post #43

Earlier quoted context omitted.

I can certainly agree that some of those descriptions don't fully encompass what you're getting. Some of your points are more picking at the authors choice of simplifying language, rather than the effort to simplify the names themselves. Some of the names are completely uninformative though -- cognito for example doesn't convey anything about oauth. Neptune doesn't make me think graph database. Kinesis doesn't make m…

>Some of the names are completely uninformative though Does Microsoft make you think computer OS? Does Apple make you think of computers and personal devices? Do common names Alexa/Siri mean anything specific to you? None of the words used in those examples have anything to do with what they do, but they are now synonymous with everything you think of when those words are spoken/written. That's because the companies…

I get the point, that with sufficient branding to a target audience, the issue is negated, but I think you're conflating branding for a corporation with branding for niche products. The level of effort put into branding the corporation at large versus the level of branding for any individual service is orders of magnitude apart.

Importantly, with AWS, there's dozens of services, all competing for a three letter address space. It's getting saturated, so it's easier and easier to get confused.

> Sure, not everyone will need EKS and it becomes more esoteric, but people that do it day-to-day know exactly what EKS is.

This is sort of my point. I work with kubernetes and kafka. The kafka instance that I connect to is managed, the k8s cluster I deploy to is not. I can't tell you off the top of my head if EKS is managed k8s or managed kafka. That was the breaking point for me to stop putting effort into trying to remember.

I have pretty severe ADHD, so I can accept that I'm probably outside a standard deviation as far as ability to remember three letter acronyms, but I think I still stand as a contradiction to your assertion.

Re: Amazon Web Services In Plain English (2019)

#60

Post by adambatkin »

Traster wrote: post #5

Some of these are clearly deliberate obfuscation. I need something to handle Queues, what should I use? Amazon SQS obviously. Oh cool, what’s that? It’s a Queue service! Oh great, why is called SQS? Simple Queue Service duh! Is there a more complex queuing service? No. There’s only SQS. The acronym is totally useless, tells you nothing beyond it being for Queues and completely obfuscates what’s happening for anyone n…

AWS offers a bunch of different queue-like services: SQS, Kinesis, MSK, Amazon MQ (supporting both ActiveMQ and RabbitMQ).

I don't think it's possible to build a queue-as-a-service that is any simpler than SQS, so there is literally no better name than SQS. (also, the suggested name "Amazon Queue" is pretty similar to the name "Amazon MQ" which does in fact exist)

It's a queue. It supports enqueue and dequeue. And that's pretty much it. It's a Simple Queue Service.

Post reply on HN