A practical way to choose—without getting lost in hype
Over the last few years, choosing an infrastructure platform has become strangely harder, not easier. We have more options, more marketing, and more strong opinions than ever before. Proxmox, OpenStack, OpenShift, Kubernetes, cloud-native, private cloud—everything sounds important, future-proof, and urgent.
But when you strip away the buzzwords, most organisations are still trying to answer a very simple question:
How do we run our workloads reliably, without making life harder for the people who operate them?
This article is my attempt to explain, in plain terms, how Proxmox, OpenStack, and OpenShift differ, and how to choose between them wisely.
Let’s start with a hard truth: there is no “best” platform.
Every bad infrastructure decision I’ve seen came from choosing a platform for strategic or political reasons instead of operational reality. The right platform is the one that fits your workloads, your team’s skills, and where your organisation is actually heading—not where it claims it wants to be in five years.
Proxmox is the easiest to explain, and that’s part of its strength.
Proxmox is a virtualisation platform. Its primary job is to run virtual machines. It does that very well. The model is familiar: hosts, clusters, storage, networks, VMs. If you come from VMware or any traditional hypervisor background, Proxmox feels natural almost immediately.
It’s simple, honest, and efficient. You deploy it, create VMs, attach storage, and get on with your work. Containers exist in Proxmox, but they are not the centre of the design. Proxmox assumes you think in terms of servers, not applications. For many organisations, that is still perfectly fine.
If your environment is VM-heavy and likely to remain that way, Proxmox is often the most sensible choice.
OpenStack sits at the opposite end of the spectrum.
OpenStack is not really “virtualisation” in the traditional sense. It is a private cloud platform, designed to behave more like AWS than like VMware. It breaks infrastructure into services—compute, networking, storage—and exposes them through APIs.
This gives you enormous flexibility and scale, but at a cost. OpenStack is complex to deploy, complex to operate, and unforgiving if you do not have dedicated skills. It shines in very large environments, service providers, and organisations that genuinely need cloud-style self-service at scale.
For smaller teams, OpenStack often becomes a burden. Not because it is bad technology, but because it demands an operational maturity many organisations simply do not have.
OpenShift is different from both—and this is where confusion usually begins.
OpenShift is not a virtualisation platform. It is an enterprise Kubernetes platform. Its primary purpose is to run applications packaged as containers, not servers packaged as VMs.
Kubernetes changes the unit of thinking. Instead of managing servers, you manage workloads. Instead of worrying about individual machines, you describe desired state and let the platform handle placement, restarts, and scaling.
OpenShift takes Kubernetes and makes it enterprise-ready by adding security, networking, storage integration, upgrades, and support. It is opinionated by design. You are expected to follow the Kubernetes way of doing things.
This is powerful—but only if you actually want that model.
The big question many people ask is:
“If OpenShift can run VMs, why not use it instead of Proxmox or OpenStack?”
Technically, OpenShift can run VMs using a project called KubeVirt, exposed as OpenShift Virtualization. Each VM runs inside a Kubernetes pod. Storage is usually shared block storage, just like in traditional hypervisors. From the VM’s point of view, it looks normal.
But here is the critical point:
VMs do not magically become cloud-native just because they run on Kubernetes.
A VM still maps to exactly one pod. There is no horizontal scaling. There is no replica set. There is no auto-scaling like a web service. You gain centralised scheduling and automation, but you lose the simplicity of a purpose-built hypervisor.
So yes—running VMs on Kubernetes does sacrifice most Kubernetes advantages. And that is not a flaw; it is simply a consequence of what a VM is.
Which raises the obvious question:
Why do companies still do this?
The answer is mostly organisational, not technical.
Many organisations already decided that Kubernetes or OpenShift is their primary platform. They want one cluster, one control plane, one skill set, and one operational model. Running a separate OpenStack or Proxmox cluster means another team, another upgrade cycle, another set of failures to manage.
In that context, VMs in OpenShift are not there because they are better. They are there because they are good enough, and they avoid running yet another platform.
VMs become “things we still need, but don’t want a separate stack for”.
This is why OpenShift should never be chosen as a VMware replacement unless there is a serious commitment to containers.
If your workloads will remain VM-heavy, and your teams think in servers, OpenShift will feel over-engineered and frustrating. If containers are genuinely the future of your platform, then OpenShift can make sense—even if VM support feels clunky compared to Proxmox.
So how should you choose?
If your primary concern is running stable virtual machines with minimal complexity, Proxmox is often the right answer.
If you need cloud-scale infrastructure with self-service and are prepared for the operational cost, OpenStack can be powerful.
If your organisation is moving towards application platforms, CI/CD, GitOps, and container-first thinking, OpenShift is a strategic choice—not a virtualisation one.
The biggest mistake is choosing a platform based on where the industry says it is going, rather than where your organisation actually is.
Infrastructure decisions rarely fail loudly. They fail slowly—through frustration, complexity, and burnt-out teams.
Choose the platform that matches how you work today, not how you hope to work someday.
Comments
Post a Comment