Fair warning, Beanstalk is still young so there might be some growing pains, but for someone with little ops experience, it's been pretty awesome. One very important fact to note, is that it's just a layer on top of other AWS services (with no extra fees, you only pay for the underlying resources), so if there's something you can't do on beanstalk, you can do it with whatever resources are beneath it (EC2, RDS, Cloudwatch, etc).
I'd recommend if you're interested in it, or feel AWS is burdensome/complicated, it's worth a try. You have to scope out if it's right for you or your project.
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).
Beanstalk is not 100% matured, you see this in some unexpected behaviors like :
- changing some environment vars give unexpected troubles with the load balancers in one environment, but not in another. - restarting an app server sometimes crashes the environment. -etc.
the automatic procedure is that beanstalk starts replacing it's EC2 instances from your Auto Scaling Group, which sometimes has to be repeated for 2-3 times in a row which can take up to 30 mins.
in the meantime you should switch to a backup environment ( which is a must have! )
but all in all im positive because it's getting better all the time and the benefits are despite the disandvantages great.
check out the beanstalk forum : https://forums.aws.amazon.com/forum.jspa?forumID=86
If anyone is interested in the work we did this weekend, https://github.com/jawnb/badatcomputers
Or is there something that I'm missing with the Elastic Beanstalk? (I've only used raw EC2)
As for platform lock-in, my comments were less towards the web services level and more about system level concerns. It's not entirely clear how you would run persistent background tasks (read: celery). This doesn't even get into the headaches of learning yet another DSL to define OS packaging requirements.
That being said, IMO this would be great for simple apps, with no strenuous requirements. In addition, anything that allows more people to easily deploy their django apps is a good thing.
Also, it's way less expensive than Heroku.
[1] http://aws.amazon.com/sqs/faqs/#How_many_times_will_I_receiv...
Now, if you could support PostgreSQL in RDS, that would be a nice feat.
