The good news for PaaS providers is that the largest player in cloud computing took another big step into PaaS support itself, with a PHP-based offering. That helps validate the model pretty effectively. The bad news for PaaS providers is… well, the same thing, really. Amazon’s PHP support for Elastic Beanstalk means that the company is looking to keep growing up the stack and into their business. This has to be especially uncomfortable for providers like Engine Yard that are built on AWS.
If you missed Amazon’s announcement about beefing up Elastic Beanstalk it’s pretty simple. Elastic Beanstalk is Amazon’s technology for making it easier to deploy applications across its cloud services. The initial announcement was for Java, making Beanstalk a PaaS for Java applications.
As of yesterday, Amazon is also supporting PHP and Git, which means that they’re looking to fit right into the workflow for many Web developers.
Right now, Engine Yard and other PaaS providers like Heroku and OpenShift have some advantages. They’ve been in the PaaS game longer. They might have nicer workflows and better tools. (Or not, I checked out Elastic Beanstalk following the announcement and didn’t see any obvious missing features.) They support languages that Elastic Beanstalk doesn’t. Yet.
“Yet” being the operative word, of course. Going after corporate deployments, and to compete with Google App Engine, of course Amazon wanted to tackle Java. PHP is a good second language choice because so many sites and applications depend on PHP, and there’s so many developers that know PHP.
So there’s still room for PaaS providers that support Ruby, Node.js, Python, Perl, etc. for now. But it’d be an enormous mistake to assume that Amazon won’t continue expanding Elastic Beanstalk to support all those, and more.
It’s also going to be tough for Engine Yard or Red Hat’s OpenShift to compete real hard with Amazon on price. Why? Well, at least for now, they’re running on AWS and have to charge a premium on top of the AWS costs for their services. Amazon is charging nothing for Beanstalk on its own.
In talking to Engine Yard’s Mark Gaydos today, following the announcement, he made the case that Engine Yard has loads of experience running a PaaS. Gaydos says that Engine Yard was in the PaaS space “before it was called that.” Fair enough, but is the experience that Engine Yard has enough to balance out the fact that they’re competing with a company many, many times larger than themselves? And it’s not as if Amazon is exactly hurting for experienced engineers and support folks.
Some companies may prefer working with Engine Yard or another PaaS provider for a variety of reasons. There should always be room for more than one player, and I don’t think Amazon’s PHP support is likely to kill Engine Yard outright. However, it does seem to limit the opportunity for growth quite a bit and make the market much more challenging than it was yesterday. Either way, Amazon wins – Amazon has a good shot at a lot of customers, but if Engine Yard continues to grow, they continue pouring money into Amazon’s coffers.
This should give companies like Engine Yard and Red Hat pause in putting too many eggs in the AWS basket, though.
Would be interested in hearing from PaaS customers and how they feel about the move. Are you going to rush to AWS for PHP apps? Is Amazon missing any crucial pieces with its Elastic Beanstalk support for PHP? What languages should AWS tackle next?
