Amazon Web Services in Plain English (2015) | Hacker News Reader

Amazon Web Services in Plain English (2015)

expeditedssl.com

655 pointsapsec11275 comments

Hey, Author here. This is old and I haven't added some of the new services that AWS has released since I first wrote it.

Whenever this list comes up there's generally a group of people that dislike it for trying to be at least mildly humorous (The whole concept for it started with my developer friends and I joking about some of the names and how opaque they were, so not sure what I'm supposed to do).

There were a couple substantial edits I made to it where a few funny lines were cut in favor of better explaining what/how something worked.

I also started fleshing out some of the services with slightly more in-depth articles about them (such as this discussion of AWS Buckets where I compare Amazon's CTO to a character from 28 Days Later - https://www.expeditedssl.com/aws-s3-buckets-of-objects

I've sometimes thought that I should try and make it into an ebook or something, but there's always been something more interesting to work on. Thanks to everyone who has enjoyed it, shared it with their friends and hopefully took their first steps to messing around with AWS.

Just a suggestion here from someone who has enjoyed this. I don't think you should edit out the funny stuff. That gives it flavour. I think it can still easily function as a serious reference while keeping the humour.

Quite the contrary actually, it should have more humour.

Seconded :-D

Agreed. Humor should not obscure the meaning, but the idea that tech docs should be completely dry and never try even a little fun seems misguided to me. On the contrary, there are studies that suggest funny and a little weird things are remembered better than completely ordinary dry facts (in fact, there are mnemonic techniques based on that), so injecting a little fun may be very beneficial.

> This is old and I haven't added some of the new services that AWS has released since I first wrote it.

When did you first write it? I didn't notice a date on the page. That might be a useful addition to the page.

All pages should have dates on them.

I came across this a while back, and really enjoyed the way you laid your site out and explained the different services. I've been using AWS for many years, so was familiar with a lot of things already, but I did learn a few new things from you, which was great.

I hope you do spend more time to update this with the newer releases from Amazon. I find that in the console now, it has got to the stage that I cannot easily find the services I need in their drop down. (Yup, I know they recently redesigned the drop down to showcase thing a lot more clearly, but there is still SO much on there that I resort to the search function now, because I know the name of the service I am after, but it is actually quicker for me to type the name than to hunt for it in the list!).

Why not open source itand accept PRs. You still get control and people can help keep it up to date?

Opinion seems split pretty evenly between: "You should make it funnier" and "This is irresponsible and wrong because you don't explain XYZ nuance of each service"

I don't feel like litigating that through PRs.

Well you might not have to, people who dislike it can fork it

It would be funny to redo the icons also. I like how the shortcut bar gives you the option to use only the icons, as if anyone can remember more than zero of them.

I’ve been saying “files” up until now and it’s really “objects” that are stored in S3 ... list of unique names (that typically look like filename paths) and then there are the actual bits (which are the objects we call files)

not sure what the difference is. all local files on your HD also abide by these same rules. if you want to use any file you have to open it which ends up as a block of bits in memory

The important distinction is that there is no true file hierarchy and no tree traversal for object search. This has material impact on using s3 as a file system.

The almost immediate modal pop-up on those pages is pretty annoying. It's just as easy (if not easier) to close the page rather than the overlay.

The problem with these intrusive tactics is literally the next thread on HN right now: https://news.ycombinator.com/item?id=13439828

Very sorry about that, something wasn't working right. I just removed it.

I agree, but on more fundamental level, the problem with these intrusive is that users are penalizing (mobile) websites with intrusive pop-up ads, usually by closing them, or sometimes, by adblock.

Great article! Could be worthwhile to provide a reference to the 'Cloud-Based Enterprise Pub-Sub Messaging' element of SNS? It does a bit more than just 'Send mobile notifications, emails and/or SMS messages' Current value: 'Should have been called Amazon Messenger' / Potential replacement: 'Should have been called Amazon Message Delivery Service' Current value: 'Use this to send mobile notifications, emails and/or SMS messages' / Potential replacement: 'Use this to send mobile notifications, emails and/or SMS messages or notifications to other web applications'

For what it's worth, the layout is somewhat broken for mobile browsers (tested with 360 px width): The table is too wide and bleeds out of the viewport, hiding parts of the text. Maybe you can make it horizontally scrollable or something.

To be honest a lot of those characters weren't really worth reading anyway, but I'll see what I can do.

Your humor from the website is bleeding to HN sire :-)

I like it :-)

I get a lot of flak for writing humorous things to keep one target audience interested in the topic at all, but getting picked up by a super serious target audience.

Basically the only I read this is because it was funny... I happened to accidentally learn a thing or 2 but that wasn't my intention. Please, humor it up!

I love this and the azure version. Refer to them from time to time. Thank you for taking to effort,don't worry about the detractors!

Not a bad stab at it, but SNS is not just for mobile notifications (and I hate that they always put it under "mobile"), and SQS is not "like" RabbitMQ. You need SNS -> SQS to get that analogy right. We have dozens of SNS topics and 3-4x that number of SQS queues subbed to them in order to replicate our old flaky RabbitMQ stack. We have never used them for "push notifications", and in fact when I've tried using SNS for that in the past, it did not scale very elegantly at all.

ElastiCache is not "AWS Memcache" (it supports other caching services), and S3 is not "unlimited FTP" (it does not support FTP protocols).

Amazon RDS is not Amazon SQL (that's what they should have called Aurora), but Amazon Hosted RDBMS.

I'd also argue that EC2 isn't always a virtual server (once you get to a certain size, you're on your own iron), and that SES can be used for more than transactional emails.

But, that aside, not a bad job.

I do think this is mainly aimed at developers used to more basic SaaS/PaaS services (like Heroku, which was mentioned a few times). Coming from that angle it really doesn't matter that S3 is not technically FTP, since it's more about "What do I use this for?". Using this list these users can quickly see that if they want to host files they should use S3 and not EC2.

You are right that this simplification is not technically correct anymore.

I really like it. A (stupid) suggestion for the AWS Scripts description ;-). It's like a Database trigger; but applied to events on the Amazon stack...

I link to your work in all my new hire kits.

This is really useful for a layman like me who doesn't have a lot of exposure to AWS.

Anything similiar for Azure? I would really like to understand the difference between the different types of app services, and especially how they relate to the project templates in Visual Studio.

https://www.expeditedssl.com/azure-in-plain-english

That's a good high-level list, although the comparisons don't always match up. For example, I'd say Traffic Manager is more like Route 53 than ELB (which only works within a region).

If you're after something a bit more in-depth (but covering less services) then I wrote a three part series last year. It may be a little out-of-date, but most of it still applies. Azure now supports MySQL, for example.

1: https://unop.uk/on-aws-vs-azure-vendor-lock-in-and-pricing-c...

2: https://unop.uk/on-aws-vs-azure-vendor-lock-in-and-pricing-c...

3: https://unop.uk/on-aws-vs-azure-vendor-lock-in-and-pricing-c...

Edit: Should that "puts da" be on that page?

Sadly that one try to be a little too funny.

For example: Express Route - "Should have been called Pretty good" that not really helpful. It should have been called "Azure MPLS" or "Azure direct connect"

I understood that as "that's already a pretty good name".

I'd say if you haven't had a lot of exposure to AWS, this list is likely to give you a misleading impression in many cases; many items are either factually or taxonomically wrong, or grossly oversimplified to force them into a particular category, or confuse the underlying implementation (or even unverified assumptions about the underlying implementation) for the service offering. There are also some surprising omissions, like ELB/ALB or KMS, and some impossible and even self-defeating suggestions, like using someone else's trademark (again, with questionable validaty).

It's especially misleading if, as you say, you want to understand differences between AWS and Azure services, because that sometimes comes down to nuances.

So I recommend treating it as humorous parody, not documentation. It is a little bit amusing if you're already in the know.

Source: I'm ex-AWS.

Calling S3 "FTP" is a bit misleading, I would have just called it "File Storage" and explained it along the lines of FTP instead.

I agree. Alternatively they should have never used a silly acronym "S3" and just stuck with the full name: "Simple Storage Service".

well there is a genuine need for a short url. But instead of aws.amazon.com/s3 I would say aws.amazon.com/storage would have been a good tradeoff, and similarly for the other services just use the dictionary word of the service. "AWS" already has "service" in the acronym, so no need to repeat "S" or "service" for every sub-service of "Amazon Web Services".

S3 = two characters and two syllables

Simple Storage Service = twenty-two characters and six syllables

Given how much it's used in discussions around online storage, the former is definitely preferable. The fully spelled-out name is really only useful to ultra-newbies, and not to anyone with even a hint of experience in the product. Not much gained there.

I just discovered a bunch of interesting stuff that I had no idea AWS provided thanks to the cryptic names. Most notable is Elastic Beanstalk - had no idea that was a PaaS!

GCP does not really need one of these. It is a lot easier to understand. The only time it gets confusing for people are the papers or projects they were based on (e.g. StackDriver, BigTable, etc).

I would highly recommend this resource for further reading.

https://github.com/open-guides/og-aws

Do we have the same for Microsoft products? Even as a developer, I can't understand half of what they're proposing. Like what the hell is Sharepoint anyway?

Or what is SAP?

Microsoft has never been understandable. I tried to find an overview of dot net on their site, when dot net was at 1.x and was going to cure world hunger, but I wasn't able to understand what they meant by the '.net platform'. Gave up after an hour.

.net been many things over the years and included many things. I guess if there was a definition at it's core (no pun intended) it's a managed code runtime with an associated set of libraries and framework to develop applications. But it's also a brand name for Microsoft development tools and frameworks. But it's very much not precise in how it's used by MS itself.

Does anyone know who are the bunch of geniuses that come up with the names and decide upon what to use? World deserve to know about them.

Developers generally have problems in two areas: naming things, regex, and off by one errors.

Don't think Amazon would allow developers to name products or is it that their marketing team is just retired developers.

It's worth noting on the SES explanation it says:

>You could use it to send a newsletter if you wrote all the code, but that's not a great idea.

You actually can use a self hosted solution like Sendy to send marketing emails & newsletters via SES & only pay for the emails you send using SES

I recommend mailtrain for sending news letters

Still wondering why AWS does not provide a solid PaaS solution like Heroku does (they are on AWS, though) - or am I just overlooking it? I would like to host a few node.js/Clojure apps but I don't want to have the hassle with virtual machines/IaaS.

ElasticBeanstalk is their PAAS-like solution. I still tend to build out things with Heroku as the central point and slot in AWS services as they make sense.

I looked at ElasticBeanstalk back then, and - frankly - to me it sounds like an overcomplicated PaaS product. If I understood it correctly, they basically "just" tie together a bunch of services for you. I was expecting something as simple as Heroku, actually.

I would encourage you to take another look at it. You are right in that it basically ties services together (mainly EC2 and RDS), but it does give you an option of starting and deploying a Ruby or Node.js project from the command line and taking care of all the details for you.

(In fact, you don't HAVE to tie services together that you don't need. If you have a separate RDS instance already that you want to use, you can tell your Elastic Beanstalk project to use that instead of creating a new one).

I use Elastic Beanstalk for all my projects now, and like how I can deploy from Git repositories so easily with a single command. Granted the interface isn't as easy as Heroku, but you have the bonus of added configurability in your apps.

That sounds indeed better than I thought. I will definitely give it try.

Elastic Beanstalk and now Lightsail.

Lightsail isn't really a PaaS, it's a 'simplified' rebranding of EC2.

Thanks. <3 Can you also rewrite all tutorials please?

NoSQL Parody: https://youtu.be/fXc-QDJBXpw

It would be cool if someone did a similar thing for the Apache Big Data projects.

I was going to volunteer, but sheesh: https://projects.apache.org/projects.html

The list of just "big data" projects is somewhat smaller

https://projects.apache.org/projects.html?category#big-data

Wonder what the vmware service on Amazon will be called - maybe Elastiware

This is very annoying to read on my S6 in chrome 55.0.2883.91

> Code Deploy > Should have been called: Not bad

The one service name that's self declared.

Judging by the Direct Connect one further down I think "Not Bad" was more of a comment on the name rather than a suggestion for another.

(2016)

https://news.ycombinator.com/item?id=10202286

Broken on mobile.

Looks good on my Nexus 5x -- I had to rotate the phone in landscape mode first though :)

Doesn't look good on my Google Pixel :/

Someone needs to teach expeditedssl.com how to build a website in 2017 that can also be consumed on mobile without content being cut out.

Machine Learning Should have been called Skynet

Updoot, because I was thinking just the other day how absurd Amazon's naming scheme is. Did an engineer think of that sh#!? If Amazon was run by Musk instead of Besos, a harsh email would have been sent to the employees to cut that sh#! out.

Source: Acronyms seriously suck https://twitter.com/davejohnson/status/602951117413216256

There's something particularly grating about your comment. From the 'updoot' to the fetishization of Elon Musk.

Actually the poster makes a good point about how when organizations excessively make acronyms, they can actually hamper communication and efficiency. I read the link, and I think Elon Musk makes some great points, so I don't think the poster's praise of Elon Musk should be criticized as a "fetisization", and I don't think the poster deserves so many down votes.

Although to be honest, I did have to look up "updoot" in the Urban Dictionary :), so to be fair I should say unnecessary use of urban slang can also hamper communication.

The military uses acronyms heavily. The seem to be still in business.

Reply on news.ycombinator.com