Hey HN, I wrote this, thanks for all the feedback. In particular if I've mischaracterized the functionality of a service or you see something that's really off please email me at mike@expeditedssl.com or just tell me here and I'll fix it.
> SWF -> Amazon EC2 Queue Use this to Build a service of "deciders" and "workers" on top of EC2 to accomplish a set task. Unlike SQS - logic is setup inside the service to determine how and what should happen.
I do not find this one to be that helpful, as "deciders" and "workers" doesn't make sense in this context. Logic isn't encapsulated inside of SWF, and the workers do not need to be hosted on EC2. SWF basically tracks workflow and activity versions, and is essentially a state management and work distribution system. It distributes out tasks to polling workers based on what the workers are polling, and what state is currently in SWF.
I think a (possibly) better name/use this to would be Amazon Task Orchestrator/Schedule and run jobs that do a bunch of things in order that can be distributed, where you want to run the workers on either EC2 or your own machines.
Ok, maybe not too much better, but I think it shows the use case a little bit better.
I really like this concept of a product TLDR. It reminds me of https://tldrlegal.com/. I wish these sorts of summaries were available for other software products and services. It would help when trying to get a simple understanding of all the buzzwords that I can't keep up with without having to read pages of documentation or look at examples.
It is a general messaging service and can deliver messages to SQS, AWS Lambda, email and arbitrary HTTP(S) endpoints.
For example, we have some S3 buckets set up to send an SNS message to an SNS topic on new object creation, the topic then in turn notifies our subscribed HTTPS endpoints by sending the SNS message which we can then parse. You can also connect S3 directly to AWS Lambda so that a new event in the bucket sends an SNS message to a lambda function - which is very handy for doing things such as "server-less" thumbnailing, transcoding, etc etc.
I was trying to write this from the standpoint of describing what the services did to another developer in a really high level way.
If you want a high level explanation for someone, I'd describe it as Amazon Callbacks. It lets you create callbacks for any action in and across any Amazon web service, where that callback can be in the form of an HTTP post (e.g. back to your web application), email, push notification, etc.
Sounds like a good fit as an open source documentation project for a dedicated group of platform researchers to knock out collaboratively in a month.
EC2/"Amazon Virtual Servers" - true today, perhaps. But when EC2 first launched, they were trying hard to sell the "elasticity" and "pay for what you use" aspects, which were unique at the time. There were no EBS volumes, the storage was all ephemeral. While it was possible to use EC2 instances as virtual servers, that was really not what they were designed for.
IAM/Users Keys and Certs - I agree that IAM is a bad name, but it's still useful to distinguish between aws API authentication and other kinds of authentication. Say "IAM" in a conversation and people will immediately know what you're talking about. Say "Users, Keys and Certs" and you'll have to keep distinguishing between certs for your websites, OS host keys, and that kind of thing.
S3/"Amazon Unlimited FTP Server" - Sorry but this one would just be very misleading. S3 is not an FTP service it is a distributed object store.
VPC/Virtual Colocated Rack" - Again I think using words like colocation and rack would just be misleading. VPC gives you software-defined networking. I think the real issue here is that amazon missed the mark just a little in the original design. VPC should have been the default mode of operation, where the initial VPC was transparent and got a default name. Not a big mistake in the long run but it did mean they had to deploy and name a new service.
RDS/Amazon SQL - I think "Relational Database Service" should be easily understood by any developer using a relational database. If you don't know that MySQL, Postgres, and Oracle are relational databases, consider this the right time to learn.
SQS/Amazon Queue: "Simple Queue Service" is basically the same as "Amazon Queue" except that it uses the same naming convention as S3 so that it's easily recognized as an AWS service rather than some generic amazon store feature.
Elastic Map Reduce/Hadooper: I think "Map Reduce" is much plainer English than "Hadooper."
CodeCommit/Amazon Github: This would be a blatant trademark violation. Also implies that it's less "plain English" given that Github is a proper noun and not a straightforward description of a service. I don't love "CodeCommit" but can't immediately think of anything better.
Not really, the only "object" you can store, Amazon's language notwithstanding, is effectively a file. It's not like you could give it something that needed to be serialized.
And it's hard to see how it's "distributed" when your bucket price varies "based on the location of your bucket" as Amazon puts it.
It's probably more redundant than FTP, but saying S3 is like FTP is a reasonable shorthand and cuts through a lot of the marketing BS.
> It's probably more redundant than FTP
FTP is a transfer protocol, it says nothing about redundancy of the data on the back end. You could put an FTP server in front of an ext4 filesystem, and NTFS filesystem, an NFS mount, or maybe even S3.
"File Server" or something like that would be better. You're quite right that "Object" is worthless terminology in this case - "Object" is basically nerdspeak for "thing".
This is a common issue in computer science and software development. Whenever new concepts are discovered or developed, they often need new names. You need to pick something that will distinguish this new concept from existing technologies. For laughs (kind of), look at configuration management software (Chef, Puppet, Cfengine, Ansible). They all quickly discovered that there were a whole bunch of new concepts that needed names, and while in some cases this hints that maybe these tools a bit over-engineered, it's hard to deny they've been popular and useful. Regardless, they all encountered these new concepts around the same time and they all made up their own names for them. So in chef you have cookbooks, where ansible has roles. Chef has roles where ansible has playbooks. Ansible has modules where puppet has providers and resource types. Ansible has tasks which are basically components of what chef would call a recipe and puppet would call a manifest.
All in all, I think "object storage" is a pretty fair term for the concept of a data store that neither heirarchical or sequential.
Calling it a "file server" is way more reasonable.
IMNHO "File server" implies it exports an actual file-system, and would also be wrong. In that light, I think S3 is more like FTP than a "file server". Sure, it might technically be more like WebDAV than FTP, perhaps "FTP-like service using HTTP for transport" is more accurate -- but I'm not sure it's better than just calling it FTP...
"S3 - Simple Storage Service" describes pretty well what the point of the service is without making strong claims around what it may or may not be. It's a service for storing things; it's not a database or a filesystem. The devil is in the details of course but even when I was really new to cloud services I got the gist of what S3 was supposed to do.
Well, yes, they aren't OOP objects. But as you say, "files" isn't great either. But it was a theoretical alternative. For example, you could do a search/replace on the S3 docs here: http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingObjects...., and they would still make sense.
But FTP isn't even close. You could not find/replace "Object" with "FTP" without making those docs completely incoherent.
That's the wrong comparison though. You could replace all instances of "S3" with "an FTP server" and it would make a ton of sense, minus the reliability claims.
Amazon Unlimited FTP Server is a simple key, value store designed to store as many FTP Servers as you want. You store these FTP Servers in one or more buckets. An FTP Server consists of the following:
You could use a mix of "FTP Server" and File:
Amazon Unlimited FTP Server is a simple key, value store designed to store as many files as you want. You store these files in one or more buckets. A file consists of the following:
Note that this is essentially redefining the word file to include S3-specific metadata.
Read the S3 docs: http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingObjects....
That is the technical term they've chosen to describe the key, its value, and all its associated metadata. As far as terms go, it's rather straightforward, in my opinion. They probably didn't use "file" because that usually implies a filesystem, which is specifically what S3 is not.
Also, go ahead and check out the history of the term "Object Store": https://en.wikipedia.org/wiki/Object_storage
If you explicitly requested your browser to create a file, then it could be any kind of data. If the web server triggered the download, your browser probably saw an HTTP header like "Content-type: application/octet-stream"
I will admit that there is an abstract concept of a "file" that exists outside the restricted realm of a "filesystem," but that's not amazon's target audience. Their target audience are programmers using APIs.
To a normal person, MySpreadsheet.xls is considered a file, no matter where it is stored. But S3 is not limited to this definition of file. An S3 object does not have to be a file in the sense of an excel spreadsheet or digital photos from your friend's wedding. An S3 object can just be a sequence of random data, which would be called a file if stored as ".dat" in a filesystem, but is not considered a file in the same abstract sense as a Word Document.
From a programming perspective files tend to come with a number of traits, like options for sequential access, random access, or appending. A file can often be modified without re-writing the entire thing. When you are programming with S3 objects, the only way to "append" something is to GET the object, retrieve the value from the object, append the data to that value, and then use PUT to upload entire object back into S3.
In this way, it is similar to FTP, except that FTP is most definitely about files and filesystems. S3 is not just for downloading files, but for retrieving any kind of data, usually directly into an application.
Given that S3's target audience is software developers, the programming version of the term "file" is more appropriate.
It's not like "Simple Storage Service" is weirdly obscure or anything.
It's not "Amazon's language"...your thinking is too programming-language-centric. Object has a much more general meaning. Amazon didn't invent the term blob (binary large object) and S3 is basically a blob store.
Since S3 was none of those things, they needed a different name.
I'd like to help contribute to this if possible.
Disclosure : I am Founder of oauth.io to what Cognito is compare.
Could you add the pricing model and notes? It seems to me that the pricing infos are always hidden somewhere and very hard to find out until you actually used them.