Recently VMware announced Core, a baseline test that assesses how compatible an application is to the Cloud Foundry open source release. In order to derive this compatibility rating, Core is based on a base set of components – specific versions of runtimes and components that are currently within the Core stable. Krish Subramanian has written an excellent post detailing the reality of Core. As he says:
If you lose sleep over application portability in PaaS environments, go ahead and make sure your apps are compatible with CloudFoundry Core but you will miss out some of the advantages offered by non-VMware CloudFoundry vendors. If you don’t care about a little vendor lock-in (which can still be overcome with code rewrite (aka additional cost)), take advantage of the unique features offered by your chosen CloudFoundry PaaS vendor(s).
It’s been interesting to see the response to the announcement by Cloud Foundry ecosystem members Tier3 and ActiveState. Both companies have been effusive in their praise for the initiative, but have also indicated the extended language and service frameworks that they both support. In doing so, they point out one of the limiting factors of Core. This limiting factor, as pointed out by Krish, comes mainly because of a potential ulterior motive by VMware. As he pointed out:
The very fact that it is theoretically possible for VMware to leverage the compliance to CloudFoundry Core to their advantage will ensure that other vendors betting their business on CloudFoundry are worried. They will try to differentiate themselves by offering functionalities that goes beyond CloudFoundry Core. They will add features that are not part of the core to ensure that their users stay with their service. In fact, they have to do this because it is the only way they can monetize successfully
Essentially VMware is making a calculated bet, that fledgling ecosystem partners will be sufficiently incented by the quasi-anointing that Core compatibility gives them to not articulate to loudly the added value that extended functionality can bring. Of course the ecosystem partners have a difficult decision to make, there options are to;
- Strongly articulate the benefits of extended functionality, in doing so they de-emphasize the value of Core but also create a significant point of differentiation from VMware’s own Cloud Foundry offering
- Tow the VMware line re Core, and hope that the reflected credibility from the Cloud Foundry ecosystem will be beneficial to the entire ecosystem
In his post, Krish suggests a logical-sounding ulterior motive on the part of VMware;
Imagine a world where developers using CloudFoundry PaaS write against CloudFoundry Core specs. It will imply that apps can be easily ported to any CloudFoundry deployment that stays true to CloudFoundry core. Now imagine VMware getting serious about monetizing CloudFoundry.com or even CloudFoundry on vCloud. Just think how easy it will be for VMware’s all powerful sales and marketing team to go against other PaaS startups betting on the CloudFoundry ecosystem. It is just a matter of nudging the “enterprise users” of CloudFoundry platform to go with VMware’s offerings
It would be easy to see this move as primarily about VMware ensuring its own ability to monetize Cloud Foundry. I’ve been pretty vocal in voicing concerns about VMware’s intentions with the initiative in the past myself. But it seems to me there are some more practical reasons for Core beyond simply VMware’s commercial ones.
At the moment PaaS is very much a fledgling movement. While some of us are firmly committed to the idea that PaaS is the future of cloud services, it’s fair to say that widespread adoption in the enterprise is still a fair ways off. As such, it is important that we do everything to reduce the barriers to adoption of PaaS. One of the key concerns from the enterprise customers I talk to about PaaS is the worry that by using a cloud service further up the stack (ie not dumb infrastructure) they are more and more reliant on one particular vendor. This has obviously long been a concern by some when it comes to Force.com.
Upon its inception, Cloud Foundry was articulated as one way to avoid this – by building an ecosystem of interoperable PaaS providers, customers have choice as to where their stuff lies. It’s already obvious, despite Cloud Foundry being somewhat new, that the different ecosystem players have different focuses and priorities when it comes to their development. As the project sponsor, VMware has to navigate a path that balances sufficient control to avoid fragmentation, with sufficient freedom for third parties to innovate. Core in one way of doing this.
Of course the best way to ensure that customers and potential customers feel secure in application and service portability is through a management layer that sits atop the Cloud Foundry ecosystem – the same way RightScale and enStratus do for IaaS. VMware could build this layer but then that would reintroduce concerns by ecosystem partners about their intentions and the levelness (or otherwise) of the playing field. This is entirely the reason that Appsecute (which, as readers will now, is a company I’m an investor in) is focusing strongly on being this “Switzerland of PaaS”.
PaaS is young, VMware’s intentions are somewhat unknown and lots of vendors are maneuvering to find a market niche. The introduction of Core is interesting, but I suggest not overly important in the development of the Cloud Foundry initiative.
(Cross-posted @ The Diversity Blog – SaaS, Cloud & Business Strategy)