Which freaking PaaS should I use?
The ups, downs, ins, and outs of deploying a legacy Java application to 7 leading platform-as-a-service cloudsFollow @infoworld
Google App Engine has the best SLA but also a high risk of lock-in. Red Hat's OpenShift was a bit disappointing, but we expect the kinks will get worked out as it exits preview status. It likely would've been more impressive if Granny were a Java EE application instead of a Spring app. Red Hat and VMware had the best answers with regards to lock-in.
Amazon Elastic Beanstalk isn't really a PaaS, but it might be a good compromise if you need IaaS customizability with PaaS-like capabilities. Microsoft's Windows Azure supports the most languages, but it didn't function as a "true" PaaS for our application. Microsoft's tooling for Linux didn't work, and its tooling for Eclipse was underwhelming.
It's still a bit early in the PaaS space, but you can already begin porting legacy apps to some cloud platforms with only minor changes or possibly none at all. Big companies and small companies alike may find a PaaS to be a compelling way to deploy applications and cut capital expenditures. This market isn't as crowded as it might seem, as many of the big players aren't yet out of beta. But in the coming months we can expect that to change.
Amazon Elastic Beanstalk
Amazon's AWS Elastic Beanstalk kind of sticks out in this list. It isn't a PaaS so much as a deployment tool for Amazon Web Service's EC2. Think of Elastic Beanstock as a wizard for deploying applications to EC2 VMs. We've included it because you'd ask about it if we didn't!
Differentiators. The biggest differentiator in this is the mothership. Most of the other PaaS vendors (including CloudBees, Heroku, and Red Hat's OpenShift) are piggybacking on Amazon's infrastructure. That means if something goes wrong at the infrastructure level, despite their SLAs, they're talking to Amazon while you talk to them because this is really an IaaS you have ultimate control down to the OS level. On the other hand, where a true PaaS would give you "freedom from the obligation of control," Amazon Elastic Beanstalk still requires you to manage infrastructure-level resources.
Lock-in. Lock-in is up to you. Since this is an IaaS, you can ultimately deploy what you want to.
Security. Amazon publicly lists its security and compliance certifications. It's an extensive list that includes FIPS 140-2, ITAR, ISO 27001, PCI DSS Level 1, FISMA Moderate, and SOC 1/SSAE 16/ISAE 3402. Amazon also provides a good amount of documentation on its security processes.
Who's using it? Amazon also publishes its customer case studies. It's an impressive collection of customers ranging from Amazon (duh) to Netflix to Shazam. It's also very long.
How did it do? It was straightforward to deploy our Granny app. To get Granny working with Amazon RDS (MySQL) required provisioning the database via the Elastic Beanstalk wizard and changing the data source descriptors in our application to match. Unfortunately, our progress was blocked by a connection timeout that other people also seem to have encountered. Supposedly you can fix this by adding IP addresses to a security group. However, debugging this took longer than deploying on other PaaS offerings, so we gave up.
Conclusions. Amazon Elastic Beanstalk is a middle ground between an IaaS and a PaaS. It's one throat to choke, but it isn't the real thing. You're going to do all the things that a PaaS would do for you by yourself. If you're thinking of cloud but you haven't decided to "go all in" and make it to PaaS, this might be a good compromise while you get there technically or psychologically. But if you can, go all PaaS and pick something else.