At the risk of giving people SATs flashbacks, the admission that OpenShift is not, was not, was never supposed to be, and will never be kubernetes has happened. It feels good to have that clarity, even if the marketing and sales folks haven’t changed their tunes yet.
In the beginning
Different solutions to different problems. An emerging technology with a completely different mindset from the existing one. Abstractions for runtime CPU usage lead to abstractions in storage and networking. The solutions converge on the same basic principles.
What does one expect of a company that makes hundreds of dollars per year repackaging open source software, enhancing it with proprietary stuff, and then licensing the software and support contracts?
Kubernetes looks pretty open source to me.
On-again, off-again relationship phase
Having a lot of the same keywords and solution appeal, many organizations weigh alternatives with the help of some embedded RedHat Professional Services teams who are just there to keep RHEL6 patched. OpenShift looks pretty good.
RedHat commits to Kubernetes, promises to upstream a bunch of changes to SIGs to solve problems and deficiencies with Kubernetes. These fixes are a mixed bag of helpful things and compromises that try to bend the open source software to the way Red Hat prefers things to work.
OpenShift 3 was still pretty far from Kubernetes.
“WE WERE ON A BREAK”
Trying to close the gap between OpenShift and Kubernetes, RedHat pushed hard with the 4.0 release and next few minor versions to achieve CNCF compliance on the API. RedHat also added the classic CI pipeline tool, Jenkins, to their platform to add “DevOps” keywords. CNCF, on the other hand, is focused on keeping Kubernetes as a proven core with an ecosystem of storage, networking, monitoring, interface, automation, and development tools.
Reconciliation
By 4.3 or so, RedHat was touting OpenShift’s “CNCF compliance” among their credentials for how Kubernetes it is. It’s entirely Kubernetes under the hood, but with extra added stuff like a dashboard and persistent storage which requires containers to abandon their UIDs and GIDs. Not a tough trade-off. I mean how many people use UIDs and GIDs in their Linux software? Most of them. Yeah.
Years of “OpenShift is Kubernetes” is undermined
Amazon Web Services (AWS) and RedHat announce a new offering on AWS: Managed OpenShift. Azure has had their own Managed OpenShift for some time as well.
We can finally rest knowing that RedHat has no plans of making workloads portable between Kubernetes and OpenShift. If you need a multicloud strategy, they can all be OpenShift now. How’s that for vendor lock-in?
But
On the AWS and Azure[5] pages talking about OpenShift, there are no references to Kubernetes but front-and-center in the hero block on RedHat’s OpenShift on AWS page, it shows this.
And they lived happily ever after
The analogy breaks down here assuming no big reconciliation and air travel shenanigans. I fully expect RedHat to keep up the pressure saying that OpenShift is Kubernetes and most people nodding along because why wouldn’t it be?
Disclaimers
- The author does not believe OpenShift is bad at being a container platform
- The author does not believe OpenShift is close enough to Kubernetes to be called Kubernetes
- The author didn’t pay that much attention to Friends, it was just on before The Simpsons
- The author believes the constraints enforced by Kubernetes lead developers and operators down a good path toward focusing on the right problems and arriving at the best solutions, this is lost in OpenShift
- Azure’s page says “Kubernetes” twice, once under the “Enterprise” heading and once later about how they added a bunch of stuff on top of what would be considered Kubernetes. AWS wins in marketing scruples for this one.