A High-Level Overview of OpenShift and Cloud Foundry: Features and Architectures
The two leading PaaS systems
Among all open-source projects in the category known as Platform-as-a-Service, OpenShift and Cloud Foundry have amassed the strongest development communities. With similar functionality and goals, both make it possible to write code in a variety of languages and deploy applications to public or private clouds. Both are evolving extremely fast.
Though the launch of the Cloud Foundry Foundation (Feb 24, 2014) changed the game for the entire PaaS industry, few—if any—in-depth comparisons of OpenShift and Cloud Foundry exist yet. We wanted to contribute to this by combining a high-level overview of Cloud Foundry and OpenShift.
Today, we are publishing “OpenShift and Cloud Foundry PaaS: a High-level Overview of Features and Architectures,” a chapter from a deeper research that is still in progress. This document includes 2 tables and 2 diagrams that compare the available functionality as of February 2014.
Please note that this is only the initial version of the document, a 10-page chapter. We understand that for a comprehensive comparison much more info is needed (e.g., adoption, deployment, ALM, etc.). Depending on what will happen to these two platforms in the months coming after the Cloud Foundry Foundation announcement, an extended paper may be published later. We’re already working on it.
As for now, any feedback from the members of the community on the accuracy of data in this white paper is welcome. Your opinions will help to make this and future comparisons as fair as possible. If you have any suggestions on the possible roadmap for this document, feel free to let me know, as well.
Architectures in a nutshell
When I was digging into the architectures of Cloud Foundry and OpenShift for a high-level overview, it became obvious that many of their major components have similar functionality:
- Routers manage user traffic.
- Working Nodes are used to stage and run web applications.
- Managers are the components that manage and monitor Working Nodes and take care of them in case of failures.
- The Messaging Bus enables collaboration between different parts of a distributed PaaS.
Although similar in functionality, these components use different technologies:
| Router | Brokers, HAProxy Gears | Router |
| Working Nodes | Gears | Warden containers within DEA |
| Messaging Bus | ActiveMQ | NATS |
| Managers | Brokers | Cloud Controller, Health Managers |
| Providing resources and services to applications | Cartridges | Buildpacks and services |
OpenShift uses unified abstractions to work with applications in the cloud. Its Gears are designed to run apps with separate access to shared resources and are implemented as lightweight containers. Cartridges provide the actual functionality necessary to run a user application. They add support for programming languages and access to various databases. Cartridges are the add-ons that contain binaries, setup, and control scripts that make it possible to deploy and maintain the functionality of applications.
OpenShift’s Brokers are the point of contact for all application management activities and traffic. They are implemented as daemons responsible for managing user logins, domain name systems, and application status. Nodes and Broker Support Nodes (BSN) represent the lower layer of the OpenShift architecture. Nodes are the physical machines where the Gears are allocated, while BSN are the Nodes that run Brokers. BSN and Nodes are connected through a Messaging Bus—for this purpose, OpenShift uses ActiveMQ.
Cloud Foundry has more direct and straightforward abstractions. The dynamic routing layer (Router) handles all the traffic. It resolves application traffic and developers’ Cloud Foundry REST API requests. Cloud Controller is responsible for all management tasks. Being the main endpoint for the Cloud Foundry REST API, it uses the UAA module to authenticate and authorize users. Health Manager monitors the status of applications and takes appropriate actions, when it changes (e.g., if an instance is down, it automatically triggers the system to create a new one). The NATS messaging system processes notifications. Services provide everything that an application may need to work properly with other resources, such as databases and external services.
Both OpenShift and Cloud Foundry support container management. Red Hat provides application container isolation via Docker, while Cloud Foundry relies on Warden. Although Docker and Warden serve the same purpose—providing resource isolation to applications (CPU, memory, etc.)—they use different approaches to achieve this. However, with the Decker project, Cloud Foundry is now a step closer to Docker.
It is also worth mentioning that one of the greatest advantages of Cloud Foundry is support for Heroku buildpacks. These bundles of detection and configuration scripts can deploy applications, as well as install all the application dependencies. When you push an application, the system automatically applies the appropriate buildpack—or you can set it manually.
You can find more details on the topic in my basic overview of OpenShift and Cloud Foundry (features and architectures). The document is by no means exhaustive, but only part of a bigger project.
Further reading
