Somewhere along the way, "we need to run some containers" quietly became "so we need Kubernetes," and the second half stopped getting questioned. You stand up a cluster, or pay for a managed one, and now you own a distributed control plane: etcd, an API server, a scheduler, a controller manager, plus a kubelet and kube-proxy on every node, and that's before the CNI plugin, the ingress controller, and the operators. For a fleet at Spotify scale, that machine earns its keep. For a team running twenty services, it's a lot of orchestrator to babysit for a job that was never that hard.
There's a quieter answer that's been in production at Cloudflare, Roblox, Trivago and CircleCI for years: HashiCorp Nomad. It's a single binary. The same executable is your server and your client; it stores its own state with built-in Raft and needs no etcd, no separate datastore, nothing external to coordinate. And to head off the obvious "toy" assumption: Nomad scheduled two million containers across 6,000 hosts in ten AWS regions in 22 minutes in HashiCorp's C2M benchmark, roughly 1,500 containers a second. Small to run is not the same as small in what it can do.
So the honest question isn't "Nomad or Kubernetes." It's "do you actually need the cluster, or did you reach for it out of reflex?" And in 2026 the answer turns on two axes most comparisons skip: what your workloads actually are, and who you're willing to bet your platform on.
What you're actually signing up for with Kubernetes
Kubernetes is not one thing you install. Its control plane is etcd (the distributed key-value store that holds all cluster state), the kube-apiserver, the kube-scheduler, and the kube-controller-manager; every worker node then runs a kubelet and kube-proxy. On top of that base you almost always add a CNI network plugin, an ingress controller, a certificate manager, a metrics stack, and a pile of operators, because the bare cluster doesn't do much until you assemble the ecosystem around it.
None of that is a criticism, exactly. It's the price of the most powerful, most extensible orchestrator ever built, and if you need that power the price is fair. But be honest about what it is: a distributed system with its own failure modes, its own upgrade dance every few months, and enough surface area that "Kubernetes engineer" is a full job title. Managed control planes (EKS, GKE, AKS) rent you the hard parts, but you still own the nodes, the add-ons, the YAML, and the upgrades. The complexity didn't leave; someone else runs a third of it.
The tell that you might be over-buying is simple: if you can't name a concrete thing your workloads need that requires this machine, you're paying for a distributed control plane to run what a much smaller tool would schedule fine.
What Nomad is, and the part people miss
Nomad's architecture is almost aggressively boring, and that's the pitch. One binary runs in one of two modes, server or client. Servers form a small Raft cluster (usually three or five) and hold state themselves; clients run the actual work. There is no etcd, no separate API tier, no per-node proxy to operate. You run the same binary everywhere and configure what it is. The operational surface is a rounding error next to a Kubernetes control plane.
But the differentiator that actually matters isn't "simpler Kubernetes." It's that Nomad is a workload orchestrator, not a container orchestrator. Kubernetes schedules pods, and a pod is containers. Nomad schedules through pluggable task drivers: docker for containers, but also exec for a raw Linux binary, java for a JAR, qemu for a full virtual machine. So the same scheduler that runs your new Go services also runs the legacy Java app nobody wants to containerize, a Windows service, and a batch process that's just an executable, side by side, on the same fleet. That's not a thing Kubernetes does gracefully, and for a shop with a mixed or legacy estate it's the whole ballgame.
Here's the same "run three copies of a web service" job, and the difference in machinery is the point. Nomad:
job "web" {
group "app" {
count = 3
task "server" {
driver = "docker"
config { image = "myapp:1.4.0" }
resources { cpu = 500, memory = 256 }
}
}
}
Kubernetes wants a Deployment and, to make it reachable, a Service:
apiVersion: apps/v1
kind: Deployment
metadata: { name: web }
spec:
replicas: 3
selector: { matchLabels: { app: web } }
template:
metadata: { labels: { app: web } }
spec:
containers:
- name: server
image: myapp:1.4.0
resources: { requests: { cpu: 500m, memory: 256Mi } }
---
apiVersion: v1
kind: Service
metadata: { name: web }
spec:
selector: { app: web }
ports: [{ port: 80, targetPort: 8080 }]
Neither is hard. But multiply that difference across every service, every environment, and every engineer who has to hold it in their head, and "a bit less machine per thing" compounds into a materially smaller platform to run.
The assemble-it-yourself tradeoff
Nomad's small size comes from doing one job: scheduling and resource management. It deliberately does not bundle service discovery, secrets, or a service mesh. Instead it leans on the rest of the HashiCorp stack: Consul for service discovery and mesh (a Nomad task registers itself in Consul automatically when it starts), and Vault for secrets. That's a genuine tradeoff with two honest sides.
The upside: each piece is separable and you run only what you need. A small service that just needs to be scheduled doesn't drag a mesh and a policy engine along for the ride. The downside: "the platform" is now a few HashiCorp tools you wire together yourself, and if you want the equivalent of what a mature Kubernetes install gives you out of the ecosystem, you're the one assembling and operating Consul and Vault next to Nomad. For a small platform team that's often a feature, fewer moving parts, each understandable. For a team that wanted batteries included, it can feel like more decisions than they signed up for.
The ecosystem, and the elephant in the room
Here is where the comparison stops being about architecture, because this is the part that actually decides it in 2026.
Kubernetes is a CNCF project. It's vendor-neutral, every cloud sells a managed control plane, and its ecosystem is the largest in infrastructure: an operator or a Helm chart for nearly everything, a service mesh menu, and, not trivially, a hiring pool where "we run Kubernetes" is a sentence every candidate understands. When you pick Kubernetes you are buying that gravity as much as the scheduler.
Nomad's ecosystem is a fraction of that, and, more importantly, its ownership story changed. In August 2023 HashiCorp relicensed all its products, Nomad included, from the open-source MPL to the Business Source License (BSL) 1.1, which is source-available, not OSI open source. Then, in a deal that closed on February 27, 2025, IBM acquired HashiCorp for $6.4 billion. So betting your platform on Nomad today is betting on a source-available license and on IBM's roadmap for it, whereas Kubernetes remains under neutral CNCF governance that no single vendor controls.
That is not a reason to avoid Nomad. It's a reason to make the choice with open eyes: the lighter orchestrator's real cost isn't technical, it's strategic. You're trading a giant vendor-neutral ecosystem for a smaller, simpler tool whose future now runs through IBM. For some teams that's fine, plenty of critical infrastructure is vendor-owned. But it belongs in the decision, and most "Nomad is simpler" takes leave it out.
So, do you need the cluster?
Strip it down to who should pick what.
Reach for Nomad when your platform team is small and you'd rather operate one binary than a control plane; when your workloads are mixed, containers next to VMs, JARs, and raw executables that would be miserable to force into pods; when you're running on-prem or at the edge where a full managed cluster is overkill; and when operational simplicity is worth more to you than ecosystem breadth. If you can't point at a specific Kubernetes feature your system depends on, this is very likely you.
Stay on Kubernetes when you're actually buying the ecosystem, the operators, the Helm charts, the service-mesh options, the managed control planes on every cloud; when you're hiring at a scale where a universal skill set matters; when your workloads are cloud-native containers and you want the network effects of the industry standard; or when vendor-neutral governance is itself a requirement you can't compromise. "Everyone else runs it" is a weak reason on its own, but "we depend on ten things from its ecosystem" is a strong one.
The mistake in both directions is the same: choosing the orchestrator for a reason that isn't about your workload. Picking Kubernetes because it's the default, when you run twenty services and no ecosystem dependencies, buys you a distributed control plane you'll spend real time feeding. Picking Nomad to be contrarian, when you actually lean on half the CNCF landscape, trades a thriving ecosystem for a simplicity you didn't need and a license question you now own.
The honest version
"You don't need the cluster" is true far more often than the industry admits. A large share of Kubernetes adoptions are buying the reflex and the resume line, not solving a control-plane problem, and for those teams a single Nomad binary would run the same workloads with a fraction of the operational weight, and orchestrate the legacy stuff Kubernetes never wanted to touch besides.
But the reason to think hard in 2026 isn't only the ops surface. It's that the decision has quietly become a bet on governance: a neutral, vendor-owned-by-nobody Kubernetes with the biggest ecosystem in the field, against a lighter, cleaner Nomad that is now source-available and owned by IBM. Choose the scheduler your workloads and your team actually fit, weigh the ecosystem and the ownership honestly, and ignore the conference-talk gravity entirely. The right answer is a lot more often "not the cluster" than most teams are willing to say out loud.
Originally published at andriiboyko.com.
PS: English is not my native language, so I used AI to help with proofreading and phrasing. All ideas and technical content are my own.
Top comments (0)