The Inevitable Proprietary Nature - and Integration Challenges - of PaaS

Loraine Lawson

This year, I've heard a lot more about PaaS-platform as a service. Certainly, Salesforce's platform as a service has taken hold, with more people developing on that platform, and Google's been in the news, if not in the enterprise, for its PaaS efforts.


And we're likely to hear more, since it seems PaaS vendors partner with IaaS (infrastructure as a service) vendors and, of course, SaaS (software as a service vendors) are partnering up, says Andre Yee, senior vice president of Products for Eloqua. Yee believes the end result will be a blurring of all three, and he points to the VMWare's recent partnership with as one example.


What piqued my interest, though was this remark by Yee about what's motivating PaaS vendors:

PaaS vendors will be driven by a motivation to create an ecosystem of applications that run on the platform. This is both as a means to legitimize the platform and to create the kind of stickiness that comes from interoperability, integration and security.


That's interesting, and certainly PaaS vendors like to talk about integration and, to a lesser extent, interoperability. But given that you'll be developing your own solutions on their platforms, you might want to ask yourself: Is this really so?


Lori MacVittie seems to think not. In a recent column, the technical marketing manager and blogger at F5 Networks argues that PaaS is proprietary by nature, and so any portability and choice are likely only "skin deep."


MacVittie's post was prompted by another VMWare alliance, this time with Google. It's worth noting that this means VMWare now has partnerships with two of the three PaaS companies that Yee considers "legitimate PaaS players who effectively have a suite of SaaS offerings," the third being Microsft.


Even though she appreciates that thes VMWare deals are a step in the right direction, she provides a must-read explanation for why you can't ignore the inherent portability challenges of the cloud.


What I like about her piece is she points out the irony of these announcements claiming it will help you avoid vendor "lock in," when you're effectively locking into proprietary services by subscribing to a PaaS solution. I would add I also find it ironic that this is one of the reasons people consider cloud and SaaS in the first place-so they theoretically have more options and flexibility when it comes to switching vendors:

...there is almost no way to avoid cloud "lock-in" when an organization commits to integrating with the proprietary services of a PaaS (Platform as a Service) solution. None. Such platform services are proprietary. Closed. Non-portable. They are services that, once your application is dependant upon, you are "locked in." ... Integration with those services necessarily makes your application dependent on the service and thus that particular cloud. It locks you in.


This "skin-deep portability" problem is also an issue with IaaS and it will be a problem for those who plan to migrate apps between on-premise cloud computing models and off-premise cloud computing models, she writes. Her column goes into some technical detail - all of which is very understandable. She also lists the options for getting out of this lock-in, although none of them are simple or pretty, and at least one involves you recoding the integration work.


Her point isn't to get you to avoid PaaS. Rather, it's to get you to think through this issue and what it means in the long run, both in terms of integration work and your development team. After all, as MacVittie points out, even on-premise, companies tend to standardize on a development environment. But the key difference is that the language, paltform - it's been your choice thus far. You don't want to inadvertently hand that decision over to cloud vendors.


As Bryan Doerr, CTO at Savvis, pointed out on our sister site, CTO Edge, this isn't something you should leave to chance:

Enterprises evaluating cloud services must understand the policy implementation mode they are buying into. They need to think about how much control they need at the resource, application and operational levels-and then make sure that it's available.

Add Comment      Leave a comment on this blog post
May 27, 2010 9:09 AM Joe Cordo Joe Cordo  says:

PaaS need not be proprietary and the market will push vendors toward openness. Forrester refers to this as Adaptive PaaS, and even is embracing the trend. SensorLogic's Cirrus PaaS for asset tracking applications provides developers with pre-built Widgets but supports any development environment and a comprehensive set of Web Services APIs. We also support private clounds and our multi-tenant architecture leverages MySQL, which gives developers the capability to migrate data. Is any architecture completely open in the purist sense? No. Developers need to make decisions on the ability to get applications to market quickly, ensure extensibility, while also making the right level of trade offs around investment protection.

Joe Cordo

VP of Marketing

SensorLogic Inc.

May 28, 2010 12:26 PM Derek Cheng Derek Cheng  says:

Any software product coming from any commercial venture is going to have some for of lock-in. It's disingenuous to believe it won't. No one accuses you of Oracle lock-in or Microsoft lock-in or even Google lock-in, but guess what? You're locked in.

That said, there are options for real PaaS implementations that mitigate the risk lock-in potentially leaves you at. For example, PaaS offerings that support private cloud or operation behind the firewall are available that completely replicate their hosted instances. LongJump is one example, but as Joe says, there are others.

He is also correct in that if the goal is to get easy to service applications out fast to improve business process or capture market conditions, then PaaS is your best option. And the right PaaS can provide the complete ecosystem as you mentioned.

May 29, 2010 8:15 AM M.Sadiq M.Sadiq  says:

PaaS,IaaS & SaaS plays major role in defining the kind of security level anybody opt. Proprietary, one way or the other way tied with the security. As Derek mentioned, 'For example, PaaS offerings that support private cloud or operation behind the firewall are available that completely replicate their hosted instances.' in my view, such services should come under as OaaS (Operations as a Service). Once OaaS in picture it is more simplified for the vendors to impose classified proprietary rights.


Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.