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.

OpenShift cartridges are pluggable components that can be combined within a single application. The built-in cartridges are different for the three versions of OpenShift, but the lists are all extensive, albeit limited to things that run on Red Hat Enterprise Linux (or Fedora, in the case of Origin, the open source version of OpenShift).

QuickStarts combine code and one or more cartridges, making it easy to install whole applications. While the OpenShift team doesn’t maintain QuickStarts, anyone who is willing to be responsible for keeping one up-to-date with security issues is free to create and post one. WordPress, Drupal, and Ghost are among the top QuickStarts. Like Cloud Foundry buildpacks, OpenShift cartridges and QuickStarts are simple to build.

OpenShift runs applications in containers called gears. Cloud Foundry runs built and packaged applications called droplets, in Droplet Execution Agents. These containers are isolated from the other gears or droplets in the PaaS, and they are lightweight compared to virtual machines. In the future, both Cloud Foundry and OpenShift will support Docker containers.

Larger considerations A key differentiator for Cloud Foundry — that is, Pivotal’s two Cloud Foundry offerings, Pivotal Web Services and Pivotal CF — is support for the Pivotal Big Data Suite, which includes Pivotal HD (Pivotal’s Hadoop distribution), HAWQ SQL for Hadoop, GemFire XD analytics, and the Spring for Apache Hadoop Java framework. The Pivotal Big Data Suite is an enterprise data warehouse that includes unlimited Pivotal HD.

According to Pivotal, in practice an administrator defines a service pool of HDFS and MapReduce instances, which take about five minutes to provision from scratch on Pivotal CF. Then a developer or an application can ask for an instance from the pool, obtain it in about two seconds, and a new instance can be created for the pool in the background. When the requested instance is no longer needed, it can be released.

Pivotal also offers a Mobile Services Suite that’s integrated with both Pivotal CF and Pivotal HD. This is based on seven years and 400 apps’ worth of know-how acquired with Xtreme Labs last year. It’s basically an MBaaS (mobile back end as a service) on Pivotal’s PaaS, with the integration extending out to mobile applications built on the platform.

A big differentiator for OpenShift is automatic application scaling, which adds gears and even nodes when an application becomes heavily used. It’s built into OpenShift and doesn’t require a front-end scaling service. You simply check a box when creating the application, then configure the traffic trigger points for adding and dropping gears.

Similarly, OpenShift automatically detects when an application is not getting any HTTP traffic and will eventually idle the gears without any intervention needed by the developer or operations. At such time as the application is requested again, OpenShift will automatically load it back into memory and handle the HTTP requests. OpenShift will even automatically start and restart misbehaving applications. All of these features reduce the amount of monitoring and operations work required to run an application on OpenShift.

Picking a PaaS My experience installing OpenShift locally went very smoothly, once I got over my misguided attempt to use an unsupported virtual machine manager. My experience installing Cloud Foundry locally was not smooth, although ActiveState’s Stackato variant was easier to install than Cloud Foundry open source. These experiences caused me to rate OpenShift higher than Cloud Foundry for installation. On the other hand, using the online version of each platform was a snap, and enterprises installing a PaaS in their own data center or on a private cloud are likely to use experienced consultants to do the setup.

The biggest pluses I see currently for OpenShift are its gear idling, which allows very high application density, and its automatic application scaling. These two features bring OpenShift up to a 9 on Management. Pivotal CF’s lack of these features lower its Management score to 8. I think most enterprise customers will appreciate both gear idling and automatic application scaling. Note that Pivotal CF does have automatic application scaling on its road map.

The biggest pluses I see currently for Cloud Foundry — specifically Pivotal CF — are its integrations with Pivotal’s big data and mobile services suites. These two very large feature areas raise Pivotal CF’s Breadth of Support score to 9. OpenShift’s lack of these integrations lower its Breadth of Support score to 8. You may or may not care about either of these integrations, depending on your plans for deployments.

Which PaaS should you choose? It depends on a lot of factors, and your IT department should do a careful evaluation. If application density is a driving factor for your installation, I would expect your team to wind up favoring OpenShift. Similarly, if your developers use Git heavily, they may favor OpenShift. On the other hand, if integrating your PaaS with big data and mobile services is high on your priority list and you don’t already have other solutions for your big data and mobile services needs, then your team may favor Pivotal CF.

For more in-depth looks at Cloud Foundry and OpenShift, read the complete reviews:

• Review: Cloud Foundry brings power and polish to PaaS
• Review: OpenShift shines for developers and ops

This article, “PaaS shoot-out: Cloud Foundry vs. OpenShift,” was originally published at InfoWorld.com. Follow the latest developments in application development, cloud computing, and open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.