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 Salesforce.com 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.