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

31–40 of 93 posts

Re: Amazon Web Services In Plain English (2019)

#31

Post by hn_throwaway_99 »

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…

> Is there a more complex queuing service? No. There’s only SQS.

Actually, there is, it's called AWS Kinesis.

Re: Amazon Web Services In Plain English (2019)

#32

Post by calvinmorrison »

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.

KuqueServive

Re: Amazon Web Services In Plain English (2019)

#33

Post by hn_throwaway_99 »

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 core of IAM.

2. S3 -> Amazon Unlimited FTP Server would imply to me that S3 actually just follows the FTP protocol, which is totally false.

3. Lambda -> AWS App Scripts. I have news for the author, but I know some companies and architectures that use Lambda as a basis for an entire serverless infrastructure, a heck of a lot more than "little scripts", e.g. serving whole websites.

4. Cognito -> Amazon OAuth as a Service - except many companies use it to store plain user accounts (e.g. username and password), not just setting up OAuth for accounts managed elsewhere.

5. SNS -> Amazon Messenger. But SNS can be used for a lot more than just sending emails, texts or push notifications. For example, it can be used to trigger lambdas. "Notification Service" seems to much better encompass the generic nature of the notification handling that SNS provides.

Re: Amazon Web Services In Plain English (2019)

#35

Post by SavantIdiot »

I'd like someone to do one of these for Policies. Every time I need to tweak an IAM or an S3 or a permission, I have to write a policy. I never quite know what I'm doing, but I get it to work. I'd really like a hand-held walkthrough of why policies are written that way, and how to write one without accidentally footbulleting myself.

Re: Amazon Web Services In Plain English (2019)

#36

Post by lukevp »

anonymoushn wrote: post #21
chrisan wrote: post #10

VPC: Amazon Virtual Colocated Rack What in the world? Why would I want a rack in the world of a cloud. I want a virtualized private cloud, which not so oddly is named Virtual Private Cloud. I feel like the person who wrote this got into web dev back when I started in the 90s, then never left the time frame. This dude, much like this webpage, clearly have not kept up with the times

What is a virtualized private cloud?

A colocated rack is a much more limited concept than a VPC. VPCs let your architect an entire network. You can have multiple private and public subnets, set security groups to filter traffic between them, do service discovery, use policy based access control, health check load balance, and host PaaS entities into the network (like Aurora serverless). On top of that, you can flex your compute. VPC is more like a rack with a firewall, an f5, a smart switch with vlans, something like kubernetes to automatically scale compute… but there are things that aren’t even possible in a rack because you can transparently both manage your own compute with ec2 and add PaaS managed offerings like RDS, elasticsearch, kafka, etc. all to the same network.

Re: Amazon Web Services In Plain English (2019)

#37

Post by NikolaNovak »

fnord77 wrote: post #26
staticassertion wrote: post #7

What's in a name? Really, is "Amazon Virtual Servers" much better than "Elastic Compute" ? Maybe slightly. But at the end of the day you have to go look at it and see wtf that means no matter what, and the 'elastic' verbiage is fairly consistent across AWS products. IAM is similarly not that bad - Identity Access Management pretty much tells me what it is. When we have a field where things are named in extremely uncl…

maybe it's an issue with my neurology, but for me if the name isn't descriptive it takes me longer to make association between the name and what it actually is. with "Virtual Servers", I would have only had to look it up once. With "Elastic Computer" it took me months of rereading what that service was for it to sink in.

That's fascinating and shows how different people are. I'm completely opposite! If you name something "gnorf" or "harjblang" and give me a definition, it occupies a specific unique place in my mind and I can learn memorize use and associate it.

With generic terms using generic words making up significant phrases, my mind struggles mightily, whether that's virtual private servers or integrated change control or steering rack control arm... This incidentally is why I struggle to learn any e.g. Car mechanics in English because it's all regular words strung up together Instead of bespoke unique keywords

Re: Amazon Web Services In Plain English (2019)

#38

Post by oneplane »

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…

It is neither 'clearly' nor 'deliberate' or 'obfuscation'. It is possible that you personally simply do not understand all the terms or definitions, that is a different story.

If you want to 'queue' things, there are many options, including a number of options hosted by AWS as-a-service. For quite a long time a 'queue' hasn't really been a 'queue'.

There is SQS, the simplest of them all. There is MSK, which is Apache Kafka, but managed, so you don't have to deal with it yourself. There is Kinesis Streams and Kinesis Firehose, which is like a many-to-one queue, there is a hosted ActiveMQ, which is more complicated than just a 'simple' queue, and then we have Redis which gets used as a queue by plenty of libraries, and there is a set of services that you can use to 'construct' queues, like EMR, Glue, Airflow, Data Pipeline etc. You can also construct a queue out of generic hosted services by combining S3, EventBridge, Step Functions and Lambdas.

So no, it is not totally useless as a name or as an acronym, and to add insult to injury: if you are not in the ecosystem you are probably not even close to the target audience. Just because you don't know something doesn't mean it therefore must be bad. You probably don't know what T&E is in the physical world, that doesn't mean it's a useless acronym or shorthand, it just means it's not for you. (It's Twin & Earth, used in a lot of domestic electrical installations)

Most of AWS isn't for random people off of the street to immediately jump in to. Neither is flying jumbojets, surgery, or recombinant DNA engineering.

Re: Amazon Web Services In Plain English (2019)

#39

Post by TimTheTinker »

chrisan wrote: post #10

VPC: Amazon Virtual Colocated Rack What in the world? Why would I want a rack in the world of a cloud. I want a virtualized private cloud, which not so oddly is named Virtual Private Cloud. I feel like the person who wrote this got into web dev back when I started in the 90s, then never left the time frame. This dude, much like this webpage, clearly have not kept up with the times

Maybe you're not the intended audience. It can get exhausting to keep up with the (new) times and learn a new stack again.

I'm on my fourth or fifth time and it's starting to get wearying. I'm glad I'm not building simple PHP apps on MySQL anymore, but a new AWS whatchamacallit gets little more than a groan from me.

Post reply on HN