OpenShift vs. Kubernetes: Are they really in competition?

OpenShift includes Kubernetes, and more…

What is Kubernetes?

To better understand what OpenShift is and how it differs from Kubernetes, we first need to understand what Kubernetes is.

We often see what the classic Kubernetes suite can do. We know that it can efficiently deploy applications through the use of Deployments, ReplicaSet, Pods, containers and so on. Thus, anyone can easily have access to powerful properties such as high availability and scalability without having to implement it.

However, we often miss that these are just a set of functionalities integrated into the Kubernetes architecture. Indeed, the true beauty of Kubernetes is that you can extend it in many ways, for example by adding:

• API resources for certificate management (E.g. cert-manager Certificates, Issuers, ...)
• Controllers to manage Ingresses or storage provisioners
• Plugins in the API Server for resource customization at creation time (E.g. Istio proxies)
• Service brokers to give users the ability to provision external services from within the cluster (e.g. AWS services)

So, you could implement your resources and controllers to create new tools and workflows to better fit your applications’ needs. Especially if you think those which already exist are not good enough.

In the end, one shouldn’t think of Kubernetes as a product, but as a kind of framework. This post makes a great parallel with Linux distributions and talks about Kubernetes distributions.

So, when installing and configuring Kubernetes, you need to find the Kubernetes distribution that best suits you.

Classic examples of distributions include, for example:

• Red Hat OKD
• GCP GKE
• and AWS EKS

To go further, you may also decide to install some specific pods to provide additional functionalities to your environment, such as user authentication, monitoring, storage provisioners, etc.

As we will see in the next part, OpenShift kind of does both and even a little more to give you the best Kubernetes experience.

OpenShift brings professional and production-oriented experience

Now, does OpenShift mean using Kubernetes, or even containers? Not really…

Until OpenShift 3, Kubernetes was not even a part of this product. So OpenShift is not really about using Kubernetes. It’s about giving users a professional and efficient way of deploying and manage containerized applications.

Yet, nowadays, Kubernetes seems to be one of the most powerful toolboxes to achieve that goal. That’s why it was adopted by Red Hat at some point as the core component of OpenShift. They began to customize it and built what ended up being the OpenShift Kubernetes Distribution (OKD).

OKD is built on top of Kubernetes and gives you additional resources like:

• Routes as an alternative to Ingresses
• DeploymentConfigs as an alternative to Deployments
• Builds and BuildConfigs as a code pipelines management
• ImageStreams as an interface with an internal Docker registry
• Templates to share resources models as cluster resources

At this point maybe you will wonder: was it really necessary to create an alternative to Ingresses for example? Wasn’t it possible to add new functionalities to the actual Ingresses instead, therefore, increasing the power of the existing Kubernetes tools?

The answer is simple: Ingresses simply didn’t exist at the time Red Hat developed Routes.

So Red Hat just added in OKD what they thought Kubernetes was missing for professional use.

That being done, they also conceived a way to install and configure it that also come with the following to increase your Kubernetes experience:

• Increased security: from Kubernetes high level functionalities to containers runtime constraints.
• Monitoring tools such as Prometheus, Grafana and EFK
• An internal Docker registry
• Jenkins integration
• Service brokers for external services provisioning
• Storage provisioners to provide PhysicalVolumes to your PhysicalVolumeClaims

The underlying architecture as well is taken care of by Red Hat to ensure availability and security, and to prevent congestions for example.

And of course, they provide different levels of user and admin support. You will have to pay for that, but that may save you a lot of debugging time.

All of this is available in many different commercial packages and can be deployed on-premise as well as on cloud providers infrastructures.

So that’s what OpenShift is in the end: a production-ready version of Kubernetes.

The following picture show a high-level view of OpenShift:

• With Kubernetes and Docker at the center, as a way of orchestrating containers.
• With additional well known software around it for monitoring, storage, etc.
• And with the key guiding lines at the bottom

Red Hat OpenShift is therefore really more than just Kubernetes. Yet, does anyone need to use it? That’s what we will discuss just now.

When should I chose to use OpenShift?

To sum up, OpenShift brings users mainly three things:

• Additional functionalities
• Production-ready deployment and configuration
• Professional support

Thus, it will save you from the trouble of learning how to use and configure Kubernetes by yourself, with enough maturity to ensure your applications run in state-of-the-art conditions.

Yet, it comes with a cost. Not everyone is willing (or able) to pay. And right now, all of the major cloud providers offer easy-to-use Kubernetes engines like Google Cloud GKE or Amazon EKS.

Be aware that what those cloud providers offer is not an end-product but more likely an even bigger toolbox. This bigger toolbox is containing a Kubernetes engine and many other services (e.g. databases) you will be able to integrate with it. By doing so, you may obtain something as powerful as a full OpenShift installation. But to do so, you will have to discover these services as well as Kubernetes, learn what you can do with them, how to use them properly and so on. Therefore, inevitably making errors along the way.

In the end, more often than not small a tech-oriented companies will prefer doing it themselves, for example using cloud providers infrastructures. This way the initial investment is less important, and you can do exactly what you want.

But don’t forget that if you can afford it, OpenShift may prevent you from many Saturday nights debugging alone what you thought had absolutely no reason to fail. If you want more information about OpenShift, do not hesitate to contact us.