What happened yesterday? Amazon Web Services launched a PHP option for Elastic Beanstalk. Apart from studiously avoiding the PaaS word, what Jeff Barr and Werner Vogels don’t say in their posts introducing the update is that this is clearly a Facebook app play. Heroku has been enjoying mindshare as go-to cloud platform for Facebook backends, now AWS wants to compete with that. What’s different with AWS supporting PHP is that now Facebook app developers can use PHP front-to-back, instead of writing their backend in Ruby to suit Heroku (or Java, Node.js, or Python, now that Heroku supports these platforms).
Opinion differs on categorizing AWS Elastic Beanstalk, and I’ve always described it as a PaaS. I had Beanstalk pegged as a classic ‘Instance PaaS’ in my Market Profile for PaaS segmentation(1)– i.e., the developer’s abstraction is instances of VMs. Beanstalk is designed so that you can touch all the underlying infrastructure if you need that control.
But is it really PaaS? With help from my Gartner colleague Lydia Leong, I found it helpful to rethink through Elastic Beanstalk today with these questions and answers:
- Who creates the AMI that includes the PHP runtime? Amazon. (It’s their LAMP AMI)
- Who chooses the AMI to associate with your PHP code. You (but you should probably choose the default LAMP one Amazon creates)
- Who updates the LAMP AMI (e.g., when a new version of PHP is released)? Amazon.
- Are the VM(s) running your PHP application automatically updated when Amazon updates their LAMP AMI template? No. (This is the key point and one borderline between IaaS and PaaS)
So Elastic Beanstalk provides an easier way to provision AWS resources for Java (and now PHP) applications, such as EC2 VMs, Load Balancers, and manage these resources as a group. Unlike ‘true’ PaaS providers, AWS doesn’t have a dynamic layer that sits between your PHP code and the VMs that Elastic Beanstalk instantiates for you. Other providers use fancy terms for this layer like a ‘Fabric’ or ‘Manifold’.
Here’s the clarification on this point from the Elastic Beanstalk documentation:
Software Updates and Patching
AWS Elastic Beanstalk does not currently have a software update mechanism or policy. AWS Elastic Beanstalk periodically updates its default AMIs with new software and patches. Running environments, however, do not get automatically updated. To obtain the latest AMIs, you must launch a new environment.
What’s also interesting in the updated Elastic Beanstalk offering is the support for the de facto standard PaaS code deployment workflow that is now well established – you push code to a PaaS using Git. (Heroku was one the first to spot this natural gesture).
Now, I want to hear from you. I’d love to hear from you in the comments if you are:
- using another PHP PaaS (such as Engine Yard, PHPFog, OpenShift). Would you switch to Elastic Beanstalk? Would the proximity to AWS other services (including their dbPaaS offerings like RDS and DynamoDB) be a driver?
- already deploying PHP apps on AWS EC2 ‘manually’ – would you consider using Elastic Beanstalk now? Why now?
- already using Elastic Beanstalk for Java applications – it’s not a platform I hear much about from my typical enterprise clients – why not?
(1) Paywall warning: Gartner IT1/GTP subscription required: Richard Watson. ‘Market profile: PaaS 2011′ http://www.gartner.com/resId=1542414
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.