Why I Switched from Kubernetes to Nomad for Our Side Projects

The 3 AM Reality Check

Last Tuesday at 3:17 AM, my phone buzzed with another Slack alert. Our staging environment was down again. Not because of a code bug or a database hiccup, but because someone had updated a Kubernetes manifest and accidentally broke the ingress controller. Again. As I fumbled for my laptop in the dark, I realized we’d spent more time debugging our orchestration layer than actually building features.

This wasn’t supposed to happen. We’re a team of competent engineers who’ve been running containerized workloads for years. But somewhere between RBAC policies, custom resource definitions, and helm charts with 47 configuration options, we’d lost sight of what container orchestration should actually do: run our containers reliably without requiring a PhD in YAML archaeology.

The Nomad Revelation

Enter HashiCorp Nomad, the orchestrator that feels like it was designed by people who actually have to maintain production systems. While Kubernetes conquered the world with its exhaustive feature set, Nomad took a different approach: do container orchestration well, and leave the rest to purpose-built tools.

Installing Nomad takes about ten minutes. Download a single binary, write a config file that fits on one screen, and run `nomad agent -dev`. Compare that to spinning up a Kubernetes cluster, where you’ll spend half a day just understanding which of the seventeen different installation methods won’t leave you with a broken cluster.

The real magic happens when you write your first job specification. Here’s what deploying a web service looks like in Nomad:

Where Nomad Shines in Practice

We migrated our first service last month, a simple API that processes webhook events. The entire job spec was 30 lines of HCL. In Kubernetes, the equivalent deployment, service, and ingress manifests would have been closer to 100 lines across multiple files. More importantly, when something goes wrong, Nomad’s logs actually tell you what happened instead of cryptic error messages about admission controllers.

Resource allocation in Nomad feels refreshingly honest. You specify CPU and memory requirements, and Nomad finds a node with enough capacity. No resource quotas, limit ranges, or quality of service classes to decipher. When your job needs 512MB of RAM, it gets 512MB of RAM. When a node runs out of resources, Nomad tells you plainly instead of silently throttling your containers.

The scheduling flexibility surprised me most. Mixed workloads just work. We’re running Docker containers alongside raw binaries and even some legacy Java applications that refuse to containerize properly. Nomad doesn’t care. It treats everything as a job and finds the right place to run it. Try explaining that level of pragmatism to your Kubernetes purist colleagues.

The Integration Sweet Spot

Nomad’s philosophy of “do one thing well” extends to its ecosystem integrations. Instead of forcing you into their networking model, Nomad works with Consul for service discovery and Vault for secrets management. This trinity of tools creates a cohesive platform without vendor lock-in to a monolithic orchestrator.

Service mesh integration actually makes sense here. Rather than wrestling with Istio’s complexity, we’re using Consul Connect for service-to-service communication. The setup took an afternoon, not weeks. When services need to talk securely, they just declare their intentions in the job spec. No custom resource definitions, no operator installations, no debugging why the envoy proxy won’t start.

Secret management through Vault integration means no more base64-encoded secrets sitting in git repositories. Applications request secrets dynamically with proper rotation and auditing. It’s the kind of security setup that actually gets implemented instead of living forever in the “technical debt” backlog.

When Kubernetes Still Wins

Let’s be honest about Nomad’s limitations. If you’re building a platform for hundreds of developers across dozens of teams, Kubernetes’ extensive RBAC and namespace isolation make more sense. The ecosystem momentum alone justifies the complexity when you need operators for every database, monitoring solution, and CI/CD tool under the sun.

Nomad’s networking story, while improving, still lags behind Kubernetes’ maturity. CNI plugins and network policies in Kubernetes offer more sophisticated traffic management for complex microservice architectures. If your application architecture resembles a distributed systems research paper, you’ll appreciate Kubernetes’ networking abstractions.

The talent market reality also matters. Finding engineers comfortable with Kubernetes is easier than finding those familiar with Nomad. Training costs and knowledge transfer become factors when your team grows beyond the founding engineers who made the initial technology decisions.

The Pragmatic Choice

After six months of running production workloads on Nomad, our 3 AM alert frequency has dropped to nearly zero. Not because we’ve eliminated bugs, but because our infrastructure stopped being the source of mystery failures. When something breaks, we can trace the problem through logs that make sense and fix it without consulting the documentation every time.

Nomad won’t solve your distributed systems challenges or magically make your architecture better. What it will do is get out of your way and let you focus on building actual features instead of becoming a full-time platform team. For teams that value operational simplicity over exhaustive feature completeness, that trade-off might be exactly what you need.

Consider this: when was the last time you had a genuine technical conversation about container orchestration that didn’t devolve into Kubernetes configuration debugging? Maybe it’s time to explore what happens when your infrastructure becomes boring in the best possible way.