Blog
January 7, 2021
For teams considering containerization, understanding the technologies needed to break from the monolith can be tricky. With new technologies, concepts (and acronyms) born every day, getting a grasp on the landscape is a challenging endeavor. The two container technologies we look at today, OpenShift and Kubernetes, are a prime example.
So what separates OpenShift vs. Kubernetes, and when should teams buy in to the OpenShift platform over Kubernetes? Let's dive in.
Table of Contents
What Is OpenShift?
OpenShift is RedHat’s Enterprise Distribution of Kubernetes.
OpenShift, and the community open source version of OpenShift, OpenShift Origin, are an end-to-end “distribution” of Kubernetes that runs on Enterprise Linux (be that RedHat Enterprise Linux, RHEL, or CentOS). An installation process takes care of configuring and managing the installation of the software required to run Kubernetes, and once installed, tools specific to OpenShift are used to manage Kubernetes, such as the OpenShift Dashboard and `oc` command line application instead of `kubectl` common to most Kubernetes environments.
Is OpenShift Free?
The community version of OpenShift is free, and is not eligible for support from RedHat. Additionally, there is no migration path between community OpenShift Origin and RedHat OpenShift.
One of the benefits of OpenShift Origin are the installers that automate the process of installing OpenShift. Tools to help you get started:
Jenkins, the CI/CD tool used to build Source-to-Image or “S2I” applications, is also bundled as a service in OpenShift, and is well integrated in the platform. Both Jenkins and S2I are OpenSouce, as is all of the monitoring included in the OpenShift.
Back to topThe OpenShift Platform
OpenShift isn’t just a way of running Kubernetes, it’s a methodology for developing microservices and applications for Kubernetes. OpenShift strongly emphasizes a blueprint methodology, in which starter projects are offered to developers as a menu of options that can be spun up as stubs via a wizard. A developer can quick-start a new project from a menu of languages, from Java and Wildfly to Ruby on Rails or Python, and end up with a git repository that can be automatically built and deployed by OpenShift.
This process is their Source to Image or “S2I” process. S2I is a transition mechanism for replacing the Cartridge system in OpenShift 2.0, which was not a Kubernetes distribution, but a too-early-to-be-ubiquitous attempt at a PaaS from RedHat. With the introduction of OpenShift 3.0, and a move to docker, containers, and Kubernetes, RedHat reimagining their PaaS offering, and in 4.0, has further refined its approach in this fast-moving space.
OpenShift Kubernetes Engine
OpenShift Kubernetes Engine is a RedHat strategy to get their foot in the door with developers who are working to implement a container or cloud-native strategy in their organization, need professional support, and need to prove that this rather expensive PaaS solution is going to solve real problems in the organization.
Plenty of Kubernetes experts will tell you, nothing in Open Source is free. Multiple people on the team need to learn some very complicated, inter-connected technologies that are written in new languages that they might have had no exposure to (GoLang in particular). Throw in new network technologies, like Istio, and perhaps new methodologies for building and deploying continuously, like Tekton or Jenkins X, and the concept of a “lite” version might seem extremely attractive to a development team that just wants to prove they can do containers first.
Consider, though, that you’re paying more to get less. All of these technologies are free and open source, and there are companies that support all of the boxes that both OpenShift and OpenShift Kubernetes Engine support for a fraction of the cost.
Back to topSee the Most Popular Open Source Container Technologies
In the State of Open Source Report, we provide data on the top open source container and infrastructure technologies, as told by a global survey of open source users. Click the button below to download your free copy of the report.
OpenShift vs. Kubernetes
Ultimately, OpenShift is a very specific way of “doing Kubernetes.” It’s going to put some guide rails down for developers who have never touched containers before, and the team’s going to feel pretty good rebuilding monolithic apps forward into the future.
PaaS vs. CaaS
RedHat has introduced YAA (yet another acronym) into the busy beehive of Buzzword as a Service: Containers as a Service, or CaaS. Platform as a Service (PaaS) had, or perhaps “has,” you tell us, a strong running as a interesting concept to developers. Ultimately, though, many critical enterprise applications don’t arrive ready-made on the menu for developers. PaaS ultimately becomes a way of rapidly testing a prototype for a concept, without having to invent tooling to do so.
The gambit was that if an entire team can use the same language, not Java or Python but business language, to describe the prototyping phase of an application that could then be placed into production, there’d be a marked increase in productivity, as demonstrated by a tons of new apps graduating to production. The reality is that at most businesses, the architectures of the “important stuff” are rigid, well-known, and, well, important.
The stakeholders of those services are risk-averse and unlikely to use a new PaaS as a migration point. What they want to see is everything working end to end, and a migration plan to get there. This reduces the emphasis on PaaS for champions of this process, and increases the emphasis on a general idea of “what if we could do containers, on demand?” Budgets are more likely to be granted for an overall improvement that doesn’t touch business critical features. So when Cloud Native and containers are on the minds of executives, developers stopped advocating for PaaS and started advocating for CaaS.
When to Use OpenShift
OpenShift is great for learning Kubernetes. It’s training wheels that get experienced developers out of the rut of monoliths and guard rails for junior developers who are coming in guns-a-blazin’ to tame the Wild West of containers.
Practically, though, developing a fundamental understanding of 12 Factor Applications and really learning the underlying mechanisms and practices of Kubernetes is more valuable to organizations. Ultimately, being able to say you’re a team of Formula One drivers, pit crew, and team managers is much more useful to any given organization than “I have no experience outside of the one McLaren has provided me.” In other words, a specialist that has gone all-in on one brand is going to take that brand with them everywhere they go, and in the technology world, vendor lock-in is not a desirable trait.
When to Use Kubernetes
I’ve mentioned a few times in this blog post the concept that a team of developers experiences great joy when they’ve been able to bring a legacy system into the future. Why is this, though?
Developers love it when they get new tools, but it’s not just because they’re goblins that collect shiny things. They want tools that make their lives easier, that crash less, that don’t call them at 2AM on a holiday when everything is on fire. Kubernetes brings increased system resilience to applications that are designed correctly. These systems fail fast, bugs show up in QAC, and typically don’t make it to production. They do this without red tape, since there’s a reliable process around deployment. Which means developers are happy.
So, when to use Kubernetes? When you want happy, engaged developers who are enjoying their evenings to themselves and are feel committed to your organization during the day when they’re working with the best new tools. Your developers can enumerate the reasons why containerization and orchestration of those containers is helpful (see my last blog post on Kubernetes here). Now it’s on you to believe them!
Back to topFinal Thoughts
Platforms like OpenShift can soften the containerization learning curve in the short term. But, as I discuss above, softening that learning curve isn't necessarily a good thing. Learning the OpenShift platform doesn't give you a fundamental understanding of 12 Factor Applications, or the underlying intricacies of Kubernetes. That understanding, however hard-earned, can mean all the difference for organizations who want to achieve the true benefits of containerization.
Get Guidance on Your Containerization Journey
If your team is moving from the monolith, our team can help guide the way. Talk to an open source architect today and get advice on which open source technologies will work best for your needs.
Additional Resources
Want to learn more about the container ecosystem? Please take some time to view our container-related resources.