VMware Cloud Foundry – were VMware’s partners simply too slow?

VMware’s launch of Cloud Foundry has put them in direct competition with some of their service provider partners, just weeks after attempting to reassure them that VMware was not a service provider.

Cloudfoundry.com, a complete hosted PaaS environment managed by VMware directly, in a similar vein to Google App Engine, Heroku, and others. Just weeks ago, when VMware took over the running of Mozy from their parent company EMC, VMware were giving out the message “VMware are not a service provider and not competing with our service provider partners”, but with cloudfoundry.com, the level of competition is pretty clear.

In the backend software powering the service, branded as cloudfoundry.org, “The open platform as a service project”, VMware have made a powerful move packaging various open-source technologies into a ready to build platform that lets service providers build their own PaaS offerings, pretty much the area that VMware already worked – providing the tools to let others build the finished offering to customers. Packaging open source products has proven to be a very effective business model for Red Hat, amongst others, so this isn’t a case of “giving up” on selling software by VMware.

While I’m sure VMware don’t want to upset their service provider partners, cloudfoundry.com is obviously going to put a few noses out of joint, which makes me ask, why VMware went down this route.

The only answer I’ve come up with so far is that their existing partners were simply too slow and didn’t have the same level of commitment to VMware’s vision of the cloud. When VMware launched vCloud Express, I’m sure they were hoping for rapid adoption across a huge range of service providers, but it simply didn’t happen. While there are vCloud providers, you’re unlikely to stumble upon one when you’re looking for hosting.

With cloudfoundry.com, VMware ensuring that there will be a least one committed provider of their platform, but will it encourage other service providers to join in, or will they continue to hold back, struggling to decide between VMware’s offerings and building their own stack on alternatives like Xen Cloud Platform, and Openstack?

Try CloudFoundry on an AWS Micro instance

Update: Unfortunately the snapshot behind this AMI was affected by the AWS data deletion bug recently, so is no longer available. VMware haven’t yet released their own official AMI, but Rightscale’s build is excellent.

There’s lots of excitement and interest around VMware’s new open source platform as a service (PaaS) offering, but at the moment the only way to try it is either to sign up to the cloudfoundry.com service and wait for an invite, or use an image the RightScale have developed for AWS.

However, there’s no real reason the image had to be used via RightScale, so I’ve created an AWS Micro image based on the regular AWS Ubuntu 10.04 image, and following the instructions from github.

It took around 3 hours to do the full build, all the compiles, etc, so I figured it was worth making the AMI image available to everyone, so other people don’t have to do the same thing. I’ve added a 512MB swap file, as the management tools need more memory than a normal Micro image can cope with, but other than that it’s pretty much the stock image.

You can launch the public AMI instance now, from the “eu-west-1” region with the public AMI ID “ami-17dee963”. You can’t launch it from the other regions, sorry. It’ll launch as a Micro image, so it could even be free if it’s your first AWS instance.

The various build tests all pass, but sometimes it is a little slow to run (due to the lack of memory).

Login as “ubuntu”, then run:

cd ~/cloudfoundry/vcap
bin/vcap start
bin/vcap tail

And you should see everything working. If you need to do any debugging, the place to start is the github CloudFoundry VCAP section.

This image is provided as a test version, please don’t rely on it for anything, and I’ll remove the AMI image when the VMware guys launch their own CloudFoundry “Micro” package in a few weeks.

Update: Unfortunately the snapshot behind this AMI was affected by the AWS data deletion bug recently, so is no longer available. VMware haven’t yet released their own official AMI, but Rightscale’s build is excellent.

Android – The new open source cathedral

In a new blog post by Andy Rubin, Google VP of Engineering, Andy defends Android’s open-source credentials, commenting that:

  • “As always, device makers are free to modify Android to customize any range of features for Android devices”
  • “Finally, we continue to be an open source platform and will continue releasing source code when it is ready”
  • “As soon as this work is completed, we’ll publish the code”

When Andy talks about this, he reconfirms that Google will continue to publish the Android source code under an open-source licence, but he also seems to confirm that Google don’t really believe in the open source development model for Android.

By withholding the “unfinished” code (is code ever finished?) from both the public and device manufacturers like HTC, who have said they will only be able to start work on Android 3.0 once it’s released, Google are limiting the outside input into Android.

This model of “closed open source” is heavily discussed in the “The Cathedral and the Bazaar“, published by ESR in 1996, that defined much of open source development of the period, and has continued to guide people on developing open source projects. It discusses the success of open source projects such as Linux which accepted code contributions from anyone, and the failure of other open source projects where the maintainer considers only their own code to be “good enough” for release, and instead chooses to work alone, only letting people work on the new code when the developer feels ready.

If you read the paper, I think you can only come to the conclusion that Google believe in the “cathedral” development model, occassional (perhaps rare) releases that noone outside the cathedral can contribute to.

Rather than encourage unity in the Android code base, this is more likely to decrease unity, and introduce new forks, as each manufacturer has to work separately to introduce new features, which they wait for the cathedral to perform the new ceremony.

What does this mean for Android in the long-term? I’m not sure, but I’m pretty sure that HTC, Samsung, and the other device manufacturers are well down the road of their own internal forks of Android 2.3, just in case Android 3.0 never quite makes it out of Google’s currently closed door…