[bromley]

I've been using the Java version of Beanstalk to run a commercial API - http://www.degreedays.net/api/ - for about 12 months.

So far it's been working out very well. I love how you can dip into the EC2 APIs if/when you need to, but it's not usually necessary as the basic setup is excellent (a load balancer in front of one or more EC2 instances - your choice of number, type, and auto-scaling rules).

The tools for updating a Java app are great. Each deployed version of your app gets stored in the AWS system, and you can rollback to any version with a couple of clicks in the AWS control panel.

It's also pretty easy to set up a staging environment to test new versions before deploying them to the live environment. Only issue I have with that is that there's no way to pause a staging environment (like you can pause an EC2 instance and not pay for it while it's paused). So you either have to keep a staging environment running all the time (paying for its EC2 instances), or set one up afresh each time you need it. The latter isn't a huge hassle, but it would be much better if you could just set one up and keep it paused for most of the time.

I think development on Beanstalk is nicely approachable, and in my experience it's been pretty reliable as well, or at least as reliable as EC2. The current version of our app has been running well, with moderate load, for several months, without so much as a restart of an EC2 instance. On two occasions 6+ months ago one of the EC2 instances went a bit screwy, having problems connecting to external URLs, but in both cases we just terminated the problem instance and Beanstalk did the rest (provisioning a replacement and putting it behind the load balancer). We could probably avoid that sort of problem in future by improving our internal monitoring (in conjunction with the beanstalk health checks that ping a URL on each EC2 instance at frequent intervals to check for problems).

[lee]

Can you tell me the reason you'd want to run a load balancer in front of a single instance? I read the feature spec for the elastic load balancer and can't it out.

[EwanToo]

There's 2 main reasons. 1, if the AZ that your single instance is running in dies completely, ELB can help fire up a new instance in another zone quickly without having to handle re-routing DNS, etc. 2 if you need extra capacity in a hurry (e.g. you just got linked from HN and 10,000 people sign up), you can add more instances without re-achitecting.

Whether it's worth paying for those capabilities is always up to you though.. :)

[captainchaos]

This is a great point. Although it's a slight extra cost, we have adopted this a best practice because it's still cheaper than a more responsive DNS service.

[bromley]

If you have one single instance only, I'm not sure there is any point. But if you want your app to auto-scale upwards to add EC2 instances if the load increases, then the load balancer is necessary. It enables all your EC2 instances to be accessible via one public URL (as the elastic load balancer forwards requests on).

I set it up such that we always have at least 2 EC2 instances, in separate availability zones, so that, if one goes down, at least the other is likely to keep working. And then it auto-scales upwards from there, if the load gets high enough.

The load balancer is pretty much transparent as far as you the developer is concerned. You don't need to configure it - beanstalk does that - and it scales completely transparently (unlike the EC2 instances, for which you do need to define auto-scaling rules if you want that).

I may be missing some subtleties as I'm far from being an AWS expert... Just been picking bits up here and there through using beanstalk and a few of the other APIs for extra bits and bobs.