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:
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:
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.
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:
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:
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:
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.
To sum up, OpenShift brings users mainly three things:
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.