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

Introducing AWS Elastic Beanstalk

aws.typepad.com

Post reply on HN
Print view View original

21–30 of 58 posts

Re: Introducing AWS Elastic Beanstalk

#21

Post by riffraff »

rmc wrote: post #19
fookyong wrote: post #12

Earlier quoted context omitted.

automatic scaling would be a good benchmark for the true definition of cloud. a lot of "cloud" services these days are nearly identical to VPS services of yore, with the added new ability to create/destroy VPS nodes whenever you want. very few of the big "cloud" providers actually handle auto scaling (as it's difficult in a world where all apps are not made the same).

automatic scaling would be a good benchmark for the true definition of cloud. You can do this with EC2. You can set up monitors based on CPU usage over a time period and it'll start new nodes if required. S3 is 'autoscaling' for serving files. Just upload your files and pay for what you use.

but storage cannot be scaled like this, you have to design your own mechanic to handle it.

Re: Introducing AWS Elastic Beanstalk

#22

Post by fookyong »

rmc wrote: post #19
fookyong wrote: post #12

Earlier quoted context omitted.

automatic scaling would be a good benchmark for the true definition of cloud. a lot of "cloud" services these days are nearly identical to VPS services of yore, with the added new ability to create/destroy VPS nodes whenever you want. very few of the big "cloud" providers actually handle auto scaling (as it's difficult in a world where all apps are not made the same).

automatic scaling would be a good benchmark for the true definition of cloud. You can do this with EC2. You can set up monitors based on CPU usage over a time period and it'll start new nodes if required. S3 is 'autoscaling' for serving files. Just upload your files and pay for what you use.

you'll still have to build your application in such a way that supports these new nodes, though. Sessions, load balancing etc.

a "true" cloud would just handle all that stuff transparently.

Re: Introducing AWS Elastic Beanstalk

#23

Post by ghshephard »

latch wrote: post #6

AWS never fit into my definition of a "cloud" solution. It's a VPS with a rich API and a lot of addons (load balancer, EBS, S3...). From what I'm reading, Beanstalk changes this and clearly puts AWS in the category they've long claimed to be in. Not that their service wasn't great/unique before. This just puts them that much further ahead. It's along the lines of what Heroku does with their routing mesh layer (as far…

Can we please all agree to disagree that there is no formal definition for cloud? I tripped across an article the other day where they were suggesting that these "PaaS" offering's weren't considered a "Cloud" by purists, and only "IaaS" (Infrastructure) - servers, cpus, network, storage - should be considered such. I was one of the original employees at Loudcloud - we certainly considered "Databases", "Applications Servers" to be cloud services.

Cloud = "That service/infrastructure/platform that you need that will be hosted by someone else in their data center"

If we wanted to be precise, we could refer to it as "Storage Clouds", "App Server Clouds", "Database Clouds", etc...

Re: Introducing AWS Elastic Beanstalk

#25

Post by hallmark »

jollojou wrote: post #15

At the moment I'm able to launch applications in the US East region only. When will the other regions support Elastic Beanstalk?

Yes, US East region only for now. From their official FAQ, other regions in the future:

http://aws.amazon.com/elasticbeanstalk/faqs/#regions

Re: Introducing AWS Elastic Beanstalk

#26

Post by andrewgodwin »

jackowayed wrote: post #4

I'm not sure how useful this really is. It just handles the application layer, leaving you on your own for dealing with the database. Now, Amazon has some services to help you out (RDS, SimpleDB), but SimpleDB is kind of crap, and RDS is expensive. More importantly, that loses some of the simplicity, meaning that you still have to think about infrastructure to a degree. Heroku is git push to deploy, and if you have a…

As one of the two people working on something similar to Heroku or GAE (we're called ep.io), Beanstalk is simultaneously worrying and quite interesting - while it is an interesting player into the market, it's not _that_ hands-off, from what I can see, especially when it comes to databases, or things like Redis, which it's nice to have managed for you as well.

It's possible we'll see people springing up on EC2 offering those as separate services, however.

The other interesting part is that, since they don't do shared hosting but make you use a whole EC2 instance, there's potential for it to cost considerably more for smaller sites, but only once you get past that free plan of theirs (then again, the disk I/O on the Micro instances is truly awful)

Re: Introducing AWS Elastic Beanstalk

#28

Post by saurik »

riffraff wrote: post #20
mmelin wrote: post #3

Wow. The benefits of Google App Engine without the limitations? Sure, an app on GAE is probably cheaper in terms of monthly expense, but factor in the development costs for a Java team unfamiliar with App Engine and Beanstalk is probably a far better investment.

no, with different limitations I believe, e.g. no cool google storage, but only SDB or RDB (which may be ok anyway)

To me, the limitations of App Engine are things like having to use a crippled version of the programming environment (as you don't get your own computer, so they've neutered things down to something "safe") and a bunch of limitations on CPU time, request length, and background processing.

(edit: I had somehow read what you said to mean, "no, but with these new limitations", so arguably I should just delete my response here, but I think that a specific list of things might be valuable still)

Re: Introducing AWS Elastic Beanstalk

#30

Post by rchowe »

chanri wrote: post #8
latch wrote: post #6

AWS never fit into my definition of a "cloud" solution. It's a VPS with a rich API and a lot of addons (load balancer, EBS, S3...). From what I'm reading, Beanstalk changes this and clearly puts AWS in the category they've long claimed to be in. Not that their service wasn't great/unique before. This just puts them that much further ahead. It's along the lines of what Heroku does with their routing mesh layer (as far…

Amazon's execution with EC2 over the past few years has been excellent. If Amazon makes a Rails version of Beanstalk, Heroku should be worried as Beanstalk could take some market share from Heroku.

Heroku will probably still have the advantage of being git-based. I doubt Amazon will support git with beanstalk.

Now, Amazon may start siphoning off python users that switched to rails just to use Heroku.

Post reply on HN