Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Amazon Web Services in Plain English

expeditedssl.com

Post reply on HN
Print view View original

121–130 of 237 posts

Re: Amazon Web Services in Plain English

#121

Post by Goladus »

michaelbuckbee wrote: post #67

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.

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

Re: Amazon Web Services in Plain English

#122

Post by tobz »

decwakeboarder wrote: post #88
tobz wrote: post #80

Earlier quoted context omitted.

Spitball some calculations? You can start with just a few EC2 instances, so conceivably, you could everything on those you'd do with a VPS. Maybe you decide that managing a database is taking too much of your time, so now you're looking at RDS. It's more expensive, but, it manages just about everything for you. Maybe you make the decision to switch to RDS Now you turn down that EC2 instance running your database. May…

We all just wing it. The good thing is that services and charges that are hard to estimate (SQS, egress network bandwidth, S3 access charges) are mostly drops in a bucket compared to those that are easy to plan for (ec2, RDS, S3 / Dynamo storage).

Right. There's a lot of simple choices you can make -- SQS instead of RabbitMQ, ELBs instead of HAProxy -- that aren't going to cut your burn rate in half or anything.

The estimation part is definitely very hard to do for the things you mentioned at the end, especially things like DynamoDB which want you to specify throughput. Not only do you spend time on that, you then spend time on handling when you exceed your provisioned throughput, etc. There's a lot of time spent thinking about shit there.

Anywho, I agree overall. Some of their services just make sense to use because you'll be hard pressed to paint yourself into a corner with them.

Re: Amazon Web Services in Plain English

#123

Post by Goladus »

ahallock wrote: post #104
snorkel wrote: post #66

Whoa errors! * S3 is not FTP. It's more like static web hosting and storage. * VPC is not a "colocated rack" as it doesn't offer physical placement of hardware. Amazon VLAN would be a better name. It's just private network address space.

FTP is a good analogy. A lot of people are familiar with FTP, and given a good s3 client, it appears the same.

I guess for people who don't understand what FTP really is, and wouldn't find it valuable to understand what S3 really is.

Re: Amazon Web Services in Plain English

#124

Post by mapgrep »

Goladus wrote: post #121
michaelbuckbee wrote: post #67

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.

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 is like FTP is a reasonable shorthand and cuts through a lot of the marketing BS.

Re: Amazon Web Services in Plain English

#126

Post by johansch »

jimbokun wrote: post #114
jpatokal wrote: post #64

Earlier quoted context omitted.

https://cloud.google.com/free-trial/docs/map-aws-google-clou... You're welcome!

The Google names seem to be much closer to the "should have been called" names from the article.

I have started researching both AWS and Google Cloud services over the past couple of months.

My clear favorite is Google. Things are generally simpler (in a good, well-designed way). I get the feeling smart hackers are designing things.

With AWS, the general feeling is that is designed by bureaucrats, the type of people who like big, slow and boring companies.

Re: Amazon Web Services in Plain English

#127

Post by patsplat »

genericacct wrote: post #97
michaelbuckbee wrote: post #67

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.

Cognito is probably more like "oauth and backends for your apps"

My primary understanding of Cognito was that it was a great way to turn social or developer login into temporary AWS credentials with a specified role, allowing AWS apis to be safely used client side.

Re: Amazon Web Services in Plain English

#128

Post by Goladus »

mapgrep wrote: post #124
Goladus wrote: post #121

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…

The only real resemblance at all to FTP is that you use GET and PUT instead of filesystem commands. I mean, I guess if you really don't understand what FTP is and have no desire to understand how S3 is different from posix, then saying you have to use S3 like you use FTP kind of works. But it would be misleading to everyone else.

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

Re: Amazon Web Services in Plain English

#129

Post by stephenr »

athrun wrote: post #47
stephenr wrote: post #37

Earlier quoted context omitted.

Except when they suffer huge outages because of some upstream issue and HN/twitter/etc go stupid with "omg half the internet is offline" because everyone thinks AWS is indestructible. AWS makes even less sense at scale than it does for small companies. Once you can afford to hire competent Ops staff (and assuming you don't have developers who insist they know everything needed to run a complex system in a high traffi…

"Once you can afford to hire competent Ops staff" Here, that's the catch. Most companies simply can't. Competing against Amazon, Microsoft and Google for talent doesn't sound like a smart strategy.

Plenty of medium sized companies would work out better off overall, with a skilled Ops person to setup cost effective services

> Competing against Amazon, Microsoft and Google for talent doesn't sound like a smart strategy.

You don't have to compete. They are trying to make a profit. You just need to be better off, long term. That could be a mixture of lower service fees, more flexibility, improved productivity, less vendor lock in, etc.

Relying on any single company's services, particularly for key/essential systems your business relies on, doesn't sound like a smart strategy.

Post reply on HN