Cloud computing discussions invariably begin with the "IPS" taxonomy: Infrastructure as a Service, Platform as a Service and Software as a Service. This taxonomy has the virtue of being comprehensible and neatly partitioning assessment requirements:
- Want an application? Look to a SaaS provider for a single purpose application (HR, financials, printing, etc.)
- Want to write your own application? Look to an IaaS provider that lets you create your own custom application.
- Want to understand the concept of leveraging someone else's software smarts to manage the plumbing while you focus on application functionality? Then look at something like Google App Engine to get an idea of what PaaS could be.
This latter category was always kind of an afterthought because it lacked very strong entrants. However, that's changing--big time. I wrote about this a few weeks ago in my blog, where I noted "PaaS is where it's at."
Cloud providers of every stripe are converging on what will be the development battleground of tomorrow--PaaS. They've clearly identified this as a crucial market--one in which the victors will enjoy huge spoils. It's also a market that will present significant challenges to users.
The evidence of this convergence is all around us. Amazon, by far the most successful IaaS provider, has steadily been surrounding its core services with additional functionality that, while not announced as "platform," has the undeniable effect of providing a set of services that help build applications faster and manage collections of resources easier. Think RDS for managing and scaling databases; direct connect for securing external application access; virtual private cloud to segregate applications within AWS (Amazon Web Services) data centers; and CloudFormation for application management.
At last week's Dreamforce event, Salesforce outlined its PaaS offering based on the recent acquisition of Heroku. While once a Ruby on Rails-oriented offering, Heroku has been extended to support Java. It's also been integrated with Salesforce's Database.com. And it's supported by the Database Rights Option, which integrates on-premise data with Salesforce applications. Salesforce may call it "the social enterprise," but the collective offering is clearly aimed at providing a generalized platform for application development.
Of course, it's not just big players staking a claim here. A number of small firms have recently been funded, each providing a slightly different framework for building cloud-based applications. While each of them (including one from VMware, which is certainly no startup) claims to be open and multi-cloud, it remains to be seen how well they deliver. Just as likely, in my view, is that cloud providers will adapt (aka "improve") each platform in a way that hampers its vision of application portability.
The net effect of this is that the neat IPS taxonomy is rapidly breaking down into a much more complicated cloud computing world in which every provider is seeking to offer a solution that covers a large proportion of customer computing needs. Your SaaS provider wants to help you write your own applications. Your IaaS provider wants to surround its infrastructure with useful functionality that makes your developers more productive. In this new cloud computing combo plate world it's far more difficult to easily discern just what a provider brings to the table, and that ambiguity presents definite challenges for enterprises.
The Challenges PaaS Presents
Why would one call PaaS a significant challenge for users? Simply because the undoubted power and productivity of these platforms brings a new set of issues to enterprises that they may not realize until well after they've deployed a number of applications.
Here are some of the things IT leaders should think about as they begin to evaluate their PaaS options:
1. Lock-in. Using a PaaS framework entwines your functionality with the CSP framework far more than installing your application into a provider's virtual machine. Attempting to extract an application when it is internally dependent upon services the provider presents requires deep inspection of code--not just installing a tarball into a different provider. The productivity you gain by leveraging the PaaS provider's offerings is matched by the dependence you suffer by being locked into the specifics of the offering. I'm less disposed than many to see lock-in as purely negative, as in my experience organizations embrace lock-in because it provides significant benefits. But it's important to go into this with one's eye open because it definitely represents a higher level of lock-in.
2. Complexity. Every PaaS provider puts its set of functionality together differently, with its framework constructed according to its view of how applications should be designed. Trying to determine how best to write and run your application in a PaaS environment is not trivial. For sure, it's a big step away from traditional on-premise environments.
3. CSP (cloud services provider) differentiation. As noted above, a number of PaaS frameworks claim to provide a layer of abstraction that hides the details of the cloud provider from the application developer. Setting aside the likelihood of this application abstraction really working, it overlooks the meta-application functionality that can lock one in as surely as anything. Much of this functionality will be provided by the CSP--think monitoring and payment systems, for example--and will focus on operations, not application writing. CSPs will use this level of functionality to differentiate themselves, with the net effect of locking you in at the operations level rather than the code level. Don't think this won't happen. The first thought a cloud provider has is, "How do I differentiate myself from other CSPs?" because they all fear becoming the computing equivalent of a "dumb pipe."
4. New skills. Your application developers will need to learn a new framework and how to develop applications for it. While many early cloud adopters are blessed with highly skilled development personnel that build new skills quickly, in the rest of the industry, getting organizations up to speed with something new is a human capital challenge.
5. Mapping existing practices to new frameworks. Most organizations have defined frameworks, methodologies and operational practices. These will have to be evaluated in light of a new framework and modified accordingly. In effect, this issue already exists with IaaS cloud offerings; it will just be exacerbated as the richness of the new framework presents more touch points for mapping.
This list may seem like a jeremiad full of reasons to refuse to embrace cloud computing. In fact, nothing could be further from the truth. The reality is that significant issues present themselves with every new platform, whether it be minicomputer, personal computer, cloud computer or mobile computer. It's crucial to recognize what challenges accompany the benefits associated with every new platform and prepare to meet them. It's also important to keep in mind the stresses--and solutions--that have occurred in the past. To quote the writer George Santayana, "Those who cannot remember the past are condemned to repeat it."
Bernard Golden is CEO of consulting firm HyperStratus, which specializes in virtualization, cloud computing and related issues. He is also the author of "Virtualization for Dummies," the best-selling book on virtualization to date.
Follow Bernard Golden on Twitter @bernardgolden. Follow everything from CIO.com on Twitter @CIOonline