Imagine you buy a Ferrari. A beautiful machine — the most capable car on the road. The salesperson hands you the keys and shakes your hand. What they don’t mention is the mandatory chauffeur in the front seat. He controls the route. He controls the speed. He decides when the car needs servicing, which garage it goes to, and how much it costs. You own the car on paper. You don’t drive it.
That is OpenShift. And the chauffeur is IBM.
OpenShift is Kubernetes. The same open-source container orchestration platform that powers the world’s largest infrastructure deployments, available free of charge, maintained by a global community of engineers. Red Hat — owned by IBM since 2019 — takes that free platform and wraps it in a proprietary layer: a custom installer, a proprietary security model, a mandatory operator framework, a branded console, and a support contract that ties everything together.
The pitch to a CTO is irresistible: enterprise-grade Kubernetes, fully supported, with someone to call when it breaks. That pitch is not wrong. It is simply incomplete. What it omits is the cost of what you give up to get there.
OpenShift is a support contract sold on top of free software. The support is real. The software beneath it is the same Kubernetes your engineers could run themselves. The question is not whether the support has value — it is whether that value is worth surrendering control of your infrastructure to a vendor whose parent company is IBM.
Standard Kubernetes has a permissive default security posture that your teams configure to match your requirements. OpenShift ships with Security Context Constraints — a proprietary security layer that sits on top of Kubernetes’ native mechanisms and enforces Red Hat’s opinions about how containers should run.
In practice, this means that roughly half the Helm charts, container images, and off-the-shelf tools your engineers want to deploy will fail on first attempt. Databases, monitoring stacks, ingress controllers, AI inference servers — anything that expects to run as root, or assumes standard Kubernetes RBAC, will hit a wall. Your engineers then spend hours or days not solving business problems, but negotiating with OpenShift’s security model to get standard software running.
The CTO sees “enterprise security.” The engineering team sees a tax on every deployment.
Vendor lock-in in cloud infrastructure is usually a gradual process — you use proprietary services, build dependencies, and eventually find that leaving is expensive but possible. OpenShift lock-in begins at installation.
The OpenShift installer does not produce a standard Kubernetes cluster. It produces an OpenShift cluster — a distinct platform with its own operator lifecycle manager, its own image registry expectations, its own update mechanism, and its own network plugin defaults. Skills, tooling, and automation built for OpenShift do not transfer cleanly to vanilla Kubernetes or any other distribution. The two platforms are related but not interchangeable, by design.
This is not a bug in the product. It is the business model.
Red Hat was an independent company with a clear open-source identity. IBM acquired it for $34 billion in 2019. IBM’s core business is enterprise services, consulting, and software licensing — a model that has historically prioritised long-term customer dependency over customer autonomy.
The relevant question for a CTO is not whether IBM is a trustworthy company. It is whether the incentives of a $34 billion acquisition are aligned with your organisation’s interest in maintaining infrastructure independence. Those two things are structurally in tension.
OpenShift pricing, roadmap priorities, and support terms are set by IBM. The free software underneath — Kubernetes, Linux, the container runtime — will always exist. But the proprietary layer you have built your operations on top of belongs to someone else, and that someone else answers to IBM shareholders, not to your board.
IBM has a documented history of acquiring technology companies and shifting their product strategy toward enterprise consulting and licensing over time. Red Hat has retained significant autonomy so far. “So far” is not an infrastructure strategy. The organisation that built its Kubernetes operations on OpenShift in 2020 is more dependent on IBM’s strategic decisions in 2026 than it was when it signed the first contract.
OpenShift licensing is subscription-based, priced per core. For a production cluster of meaningful size — say 20 nodes at 32 cores each — the annual subscription cost runs into six figures before a single workload is deployed. That is the cost of the chauffeur, not the car.
Beneath the subscription, the car is free. Kubernetes is free. The Linux operating system is free. The container runtime is free. The ingress controllers, monitoring stacks, certificate managers, and storage drivers your cluster depends on are all open source. The OpenShift subscription pays for Red Hat’s opinions about how those free things should be assembled, and a phone number to call when something breaks.
A team of competent Kubernetes engineers — the kind your organisation should be employing regardless of which platform you run — provides the same outcome without the subscription, without the proprietary constraints, and without the vendor dependency. The break-even calculation is not complicated.
| Factor | OpenShift | Bare Metal Kubernetes |
|---|---|---|
| Underlying platform | Kubernetes | Kubernetes |
| Vendor lock-in | ✗ High — IBM/Red Hat | ✓ None |
| Standard Helm chart compatibility | ✗ Partial — SCC conflicts | ✓ Full |
| Security model | ✗ Proprietary SCC layer | ✓ Native Kubernetes RBAC |
| Upgrade control | ✗ Red Hat schedule | ✓ Your schedule |
| Annual licensing (20-node cluster) | $180,000–$320,000 | $0 |
| Engineer skill portability | ✗ OpenShift-specific | ✓ Industry-standard |
| Exit cost | ✗ High and growing | ✓ None |
| Roadmap ownership | ✗ IBM | ✓ You |
The strongest case for OpenShift is the support contract. When production is down at 2am, having Red Hat’s engineers available matters. That is a legitimate value proposition, and it should not be dismissed.
But the support argument assumes something that deserves scrutiny: that your organisation lacks the internal capability to operate Kubernetes reliably. If that is true, the correct response is to build that capability — because no support contract substitutes for understanding what you are running. The organisations that call Red Hat at 2am are, more often than not, organisations that outsourced understanding along with operations.
A team that owns its Kubernetes platform — that built it, understands it, and operates it daily — resolves incidents faster than a support ticket. They also do not pay six figures a year for the privilege of filing one.
If Red Hat doubled the subscription price next renewal cycle, what would it cost your organisation to leave? How long would the migration take? How much of your operational tooling is now OpenShift-specific? How many of your engineers know vanilla Kubernetes versus OpenShift?
If the honest answer is that leaving would be painful, expensive, and disruptive — that is the lock-in working as designed. The chauffeur knows you need the car more than you need the keys.
The organisations that avoid this situation are the ones that ask the question before they sign, not three years and two renewal cycles later.
Kubernetes is infrastructure you can own. OpenShift is infrastructure you rent from IBM while believing you own it. The difference matters most on the day you want to leave.
Sugau specialises in bare-metal Kubernetes deployments without vendor dependency — the same capability OpenShift promises, built on infrastructure your organisation fully controls.
Find out what running Kubernetes without a vendor subscription would cost your organisation — and what you are currently paying for that you do not need.
Get Your Free Assessment