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.
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.
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!).
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"
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.
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.
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!
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.
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...
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.
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.
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'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.
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".
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).
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?
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.
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.
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.
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.
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.