Earlier this week Amazon added PHP and Git support to Elastic Beanstalk. To me, this looks like Amazon encroaching on PaaS territory and offering features similar to Engine Yard, OpenShift, Heroku, and others. All of which, by the way, host on top of Amazon. But not everyone agrees that Elastic Beanstalk has the necessary ingredients for a PaaS, or that Amazon is trying to compete with existing PaaS providers.
After hearing a bit of discussion over whether Elastic Beanstalk really fit the PaaS bill, I touched base with some of the PaaS providers and colleagues that work with PaaS software. In particular, I spent a good deal of time talking with Dave McCrory, senior architect of Cloud Foundry.
Is Elastic Beanstalk a PaaS?
Let’s start with the first item, does Elastic Beanstalk qualify as a PaaS in the first place?
My view is that it is a PaaS, if a rudimentary one when you line it up next to folks like Engine Yard or Heroku. It does provide a platform for running Java and PHP apps beyond the raw infrastructure. As Amazon’s CTO Werner Vogels says on his post following the PHP/Git announcement, “AWS Elastic Beanstalk is another abstraction on top of the core AWS building blocks. It takes a different approach than most other development platforms by exposing the underlying resources. This approach provides the simplicity to quickly get started for application developers, but it also allows them to modify the stack to meet their goals.”
Is it exactly analogous to other development platforms? No. Says Vogels, “So is there a “one-size-fits-all” in the development platform space? No, each platform fits the needs of different developers, applications, and use cases. Preference and familiarity also play a role in why some developers choose one over the other. Ultimately, we want developers to successfully run and manage reliable, highly scalable applications on AWS, irrespective of the abstraction that their development platform of choice offers.”
McCrory says that he doesn’t necessarily see Elastic Beanstalk as a PaaS. Instead, he describes it as more of a “configuration feature for IaaS, like InstallShield. It makes it easy to deploy and configure an application” but it doesn’t do many of the other things automatically that developers have come to expect from a PaaS like Engine Yard or Heroku.
The problem with Elastic Beanstalk for McCrory, is pretty much the same thing that Vogels touts as a feature: It exposes the infrastructure and “expects the developer to fiddle with all of those things beneath.” And this is true – while Amazon has the components like monitoring, message queuing, and so on it does expect developers to assemble the bits they need.
Bill Platt, VP of operations at Engine Yard, also brings up support. “If you want to have Ops people on staff or use your Dev resources to troubleshoot issues when your PaaS provider goes down, then AWS Elastic Beanstalk is an option. If you want to assign your Dev resources to building killer products, then Engine Yard provides you with a commercial grade platform, deep expertise and proactive support staff that have extensive experience deploying Ruby on Rails and PHP apps.”
I would agree with Platt that, if you want to pay extra for hand-holding, you should look to one of the other PaaS providers. But when it comes to features, I wouldn’t count on AWS being behind other PaaS offerings for long. The company has a history of innovating very quickly and it has far more engineers at its disposal than most of its competition (excepting Google and Microsoft). It may never be the best company for personal warm and fuzzies, but I expect its feature set will continue to evolve towards the more traditional PaaS offerings.
Competitive with Traditional PaaSes?
The other question is whether Amazon is competing with Engine Yard and other services, or means to. Vogels has said “Our goal is to ensure every developer’s favorite platform is always available on AWS so they can stop worrying about deploying and operating scalable and fault-tolerant application and focus on application development. In a nutshell, we want to let a thousand platforms bloom on AWS.”
Of course Amazon does. As I pointed out in the prior post, this is win/win for Amazon. If customers go directly to AWS, then Amazon benefits. If customers go to Engine Yard, Heroku, or OpenShift hosted on AWS… it also wins. The only way Amazon loses out is when customers pick PaaS offerings hosted elsewhere.
But if you’re partnered with Amazon, that doesn’t mean the company is going to stay out of your back yard. If you wonder whether Amazon is willing to go after its partners’ business, you only need to look how Amazon is working with publishers. While Amazon is continually fighting with publishers, the company is not only squeezing them, it’s also setting up shop as its own publishing imprint.
In short, I don’t expect Amazon to come out and declare war on its partners in PaaS. That doesn’t mean the company is going to be content to stay in the IaaS business for eternity, or even the next five years. If I was with Engine Yard or Heroku, I’d be operating under the assumption that Amazon will happily eat my lunch if PaaS looks like an attractive enough market.
So is Elastic Beanstalk a PaaS? You might disagree, but I’m still convinced it is. Granted, it’s a rudimentary PaaS when compared with other offerings, but it still seems to fit the bill.