Why CloudFoundry Core Is (Not) Important?

On Tuesday, VMware’s CloudFoundry project announced the availability of CloudFoundry Core, a baseline to test if an application is compatible to CloudFoundry’s core open source release. The CloudFoundry Core is based on a set of components that forms the baseline for the definition of core. Right now, they have limited set of programming languages and data services but they have shown inclination to add more in the future. Also, VMware has clearly highlighted what is part of the CloudFoundry Core and what is extra so that developers can get better understanding while planning their app strategy. It is an interesting step by VMware’s CloudFoundry team and I thought I will do a post talking about its importance and limitations (yes, the title is misleading but I went with it because it is catchy). Also, keep in mind that my discussion about the limitations doesn’t take away the significance of this announcement.

First, why it is important?

VMware has already written a blog post on why it is important but I will rehash it again and add some of my own thoughts to it. At the heart of the announcement is application portability across many different clouds (PaaS in this case).

Preserving cloud portability is imperative in the cloud era. Being locked into a single cloud restricts the ability to respond to changing needs now and in the future. Cloud portability allows movement between providers that better suit pricing needs or can offer better quality of service. It provides the flexibility to pick and choose where to deploy applications based on compliance requirements, data protection laws, and latency constraints. A choice of public or private clouds is key to adding capacity for managing growth as well as dealing with “cloudbursting” scenarios for optimizing spending.

Whether we like it or not, PaaS involves certain levels of vendor lock-in. Before traditional vendors and pundits start peeing on PaaS, I want to point out that it is the case with traditional application development process too. In a way, developers lock themselves in the moment they decide on the programming language they are going to use. I would say that data gravity problem is a serious problem than this lock-in risk. However, it is a separate discussion and I will just focus on CloudFoundry Core announcement. Also, PaaS offers way too many advantages and it is definitely not worth losing sleep over this fact.

Instead we should focus on how we can take advantage of PaaS while also minimize the lock-in risks. CloudFoundry Core is the first step towards mitigating this risk inside CloudFoundry ecosystem of players. This will allow application developers to develop apps that can seamlessly move from one CloudFoundry deployment to another without any large scale rewriting. This is the basic premise behind this announcement.

However, this could also help avoid the fragmentation issue that many successful open source projects (e.g.: Android) are susceptible. In fact, during the recent OpenStack Summit, fragmentation of OpenStack was voiced as one of the concerns by analysts. CloudFoundry Core could help limit the fragmentation of the project to a certain extent.

Second, why it is a smart move by VMware?

Apart from the perceived altruistic aspects of this announcement in terms of openness and portability, I would say this is a pretty smart move by 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. If you see from this angle, this is a smart move by VMware.

Finally, why it is not important?

The arguments for this point follows from the previous one. 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. In fact, Tier 3 and Activestate has made this clear in their respective blog posts on the Core announcement. If all these vendors start offering “value added core incompatible” features and functionalities, the application portability problem (more or less) remains the same. In this sense, this announcement is not significant.

So

The crux of my post is the following. 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). This is my take in a nutshell.

Related articles

• VMware Cloud Foundry Core Ups Application Portability (thevarguy.com)
• Cloud Foundry Core and the Future of PaaS (appfog.com)
• New Cloud Foundry app validates cloud portability [GigaOM] (gigaom.com)
• Preserving Cloud Application Portability – Introducing Cloud Foundry Core (cloudfoundry.com)