OpenShift is a private PaaS solution (Platform-as-a-Service) to build, deploy and run applications into containers. Open source, it is available under Apache 2.0 licence and released into 2 versions: Origin (community) and Enterprise.
Since July 2014, OpenShift has been working on an ambitious refactoring project of its technical architecture to integrate - the now inevitable - Docker and Kubernetes.
Launching this project a year ago was a notably bold and risky strategy for OpenShift. Indeed, while the competition with Cloud Foundry was at its peak, OpenShift chose to launch an important reengineering project with side effect of freezing development of new features and compromising compatibility with previous versions. We now believe they made the right choice.
To date, the Origin project federates 86 contributors on Github (of which the 10 most active work at Red Hat). This quite active community made about 16 iterations in 12 months and has just published its already very promising first release.
Although the solution is mainly driven by Red Hat, it heavily depends on Kubernetes (by Google). This raises the complex question of governance which depends on good collaboration and visions alignment of the two companies. What will happen with future features developed by Google: will they focus on Kubernetes or OpenShift? Obviously, the question is not yet settled.
However, if the support of Google is confirmed, a two-headed governance of these giants can only be beneficial to OpenShift. It will confirm its competitive advantage over Docker Enterprise (Machine, Compose and Swarm).
OpenShift v3 offers 3 native ways to build automatically an application :
OpenShift 3 also allows to define an automated deployment strategy of an application when a new image version is published in the registry or when the configuration of the application is updated.
To complete these build and deployment features, OpenShift 3 provides the ability to define its own application blueprints as template files described in Json or Yaml format. These blueprints describe both the topology of the application architecture and the containers deployment policy. The diagram below illustrates the assembly of the different components of a template for a 3-tier application in OpenShift.
The components assembled in a "template" are partially inherited from Kubernetes concepts. The main objects to remember are:
Through its multiple deployment mechanisms and the ability to set its own "blueprints" OpenShift v3 comply to the most complex application architectures.
A deployment of an OpenShift 3 infrastructure can be done in standalone mode (using the docker image “openshift/origin”), or in a distributed way using the ANSIBLE playbooks provided by OpenShift. In the latter case, two kinds of server roles are used: “Master” and “Node”.
The “Master” nodes purpose is to:
“Masters” rely on a distributed directory based on etcd to provide configuration sharing and services discovery.
“Nodes” host the PODS and run containers (applications and/or Registry****).
The architecture is at the same time distributed, scalable and resilient. However, automatic scalability is not yet supported by the platform itself: provisioning and capacity planning of the underlying servers currently have to be done manually.
The platform can be accessed and managed through its REST API, its CLI or its Web portal (but currently only in read-only mode for the latter).
OpenShift 3 offers an interesting bridge between the “Plateform-as-a-Service” world and the “Container-as-a-Service” (CaaS) world. Red Hat came up here with a bold solution and a state-of-the-art architecture. We strongly appreciate the “blueprints” specification format for architecture definition and deployment orchestration.
In the beta 3 version, OpenShift platform didn’t put a strong focus on platform operability. It shouldn’t be used in production yet. However, user stories on that matter can be found in the roadmap:
We believe that modeling an application in OpenShift 3 is a new job that will require new skills in order to ask the appropriate questions: how to organize the containers? Should routes or services be used? How to handle data (persistence, replication, backup)? How to manage multi-tenancy? How to integrate Development and Deployment Software Factory?
To sum up, OpenShift is a very promising private PaaS solution. It allows to reduce the time to market by automating application building and deployment processes from the very beginning of the project. It supports the most complex web architectures, even if the topics of data management and external services integration are not fully addressed currently.
We believe Openshift 3 has everything in hand to become a reference in the area of D****ocker based private PaaS.
To go further: http://fr.slideshare.net/NewHopeKim/open-shift-and-docker-october2014