Live data from Hacker News

Amazon Web Services in Plain English

expeditedssl.com

81–90 of 237 posts

Re: Amazon Web Services in Plain English

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

Whoa pedantry.

It's fine the way it is.

Re: Amazon Web Services in Plain English

#82
post #78

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.

Well done, as a front end developer I find this tremendously useful. Could you go even deeper and describe various components of some of the services? What is a bucket and what is an instance? etc. Thanks

The plan is to go back through and start doing a similar "plain english" post about each of the services. If you're interested in getting those, please drop your email into the little newsletter form on the page.

Re: Amazon Web Services in Plain English

#84
post #71

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.

Hi Michael! Great guide. SNS is not just for mobile app developers and should probably belong in the "Web Developer Services" section. 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 endpoin…

All good points, I think this is where the "plain english" starts to break down and you _have_ to really come to grips with exactly what the services are doing.

I was trying to write this from the standpoint of describing what the services did to another developer in a really high level way.

Re: Amazon Web Services in Plain English

#85
post #19

I have to say that I think "glacier" is an inspired name. It takes a negative -- slow data retrieval -- and turns it into a positive -- indestructible, huge, unstoppable.

I completely agree. It is a great name for the service. "There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors." ~ Jeff Atwood

I count 4 hard things there.

Re: Amazon Web Services in Plain English

#86

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.

Thanks dude - finally one place where I can quickly understand everything Amazonian!

Re: Amazon Web Services in Plain English

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

S3 (or any object store) "is like FTP" has been the best explanation I've used. Way too many people I've talked to think that it's a POSIX-compliant filesystem and "like FTP" is familiar enough to them to know that treating it like a standard filesystem is a terrible idea.

Re: Amazon Web Services in Plain English

#88
post #80
post #70

When you're building a new app based around a handful of these services, how do you have any idea what it will cost to host your business on a startup? In the past I've avoided using these, and just used VPS servers doing my own thing, because it's really hard for me to, for example, guess how many database queries I'll do or messages I'll send between app components. I feel much safer saying that I can limit myself…

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

Re: Amazon Web Services in Plain English

#89
post #70

When you're building a new app based around a handful of these services, how do you have any idea what it will cost to host your business on a startup? In the past I've avoided using these, and just used VPS servers doing my own thing, because it's really hard for me to, for example, guess how many database queries I'll do or messages I'll send between app components. I feel much safer saying that I can limit myself…

Well, there's a cost calculator that you can use to get an idea (though it requires understanding their services somewhat to put it together correctly): http://calculator.s3.amazonaws.com/index.html

You can also set up billing alerts, though as has been discussed, they aren't strict caps, so you can still exceed your cap.

Re: Amazon Web Services in Plain English

#90

It took me forever to understand what each services aim to do. Like I could have literally been a better programmer by spending all the time learning algorithms instead of figuring out what each of the aws services do. I wish I've had access to this post before. I like the services they offer, I just really hate the names they gave it. Funny enough, Jeff Bezos said in an interview that names of a product is important…

You've got a nasty shock coming then, you'll spend far more time scouring badly written documentation about something that is supposedly simple but just doesn't work and once you've got working you'll never, ever use again until you've forgotten everything and then you need to set it up again and you'll have to go through the whole soul destroying process again but the documentation you find is now out of date, why-god-why, than you ever will implementing algorithms.

In fact, if you spend more than a couple of weeks implementing algorithms in your entire career you're probably doing it wrong or part of the 0.1% of programmers working on low level libraries.

Post reply on HN