OpenShift Under the Hood: Part 1 - Archived

Last week I joined Matt Hicks, Director of Engineering for OpenShift, for a webinar titled “Under the Hood of PaaS”, where we took a deeper look at the OpenShift PaaS platform. In this multipart blog series, I will summarize some key points from our discussion. You can watch a full recording of the webinar here.


Often times when comparing different PaaS options, users focus on the features they see. To really understand what a PaaS is capable of as well as it’s limitations, you have to go “under the hood” and get a better understanding of the platform it’s built on. The features available to developers in any PaaS offering will be dictated by that underlying platform, along key things like usability, reliability and security.

In our review of OpenShift, we focused on 4 key areas:

  • Developer Experience
  • Frameworks & Services
  • Container Model
  • Platform & Administration

OpenShift Core Capabilityies Graphic

In this first blog post we will cover the Developer Experience and Frameworks & Services in OpenShift.

Developer Experience

Our goal in OpenShift is to provide the best platform for application developers, so they can build amazing applications. This starts with making sure users can access OpenShift the way they want and that we provide development tools they are familiar with. Developers can access OpenShift via a rich Web Console, a Command Line Interface (CLI), or an Eclipse IDE (via the JBoss Tools plugins or through JBoss Developer Studio).

To deploy a new application stack, these interfaces connect to OpenShift via a REST API on the OpenShift Broker tier, which handles orchestration. This REST API also enables the integration of additional client interfaces, which customers and partners are using to integrate their own custom clients, including Web-based IDE’s, mobile development environments, service catalogs and more. This flexibility enables developers to work in the environment with which they are most comfortable.

For deploying application source code, OpenShift integrates Git which is a another popular choice among developers. Developers push their application code to a Git repository running on their application “Gears”. Gears are isolated containers running on a Red Hat Enterprise Linux host “Node” and a typical OpenShift deployment may have tens or hundreds of Nodes, hosting thousands of Gears or more. The user’s OpenShift Git repository can also be cloned locally, so developers can build applications on their desktop and then push code to the OpenShift platform using standard Git commands from the CLI or via the the Eclipse IDE plugin which abstracts Git. They can also pull that code from Github or their central source code management system.

Users can leverage fully integrated dependency management solutions for each language, like Maven for Java developers or NPM for Node.js, to manage their dependencies on the OpenShift platform. OpenShift also provides an optional Jenkins Continuous Integration (CI) cartridge, which enables each developer to manage their deployments via a dedicated Jenkins CI environment, by spinning up a Jenkins master and slave instances.

For users who want to deploy already compiled application binaries (i.e. WARs or EARs for Java developers), OpenShift also supports a binary deployment option and API as well as advanced features like maintaining deployment history & rollback. Developers can also SSH directly into all of their application Gears on the OpenShift platform, if they choose to do so. This also facilities integration with a user’s existing CI build infrastructure.

By leveraging standards technologies like Git, Eclipse, Jenkins, Maven, NPM, SSH and more, OpenShift provides a familiar environment for developers so they can migrate application deployment to the cloud.

Frameworks & Services

Developers also care about being able to use the programming languages, frameworks and services they want to use in order to build their applications. OpenShift was architected with this in mind and the OpenShift “Cartridge” model are how new languages, frameworks and services are integrated into the OpenShift platform. OpenShift is a multi-language or “polyglot” platform, with support for Java, Ruby, Python, PHP, JavaScript, and Perl available by default.

Java developers can leverage OpenShift’s JBoss EAP cartridge for full Java EE 6 capabilities or Tomcat. JavaScript developers can leverage Node.js or new options like Vert.x which supports server-side JavaScript, Java and additional languages running directly in the JVM. Community cartridges options like Go, Ceylon, and more are available in the OpenShift Origin community and can be run as Downloadable Cartridges. Users can also create their own cartridges to integrate new programming languages and frameworks into the OpenShift platform.

Cartridges are general purpose and can also be used for adding databases, integration middleware and other services to the OpenShift platform. OpenShift provides support for databases like MySQL, Postgres and MongoDB and provides additional services like Jenkins CI via a default set of cartridges.

Through the JBoss xPaaS initiative, additional cartridges have recently been introduced in the OpenShift community include JBoss Fuse (which provides Active-MQ based messaging and powerful Camel-based routing capabilities), JBoss Aerogears services (to integrate Push notifications and other mobile back-end services), and soon JBoss BPM (to provide business process management and rules capabilities). In the community you will find additional cartridges and quickstart options like Redis, Nginx, WordPress, Drupal and more. But even in the case where what you find isn’t exactly what you need, OpenShift users can always build their own via the extensible Cartridge model.

The meaning of “support” is also important to clarify in the context of OpenShift. A supported cartridge in OpenShift Online or OpenShift Enterprise is packaged, supported and maintained by Red Hat. This includes both the cartridge and also the underlying programming language or service runtimes. If a security CVE or other issue is identified, Red Hat provides timely patches and update supported cartridge and underlying runtimes automatically (includes backporting fixes for older supported runtime versions) in OpenShift Online or ship those patches to OpenShift Enterprise on-premise customers, not just point users to the upstream communities to get those fixes. While OpenShift also provides a large number of additional community supported cartridges in the OpenShift Origin community project, the level of default Cartridge support is unparalleled among PaaS providers and an absolute requirement for Enterprise PaaS customers.

Next, continue to Part 2 where we’ll look at the Container Model and Platform & Administration.

OpenShift Container Platform, OpenShift Online, OpenShift Origin, Thought Leadership
Comments are closed.