PaaS shoot-out: Cloud Foundry vs. OpenShift

PaaS (platform as a service) occupies an interesting niche in the cloud ecosystem. It typically sits on top of IaaS (infrastructure as a service), which provides the ability to access remote computing resources. With IaaS you have machines, or virtual machines, that are not on your premises, that you can use as you wish. An example of IaaS would be Amazon EC2.

PaaS includes infrastructure, storage, database, information, and process as a service. Think of PaaS as providing remote computers, disks, databases, information streams, and business processes or meta-applications, all tied up in one "stack" or "sandbox." The applications may well be SaaS (software as a service), such as a CMS (content management system) or CRM (customer relationships management) system. Where a PaaS adds value over IaaS is to automate all the provisioning of resources and applications, which can be a huge time-saver.

[ Also on InfoWorld: Cloud Foundry brings power and polish to PaaS | OpenShift shines for developers and ops | Puppet vs. Chef vs. Ansible vs. Salt | Work smarter, not harder -- download the Developers' Survival Guide | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]

The two major open source PaaS systems are Red Hat's OpenShift and Pivotal's Cloud Foundry. Both are available in three flavors: hosted, enterprise, and open source. For this review, I looked primarily at the enterprise versions, which are fully supported and intended for businesses that want to run PaaS in their own cloud or data center. In both cases, the hosted and enterprise versions are based on the open source versions.

Don't confuse PaaS systems with configuration management and orchestration tools, such as Puppet, Chef, Ansible, and Salt. You can use Puppet or the others to set up a PaaS or SaaS, or simply to manage the configuration of a whole bunch of servers. OpenShift does in fact use Puppet, and it's compatible with the others. Cloud Foundry uses a different configuration management tool: BOSH.

Small differences
Cloud Foundry and OpenShift are quite similar in their capabilities and their approach to the PaaS. While the terminology they use and the exact deployment methods differ, they are very much the same thing: Each offers a Linux platform with lightweight containers that can run applications against open source languages and frameworks, using common services such as databases.

For deployment of application source code, OpenShift uses Git, but it also allows you to deploy binary packages. Cloud Foundry only takes your binaries (.WAR files for now, with other formats to be supported later), then automatically combines them with buildpacks of languages and frameworks (such as Java and Tomcat) and services such as databases. The buildpack format was developed by Heroku and contributed to the open source community, spawning many community buildpacks, most of which work on Cloud Foundry.

Four buildpacks are standard in Cloud Foundry: Java, Node.js, Ruby, and Go. In most cases, the open source language or framework you need will be available as a buildpack, and to load it, you'll simply note the Git repository on the Cloud Foundry command line when you push your app. If the necessary buildpack is not readily available, you can easily create it in a few lines of Ruby or another scripting language.

OpenShift doesn't have buildpacks. Instead it has cartridges, which include databases as well as languages and frameworks, and QuickStarts, which are applications with code and libraries already configured for you.