Amazon has shown that Infrastructure-as-a-Service (IaaS) can actually work, leaving all other IaaS players scrambling to compete. For its part, Salesforce.com has illustrated that Software-as-a-Service (SaaS) can be similarly successful, and yes, the other players in the SaaS marketplace have been emulating Salesforce for years. But what about Platform-as-a-Service (PaaS)?
Sure, there are many players in the space, including Heroku, Google, Engine Yard, Cloud Foundry, CloudBees, Microsoft Azure, even Facebook. And while the PaaS marketplace is still less mature, and hence more dynamic than the IaaS or SaaS markets, it has matured rapidly over the past few years, and today there are many viable offerings with a correspondingly impressive list of success stories.
And yet, PaaS as a category faces a challenge to its growth, and it’s more of an architectural challenge than a market challenge this time. The challenge is building the appropriate abstraction.
The central architectural context of Cloud Computing centers on this abstraction. With IaaS, the Cloud Service Provider (CSP) abstracts the underlying physical resources (servers, storage, etc.), presenting simplified interfaces (both Web and APIs) that support automated self-service. If you don’t get the abstraction right, then users need to monkey around with the technology under the covers — and that’s not Cloud at all.
SaaS follows the same pattern. Users interact with a SaaS offering via Web interfaces and loosely coupled APIs. A SaaS user is never welcome to monkey around in the underlying code at the SaaS provider. If they were able to do so, it wouldn’t be SaaS.
What about PaaS? The central idea of PaaS is the CSP provides a development and deployment environment to the user. True, PaaS abstracts the underlying infrastructure, but that’s the role of the IaaS underneath the PaaS platform. The goal of PaaS is to abstract the development environment details themselves.
Unfortunately, building an abstraction at this level is extraordinarily difficult, because developers typically require fine-grained, hands-on control of their development environments. Change a classpath or config file setting or environment variable or any number of other nuts and bolts that make up a coder’s day-to-day work environment, and everything the developer has built will crash and burn.
The PaaS CSP, therefore, faces a double bind. Either they try to create a platform where users can make all these configuration choices themselves, or they include such details in their platform, essentially under the PaaS abstraction. But the former option essentially relegates the platform to an IaaS offering, with little value-add to qualify it as a viable PaaS player, while the second option risks breaking customers’ code every time there’s an update or configuration change.
From the customer’s perspective, today’s PaaS is all about buyer beware. If you want your code to run the way you expect every time, then PaaS may not be appropriate for your needs. Bite the bullet, use IaaS, and install all your tools yourself. On the other hand, if you want to leverage the convenience and rapid development potential of PaaS, then get ready for the roller coaster. It’s going to be a bumpy ride.
