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:
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.
Best Microsoft MCTS Certification, Microsoft MCITP Training at certkingdom.com
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.
