The Broadcom changes have forced every team to rethink what’s next. Most start with cost, but the real question is control.
How do you build infrastructure that will still serve you 10 years from now, one that’s agile enough not to get trapped in the same problem again?
In the full picture, year one isn’t cheaper. You pay to set up, migrate, refactor, and train. Break-even might come three to five years later, and even then, you’re still paying in engineering time to keep systems stable and learn the new stack. Then renewals hit. And costs rise again.
Freedom comes from infrastructure agility.
If that’s the goal, is Kubernetes the open standard worth betting on? Has it proven it’s here to stay? And if it has, who’s the right partner to start with?
We believe Kubernetes represents that standard—and Red Hat provides the most stable foundation for the next decade of infrastructure agility.
Kubernetes has become the standard because of how widely it’s used and supported.
Since its release in 2014, it has proven stable over time. Major providers like Google, Red Hat, Microsoft, VMware, and Amazon all contribute to it. It’s no longer just an open-source project. It’s a mature ecosystem that powers modern infrastructure.
Kubernetes has taken the same role Linux did for operating systems. Linux became the open standard for running software on any hardware. Kubernetes has become the open standard for running workloads across any infrastructure.
Other options exist. You could use Nomad for containers, or run KVM directly on Linux for virtual machines. But those tie you to their own models.
Kubernetes was built as an open standard from the start.
The difference between Kubernetes and older open projects like OpenStack is adoption. OpenStack had community support, but never reached this level of use. Kubernetes is everywhere now (across clouds, data centers, and industries). Amazon, Microsoft, and Red Hat each have their own version. And they all run on the same foundation.
That scale makes it hard to replace.
If you want to run containers or virtual machines across multiple environments without getting locked into one provider, Kubernetes is the practical choice. There’s no other platform that orchestrates workloads across clouds while preserving flexibility. It’s too ingrained in modern infrastructure to ignore.
When you adopt Kubernetes, you’re adopting a standard, not just exchanging vendors.
The API and libraries define that standard. You can move between providers: OpenShift on AWS, Rancher on-prem, or another platform if you make smart design decisions. Portability depends on how you implement it, not on which distribution you pick.
A new standard could appear someday, but it would have to solve a completely different problem.
Kubernetes now runs both containers and virtual machines, putting it in direct competition with VMware. Replacing it would require solving a new class of infrastructure problems, not just improving what exists.
With smart design, you can move workloads cleanly between Kubernetes environments. Tools like Velero, Kasten K10, and PX Backup let you lift containers, network definitions, VMs, storage, and configurations from one distribution to another without rewriting. Tools like ArgoCD, FluxCD and Fleet allow you to have consistent configuration management across multiple instances and various distributions.
Skip that planning, and you risk locking yourself into a vendor again. Remember: The standard gives you the option. How you use it decides whether you stay agile.
We can’t predict the future, but the evidence (the maturity, contributor breadth, and scale) suggests Kubernetes will last well beyond this cycle.
Kubernetes started as a container platform, but the real turning point came when it began handling virtual machines.
That’s what KubeVirt does: it lets you run VMs alongside containers under one control plane. For teams leaving VMware, that matters. You don’t have to re-platform everything overnight. You can bring existing workloads into Kubernetes and modernize on your own schedule. Red Hat’s version, OpenShift Virt, is the most mature and supported platform right now.
Red Hat is the easiest and safest place to start this move. It isn’t about vendor loyalty. It’s about maturity and support. Red Hat has been in the Kubernetes space since the beginning. OpenShift version 3 was redesigned around Kubernetes when it was first released 11 years ago. They’ve been a leading contributor to the project ever since.
Red Hat has been the most stable and enterprise-ready implementation of KubeVirt so far. They’re not new to virtualization. They wrote KVM (on which KubeVirt is built). Before that, they had Red Hat Enterprise Virtualization and OpenStack. This is their latest evolution of that experience. Their integrations, UI, and enterprise support stack make it easier to train teams and move from VMware without breaking what works.
Red Hat’s ecosystem includes migration tools, storage integrations, and a consulting team that knows how to get people off VMware without breaking what works. Their tools handle feature gaps, training, and testing so what ran in VMware still works in KubeVirt.
If your goal is a smooth first phase (and it should be) you want to start with something solid. Red Hat OpenShift gives you that. You can branch out later if you want. Providers like SUSE, Spectra Cloud, and Canonical are catching up. You can move to them down the road because starting with Red Hat doesn’t lock you in. It gives you a stable base to build from.
I have to stress this: You’re not betting on Red Hat. You’re betting on Kubernetes. Red Hat is just the doorway right now because it’s the most stable, supported, and enterprise-tested option.
If Red Hat gets too expensive or another provider passes them, you can move. You’ll stay on the same standard, avoiding a full rebuild. However, this assumes you ensure you leverage standardized solutions for CICD, storage, backup, etc or you’ll have a little rework to do.
That’s the whole point of choosing open standards.
Kubernetes gives you the tools to become more agile.
But agility isn’t automatic.
It depends on how you use it. Too many teams work too far up the stack without understanding what sits underneath. Kubernetes runs on Linux. It handles networking, storage, and automation layers, but it can’t protect you from weak fundamentals. If your team doesn’t understand those, you’re just trading one kind of lock-in for another.
Many engineers know Terraform or Ansible, but not TCP/IP or Linux basics. Cloud vendors trained people to live inside their own toolchains. When those same teams move to Kubernetes, they expect it to fill the gaps. It won’t.
The biggest risk is how teams adopt it. Some keep Kubernetes boxed inside a small specialist group where it never scales. Others roll it out too fast, before anyone understands what it’s automating. One limits growth; the other multiplies failure.
The better path is deliberate. Build engineers who understand both Kubernetes and the systems it manages. Roll it out in phases so it becomes part of how the organization works, not just another platform.
Kubernetes doesn’t make your infrastructure agile by default. It opens the door to infrastructure agility.
The rest depends on the decisions you make.
---
Derrick Sutherland - Chief Architect at Shadow-Soft
Derrick is a T-shaped technologist who can think broadly and deeply simultaneously. He holds a master's degree in cyber security, develops applications in multiple languages, and is a Kubernetes expert.