Live data from Hacker News

Amazon Web Services in Plain English

expeditedssl.com

211–220 of 237 posts

Re: Amazon Web Services in Plain English

#211

Earlier quoted context omitted.

> At some point it makes sense, but it is way, way down the road for most startups. Thing is, unlike the "get driven to work" analogy, programmers/etc are in the same problem domain as the required services. It would be like a mechanic taking an Uber to his garage every day because he couldn't be bothered personally owning a car. What?! "Car leases" (rented dedicated servers [possibly even managed]) are a happy mediu…

> Thing is, unlike the "get driven to work" analogy, programmers/etc are in the same problem domain as the required services. But programmers should be focusing on delivering their startup's unique technology or service, not building and maintaining commodity infrastructure.

Yeah, I agree that initially, startups should focus on building value over lowering infrastructure costs.

But I'm continually embarrassed when companies who raised $100Mns in Series B funding continue to rely on AWS when they could have build out much sooner, and reduced their burn rate measurably.

Re: Amazon Web Services in Plain English

#212

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.

A good read and helpful list.

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.

Re: Amazon Web Services in Plain English

#213

Earlier quoted context omitted.

Nice list. Disagree with many of them, though. 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/User…

> S3 is not an FTP service it is a distributed object store. 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…

FTP is File Transfer Protocol. S3 is not for transferring files and it's not a protocol. It's a file bucket or object store is appropriate. I use S3 to store static content and then use Cloudfront as my CDN. I think comparing it to FTP is rather confusing to say the least. Static content includes things like html, css, javascript not just jpgs or what have you.

Re: Amazon Web Services in Plain English

#214

Earlier quoted context omitted.

How is "Object Store" marketing bs? What is the proper term for an S3 object? It's not file , because file is a term that comes from the context of a filesystem, which is what S3 is not. 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 straightforw…

So when I download a file from a website, I'm not actually downloading the file? Since it doesn't become a file until it gets flushed to disk by my browser? So what is the name for the sequence of bytes that are actually downloaded?

I'd say you don't really download the file, you render it in a browser via the http protocol. Downloading implies you have a local copy of the html file or js or whatever.

Re: Amazon Web Services in Plain English

#215

Earlier quoted context omitted.

> I agree that "object" makes no sense when applied to S3. It's not like you can store an "account" object and call a method to get back the current balance, with accrued interest for the time since last deposit added in. Or even store an image and call a method to get back a black-and-white version. Etc. Well, yes, they aren't OOP objects. But as you say, "files" isn't great either. But it was a theoretical alternat…

> 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.

No, it wouldn't make any sense at all.

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.

Re: Amazon Web Services in Plain English

#217

Earlier quoted context omitted.

How is "Object Store" marketing bs? What is the proper term for an S3 object? It's not file , because file is a term that comes from the context of a filesystem, which is what S3 is not. 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 straightforw…

So when I download a file from a website, I'm not actually downloading the file? Since it doesn't become a file until it gets flushed to disk by my browser? So what is the name for the sequence of bytes that are actually downloaded?

So what is the name for the sequence of bytes that are actually downloaded?

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.

Re: Amazon Web Services in Plain English

#218

Earlier quoted context omitted.

> S3 is not an FTP service it is a distributed object store. 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…

Maybe Simply... "Amazon File Server" ?

The main problem with that is that virtually all of Amazon's original target audience would have seen "Amazon File Server" and assumed it was a "File Server" like every other "file server" they'd ever heard of, which either exported a file system such as NFS or Samba or used ftp or http to serve files-- and in the latter case, calling it a "file server" rather than an ftp server or web server would be rare.

Since S3 was none of those things, they needed a different name.

Re: Amazon Web Services in Plain English

#219

Earlier quoted context omitted.

> S3 is not an FTP service it is a distributed object store. 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…

How about "Web File Server"? I think mentioning "FTP" in the "It's like" column is reasonable, but I thought it was confusing in the name.

Yeah I have no problem with drawing some comparisons to FTP. It's definitely like FTP in the sense that there's this step where you have to get the data you want to deal with then put it back; but that's really where the similarities end.

Re: Amazon Web Services in Plain English

#220

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.

This is great! One nitpick: I wouldn't say that SQS is like Sidekiq. Because sure, part of Sidekiq is a queue (in Redis), but the more important aspect of Sidekiq is the workers that operate on the queue. If you needed a second example I'd have gone with ZeroMQ.
Post reply on HN