The PaaS Dilemma

Comment | Print | RSS

• Login to Rate

Those who have had any degree of exposure to mainstream cloud computing jargon are familiar with the big three "azzes": IaaS (infrastructure as a service), PaaS (platform as a service), and SaaS (software as a service). These are conceptually independent ways by which cloud services can be delivered to end users; check out the definition that the National Institute of Standards and Technology (NIST) has come up with.

To date, both IaaS and SaaS have enjoyed healthy rates of adoption. IaaS can be leveraged by simply virtualizing an existing physical server -- technology that's already proven itself "enterprise-ready." SaaS has been around even longer, and is used extensively for "commodity" applications such as travel, expense, procurement, payroll, and so forth.

And then, somewhere in the middle, there's PaaS. Exactly what is it, and why would you want to use it? If you canvass the industry today, you'll find numerous offerings labeled "platform as a service," but, with few exceptions, they look nothing alike. It's the ambiguity of that no-man's land that makes PaaS both an exciting and frustrating topic for CIOs. To see why, let's stack SaaS on PaaS on IaaS to capture how software ultimately runs on hardware, with some layer of abstraction in between.

The plethora of PaaS offerings makes sense if we think of PaaS as a spectrum representing that abstraction layer, shown in Figure 1. At the far left, PaaS essentially doesn't exist -- software runs directly on hardware. At the other extreme (far right), all aspects of the application's execution environment have been virtualized to a service-oriented, network-only resource access model.

PaaS as a Continuum of Application Hosting Abstraction

Thinking of PaaS this way clarifies both its advantages and disadvantages. The benefits as one moves to the right include (to various degrees, and with varying efficacy depending on the offering):

• Reduced dependence on specific hardware
• Rapid application development
• Automatic scalability and optimization
• Service level guarantees
• Reduced total cost

These arise largely due to the fact that applications are aggregates of pre-existing services bound together through a service-oriented interface, having only managed network access as a dependency, running on shared infrastructure.

These qualities enable the platform to provide a richer execution environment with guaranteed performance characteristics more cost effectively.

But there is a tradeoff: The dreaded "platform lock-in." A decision to leverage the goodness inherent in a highly virtualized and abstracted platform implies a strict dependence on that platform, its particular array of services, and the consumption model. The more you depend on the platform's higher-level services and features, the more you lose control of the application's architecture and environment, and the harder it will be to move it later on, should the need arise. For many CIOs who hear the siren call of a full-featured PaaS, the prospect of lock-in keeps them at a safe distance, and they choose to stop at the shallow end of the PaaS pool where the water is easy to navigate.

Cost vs. control... faster development vs. platform lock-in. How to resolve the dilemma? PaaS is a nascent market in flux, with many offerings. It's easy to choose one that may not be around tomorrow, which could have dire consequences. At the same time, the pressure to further reduce IT cost continues to build, and just running generic virtual machines (VMs) in the cloud (IaaS) can't deliver the same efficiencies as a PaaS.

But, there is a way to reap the benefits of PaaS today and minimize the possibility of lock-in: Look for platforms that balance cost and control, and choose ones that are available from multiple sources. Since they ultimately want to profit from a developer base, both VMware Inc. (NYSE: VMW) and Microsoft Corp. (Nasdaq: MSFT) have taken the approach of fostering many competing instances of their platform's service.

VMware's Open PaaS defines a common interface that can have multiple implementations from any number of providers, such as SalesForce.com and Google. Microsoft's recent agreements with a handful of large IT vendors (including this author's employer, Dell Inc. ) to create separate, independent instances of the Windows Azure service, and to sell private instances of Azure as an appliance, means that consumers of the Azure technology can choose to buy it from multiple sources, move among them, or even stand it up themselves if needed.

And that means CIOs don't have to hang around in the shallows waiting for the storm of PaaS innovation to subside.