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

71–80 of 237 posts

Re: Amazon Web Services in Plain English

#71

Post by djm_ »

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.

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

Re: Amazon Web Services in Plain English

#72

Post by [deleted] »

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.

[deleted]

Re: Amazon Web Services in Plain English

#73

Post by err4nt »

gldalmaso wrote: post #58
stephenr wrote: post #32

Let me preface this by saying I use AWS only when clients insist on it. I think there are much better options that don't lock their customers in anywhere near to the same level. I think AWS has plenty of badly named services, but some of these suggestions are much worse worse (and have a huge American influence - that fascination with using brand/implementation names for a generic/standard item) than the current actu…

to add: * Amazon Unlimited FTP Server: you can't really interact with S3 using a ftp client

Both of the most popular FTP clients for Mac and Windows that Ive seen developers using have fantastic support for S3!

http://cyberduck.io https://panic.com/transmit/

Re: Amazon Web Services in Plain English

#74

Post by brudgers »

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.

I surprised myself after reading your article by signing up for your newsletter and I can probably count on my fingers without using binary encoding the number of times I've done that based on an HN submission. The article's format is a hard one to sustain across a list that long and stay readable and pulling it off is an achievement. Here's to your newsletter being similar goodness.

Re: Amazon Web Services in Plain English

#75

Post by frankcaron »

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.

I'm kind of in love with you after writing this. Thank you for doing what so few product and service companies do: naming a product in a manner that makes it almost instantly-understandable as to what problem it solves.

Re: Amazon Web Services in Plain English

#76

Post by Cthulhu_ »

unoti wrote: 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…

I'd say run on Heroku, but IIRC they gave up on their free plan. You could run on Google App Engine though, IIRC they still offer a free service up until a certain number of requests or CPU usage or something in that direction. You could use those to determine how much your application actually uses the service.

IIRC, Amazon also offers services for a fixed monthly price, you could look into that too.

Re: Amazon Web Services in Plain English

#77

Post by spdionis »

PuffinBlue wrote: post #29
Pyxl101 wrote: post #28

Earlier quoted context omitted.

Because when you figure out how to use them, you can save a tremendous amount of time and energy, and build sophisticated systems with simple code and little effort. When you have the need in a certain area, a lot of them will feel like "Wow, I didn't know that someone could automate this for me with so little effort compared to doing it myself". Most of it becomes increasingly valuable as you operate larger systems…

I know you are right (of course), I just wish is wasn't so much of an upfront cost (cognitively). I do think the page shared here is fantastic though and has changed my attitude somewhat towards AWS.

Anecdote: after deploying and maintaining applications in Opsworks for a while I feel it's comparatively incredibly hard to do that anywhere else.

The services they offer are great. Remember that you don't have to learn them all at once though. I've worked with amazon services for a couple of years and I still don't know/haven't used most of them. Just use what you need, really.

Re: Amazon Web Services in Plain English

#78

Post by dandare »

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.

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

Re: Amazon Web Services in Plain English

#80

Post by tobz »

unoti wrote: 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.

Maybe now you're thinking that RabbitMQ is too much of a pain to manage, so you do the same thing with SQS. Analyze the time/cost savings of switching, and see if it makes sense.

I think for new applications, estimating is a lot harder, right? You have no traffic until someone is interested in your product, but you can sort of spitball. There's a bunch of free load testing services out there to let you roughly simulate N concurrent users, and open-source projects to simulate those users yourself.

Ultimately, and maybe someone has an idea how to do this: I don't think you can ever plan beforehand. You could be optimistic, and assume your app is going to explode, and that you'll need 8 web servers and redundant load balancers and DB with a read replica... but that's just what it seems like, optimistic. I think the closest you can get is spitballing -- assuming maybe you'll get 100 concurrent users or something -- and making sure you can handle that.

Separately, there's the whole issue of trying to make smart decisions ahead of time with your infrastructure, but similarly, this can be really hard to do.

Post reply on HN