CloudFoundry Core May Not Be Important But CloudFoundry Is Important

Two weeks back I wrote a post arguing that CloudFoundry Core is not important. I had argued that even though CloudFoundry Core is done with an intention to make application portability seamless across various CloudFoundry deployments, the business considerations of PaaS vendors in the ecosystem will ensure that application portability is not a given.

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).

In this post, I want to take a seemingly opposite point of view and argue that even though CloudFoundry Core is not important, CloudFoundry, by itself, is very important for avoiding vendor lock-in and ensuring business continuity. This argument follows from the fact that CloudFoundry is open source. Let me try to elaborate a bit more on this topic.

I have long argued in this space that even though open protocols are critical in the cloud world, open source is also equally important. The fact that CloudFoundry is open source highlights this point once again. Let us take a step back and see the available options with a PaaS vendor in the CloudFoundry ecosystem when, in a hypothetical scenario, CloudFoundry is not available under an open source license (i.e.. available only under a proprietary license). If an app is designed to be compliant with CloudFoundry Core, one can ensure app portability. However, if the app takes advantage of certain unique features offered by the PaaS vendor, the barrier to application portability is very high because

• CloudFoundry will be under a proprietary license and the licensing fee for the software will be exorbitant to deploy in-house
• Since CloudFoundry source code will not be available (in most cases and restrictive even if is made available by the vendor to paying customers), it will be very difficult to replicate the features offered by the PaaS vendor
• In short, you are locked into the PaaS vendor because the cost of avoiding lock-in is prohibitively exorbitant

However, in reality, CloudFoundry is available under an open source license. Now let us consider the case of an app written to take advantage of some of the unique functionalities offered by a PaaS vendor. If the app architecture is properly planned while taking advantage of the unique features offered by the PaaS vendor, it is quite possible (in most cases) to move this app to another CloudFoundry deployment that replicates the functionality offered by the PaaS vendor. The possibility to replicate the CloudFoundry deployment with the PaaS vendor is much easier because the open source license of CloudFoundry lowers the barrier significantly:

• The CloudFoundry licensing fee is completely removed or considerably lowered
• The lack of restrictions with the source code will allow you to set up a CloudFoundry deployment that could mimic the PaaS provider. Yes, there is a cost involved in ensuring this business continuity but it is usually much lower than being locked into a PaaS vendor or getting your business completely disrupted. Also, in some extreme cases, it may not be entirely possible to mimic the PaaS vendor’s setup but, as I pointed out earlier, it is still possible to ensure portability with proper application architecture strategy.

Under this context, CloudFoundry, by itself, is very important even though CloudFoundry Core may not be all that important.

PS: There is still a possibility of vendor lock-in in spite of the open source nature of CloudFoundry but my main argument is that such a lock-in risk is significantly lower in the case of CloudFoundry.