VMware’s CloudFoundry and Red Hat’s OpenShift – Compare and Contrast

Over the last few weeks, VMware (as we indicated in an earlier post) and Red Hat have initiated two very similar initiatives known respectively as CloudFoundry and OpenShift. These are Platform as a Service (PaaS) plays, being developed for the longer term, primarily looking to encourage the development of (and thereafter to provide infrastructure for) applications specificallysuited to the the cloud. In this article we compare and contrast the two offerings and discuss their significance for the PaaS market as a whole.

Antecedents

Neither platform is entirely new, OpenShift is a development of the Makara Cloud (we discussed the Makara Acquisition in December 2010), but it is not derived from its own complex IaaS blueprint (Cloud Foundations). CloudFoundry a replacement of an initiative to deploy Spring on Amazon Web Services (now known as classic.cloudfoundry.com). CloudFoundry does not replace VMware’s other PaaS initiative, VMforce which it entered into with Salesforce.com about a year ago and which we  note is still in developer preview. We would suggest VMforce was a tactical announcement whereas CloudFoundry is the strategic play.

Diversity as a Strategy

Both CloudFoundry and OpenShift support a broad range of development languages and frameworks and are open in their persistence layer, with the ability to extend to other frameworks, databases and languages. They are both multi-language platforms, and both have support for both relational database and non-relational persistence. The objective is to provide full coverage (outside of the Microsoft technologies) of any development platform that an enterprise may adopt, thereby becoming a strategic cloud provider to a whole enterprise. At the core of both is open source software, and both are ambiguous about the private/public cloud debate.

Both CloudFoundry and OpenShift  are responding to the diversification we are seeing away from the J2EE/.NET polarization that existed in enterprise applications  development some years ago, with the introduction of Ruby, Python, Groovy, Spring, Rails etc. the encroachment of PHP, and the development of non-relational persistence. Some of these technologies  have not gained currency in many enterprise development shops (at least in comparison to a standard J2EE or .NET stack), but the expectation of both vendors is that useful applications can built fast using these technologies, and that they will scale elastically across the cloud, and that this may well be a simpler process than getting traditional applications built on big old relational database clusters and J2EE application servers to scale.

Both of these PaaS strategies rely on an underlying IaaS platform. The strategies in many ways mirror each other, and rely on the same underlying components, with slight variations depending on the two companies’ respective acquisitions and partnerships.  However there are significant differences.

CloudFoundry Key features:

Cloudfoundry, unlike OpenShift is one solution packaged in three different ways. If you ferret around on the internet you can find the architecture diagram to the right.

You basically drop in application-level components which scale out elastically through replication, and which access services (such as databases) which are shared, and scaled out by the platform as required and within practical limits. A degree of secured multi-tenancy is provided by running separate userIDs for each applications’ droplets, and separate databases for each application.

It is worth noting that not all the vFabric infrastructure is available yet on CloudFoundry, whereas a lot of 3rd-Party Open Source services are supported.

Languages & Application Frameworks (Currently)

• Spring for Java applications, Rails and Sinatra for Ruby apps, Node.js, Grails
• MySQL Relational Database.
• Non-Relational Persistence MongoDB, and Redis

Delivery Format:

• Cloudfoundry.com Hosted environment (Beta)
• Cloudfoundry.org open source project – download and build the source code.
• MicroCloud – This is a nice idea, it’s the whole stack (presumably in a VM) on your own dev machine, and it can take them into places which simply won’t adopt a public cloud yet – even for development (e.g. merchant banks or government).  It isn’t quite available yet.

OpenShift Key features:

OpenShift  is really two different platforms which happen to be branded with a single name.  The OpenShift Express platform is a standalone platform aimed at individuals, developers  or the extreme low end of businesses who don’t require much scalability or security.  It is very limited in the technologies it supports. OpenShift Flex is is much more broad-ranging, scalable and secure platform that builds on top of an existing IaaS platform, and is single-tenanted within the tenancy established by the IaaS infrastructure.

Express:

• Free hosting of Ruby (Rack and Rails), PHP and WSGI (Python).
• Provided as Developer Preview.
• Local SQL-Lite.  External (i.e. Bring Your Own) MySQL.
• Single image with no inbuilt scaling features. Multi-tenanted.  No dedicated servers.
• No dependency on an underlying IaaS Cloud.

Flex

• PHP and Java
• JBoss Application Server, Apache Web Server, Apache Tomcat, MySQL, PHP, Zend Framework, Java, Memcached, and MongoDB.
• Underlying architecture is an IaaS cloud – Currently Amazon Only.
• Provides auto-scaling by leveraging the IaaS infastructure through the use of Red Hat’s Deltacloud API.

Interoperability

In providing IaaS interoperability through the DeltaCloud API, there has been some commentary that OpenShift’s destiny is tied to broad adoption of DeltaCloud, however this is not actually the case. DeltaCloud is a “wrapper layer” that maps various APIs onto a single API.  It may well be a lowest-common-denominator with respect to other Cloud APIs, but as long as that lowest common denominator is adequate for OpenShift, then Red Hat has no dependency on widespread adoption of DeltaCloud since it can maintain the mapping to and from other APIs itself.

In contrast, CloudFoundry  is built on the vSphere IaaS infrastructure (provided by VMware or others), although a fig leaf of portability to Amazon IaaS infrastructure is being provided by RightScale.

Given that the messages of the two vendors are both about “openness” and the ability to run a broad range of languages, infrastructure and application frameworks, it is also worth considering whether the two platforms themselves are interoperable.

These platforms are sold to developers with the key message being that developers don’t need to become architects – the code magically drops on to the cloud and infrastructure is provided to it on demand.  It may be perplexing to non-developers that the interface to all of this is actually a command-line. The reason is that the CLI is issued by the “Launch Configuration” deployment tools that are embedded in the Integrated Development Environment (IDE), which is typically Eclipse.  The sales-pitch to developers is around simplifying the generation of this command-line, and of automatically provisioning the underlying architectural elements to which it deploys.

Given the commonality in the tools and frameworks, it is the CLI that will become the primary lock-in point for developers deploying to one PaaS cloud or another and, as the cynical amongst you may have already guessed, VMware and Red Hat haven’t come up with a standard CLI.

Conclusions

These are both works in progress and their scope will doubtless grow massively.  It would be nice if the two initiatives could somehow come together, since there is a lot of overlap, but in the real world we assume they won’t.  OpenShift seems to offer broader language options – notably PHP and Python, to be more serious about IaaS-cloud neutrality, to offer better J2EE support, and also to be more mature. CloudFoundry seems more unified and to offer a better route from development to production irrespective of whether the choice is made to use private or public clouds.

The main conclusion is, however, that in the end-game of PaaS clouds (in perhaps 5 or 10 years time) all clouds are going to offer diversity.  There won’t be special-purpose Ruby clouds, or Python Clouds, or Clouds based on Cloud-specific proprietary interfaces (e.g. Force), the PaaS infrastructure will support a broad range of technologies and be sold strategically to an enterprise for all the applications it chooses to deploy that way. I suspect that VMWare would win this fight against Red Hat, but the real competitors will be IBM and HP and we should await their offerings.

We also come back to the story around Novell, and our speculation over the last year or so.  It looks like Attachmate has retained a lot of patents in the Novell/SUSE acquisition, and may well still have the rights to the .NET clone, Mono.  In which case, we may see someone acquire Novell to add a .NET flavour to its diverse PaaS play.  That would be exciting. It might also be worth noting that (as we noted around a year ago) it is possible to run PHP on Microsoft’s Azure, although we still haven’t found a reason for doing so.