With the launch of VMware’s vFabric Data Director, and the first of many databases that it will manage, vFabric Postgres, it seems VMware have made the first step in differentiating their hosted platform cloudfoundry.com from the open source Cloud Foundry project.
While most of the news and blog posts discussed the impressive technology behind vFabric Data Director and vFabric Postgres (both seem very nice), the SpringSource blog talked about using vFabric Postgres on CloudFoundry.com.
As they put it themselves:
To power the PostgreSQL service on cloudfoundry.com the Cloud Foundry team is using vFabric Postgres 9.0, a vSphere-optimized version of Postgres
While vFabric Postgres and the open source Postgres are currently identical to developers, this seems unlikely to last in the long run, as development streams diverge over time with new version releases and new feature requests – especially when a big part of the Postgres project’s famous reliability comes from their slow and steady development process.
It’s possible that the Cloud Foundry developers will not make use of any features only available in vFabric Postgres, but this seems quite unlikely given that they’re likely to be the ones asking for features to be added in the first place.
Of course, I’m sure it won’t be long until there’s a vFabric Redis, vFabric RabbitMQ, and so on, for all the different VMware owned open source products, and CloudFoundry.com is now likely to adopt them all.
This makes me wonder, in a couple of years will it still be possible to build a private cloud platform comparable to CloudFoundry.com using the code from cloudfoundry.org, and indeed for someone else to build a competitor to cloudfoundry.com, without first licencing closed source code from VMware themselves?
If VMware do choose to make CloudFoundry.com reliant on functionality from the proprietary vFabric products, this would be a great shame for an excellent open source project.
You don’t have to use the vSphere optimized version of Postgres with the code from cloudfoundry.org. You can easily use a standard PostgreSQL install. That’s what I’m using locally right now. Anyone creating their own cloud using the coudfoundry.org code can choose what services to provide and whether to use some custom version of these services or not.
As I tried to say in the post, I totally understand that you can use the standard version of Postgres today, my thoughts are more around the future of CloudFoundry.com vs Cloud Foundry the open source project.
At some point, someone is bound to add a feature to vFabric Postgres (or vFabric Redis, etc) which isn’t 100% compatible with Postgres, and at that point, will we end up with CloudFoundry.com starting to rely on the functionality of the VMware version of the product? If that happens, then we’ll end up with a situation where the CloudFoundry.com hosted service is running off a different code base from CloudFoundry.org, which would be a pity even if the differences are slight.