Every “simpler” DevOps tool is just Kubernetes wearing sunglasses.
The dream of simplicity
I remember the day I promised myself I’d never touch Kubernetes again.
I’d seen things pods looping, nodes ghosting, Helm charts crying in YAML.
So this time, I swore:
“Just one container. That’s it.”
That’s how it always starts, right?
You tell yourself you’ll spin up a single Docker image, serve one tiny app, and call it a night but then it happen one turns into two then you need a load balancer then health checks then well you’re halfway through rebuilding Kubernetes before you even realize it.
I call this the DevOps Loop of Denial.
Every engineer goes through it:
- First, you reject Kubernetes.
- Then you reinvent it.
- Finally, you accept it. Like grief, but with YAML.
The funny part? It’s not even Kubernetes’ fault.
It’s us.
We can’t resist the urge to over-engineer, automate, and “just make it scale.”
We crave simplicity, yet we worship complexity like it’s an achievement badge.
TL;DR
I tried to simplify my deployments in 2025.
I ended up building Kubernetes all over again.
This is the story of that realization and the peace that finally came after accepting it.
The calm before the cluster
The first time I ran docker run nginx, I felt unstoppable.
The container spun up like magic. No config drama, no servers screaming, just… working code.
It was beautiful.Like discovering fire, but without AWS billing me for oxygen.
Then I needed a second container.
“It’s just one more,” I told myself, smiling like a rookie in a disaster movie’s first ten minutes.
So I made a docker-compose.yml.
Then another.
Then one for production.
Soon, I was staring at more YAML than code.
Each line felt like a riddle whispered by an eldritch being named “IndentationError.”
Sample Reality Check
services:
web:
image: nginx
ports:
- "80:80"
db:
image: postgres
environment:
POSTGRES_PASSWORD: secret
That was supposed to be it.
Two containers, one simple config but then came environment variables, persistent volumes, and health checks the “just one more thing” of DevOps.
Suddenly, I was mapping ports like a cartographer in the 1600s.
Every change demanded a rebuild every crash made me question my life choices.
At first, I thought I was just being dramatic.
But every developer I talked to had the same haunted look.
They’d whisper about volume mounts and circular dependencies like war veterans swapping battle stories.
That’s when I realized something:
Simplicity is never simple once you care about uptime.
Docker had given me a taste of power, and like any good dev, I immediately abused it.
The next logical step? Finding something simpler.
(That’s what I thought, anyway…)
The descent chasing simpler tools
After the third night of debugging Docker Compose restarts, I did what every dev does when they’re lost.I googled “simpler alternative to Kubernetes.”
That’s like searching “low-calorie pizza that still tastes amazing.” You’ll find options, sure but they all end with disappointment and YAML.
At first, I fell for Fly.io.
Their landing page whispered sweet promises:
“Deploy globally with one command.”
Beautiful. Minimal. Magical.
So I pushed my app.
Then the logs started chanting arcane words like “health check failed” and “image unavailable in region FRA.”
It was déjà vu, but with prettier UI.
Then came Nomad HashiCorp’s minimalist orchestration alternative.
CLI felt clean. The docs felt friendly.
Five minutes in, I was already defining job files that looked suspiciously like Yaml again
I told myself this one would be different.I told myself I didn’t need Kubernetes next thing I know, I’m configuring load balancers, replicas, and environment secrets in a “lightweight orchestrator.”
Here’s the thing they don’t tell you:
Every “simple” deployment tool secretly dreams of being Kubernetes when it grows up.
They start with one binary and end with a control plane, CRDs, and a Slack community arguing about ingress controllers.
It’s not their fault.
Simplicity doesn’t scale and scaling breaks simplicity.
That’s the trade-off.
You can hide Kubernetes, but you can’t kill it.
Reality Check
Kubernetes isn’t complex because engineers love pain.
It’s complex because production environments are.
And so, in my noble quest for minimalism, I had come full circle.
each tool promised salvation each one delivered YAML.
The Loop realizing I built Kubernetes again
It hit me one evening as I stared at my terminal.
I had three services running, a network overlay, some secret management, autoscaling, and health checks.
That’s when I realized…
I’d built Kubernetes again.
Except worse.
Mine was duct-taped together with bash scripts, docker ps commands, and a prayer.
At first, I laughed then I cried a little.
Because deep down, I knew it wasn’t the tools it was me.
I’d been chasing “simplicity” like a dev chases a perfect light theme: it doesn’t exist, but hope is eternal.
I opened my configs to review what I had “simplified.”
A small sample of the crime scene:
services:
app:
image: myapp:v4
replicas: 3
env:
NODE_ENV: production
healthcheck:
path: /health
Tell me that doesn’t look like a Deployment YAML wearing fake glasses.
It was Kubernetes. Just pretending to be indie.
I remember staring at my architecture diagram and whispering to myself:
“You either die a Docker user, or live long enough to see yourself maintaining etcd.”
Every tool, every abstraction they were all just different dialects of the same language.
Scheduling. Networking. Scaling.
The moment you need all three, you’ve accidentally summoned Kubernetes.
The illusion of simplicity had shattered.
There was no running from it not Fly.io, not Nomad, not Render.
They all stood on the same shoulders of YAML-shaped giants.
And in that moment of chaos, something surprising happened:
I stopped being mad at Kubernetes.
Because for the first time, I understood why it existed.
Acceptance the zen of Kubernetes
There’s a point in every developer’s journey where rage gives way to peace.
You stop shouting at YAML files.
You stop pretending your docker-compose setup is different.
You close your eyes, take a deep breath, and whisper:
“Maybe Kubernetes isn’t the enemy.”
At first, I thought enlightenment meant deleting Kubernetes.
Now I know enlightenment means understanding it.
It’s not that the system is too complex it’s that the world it serves is.
Distributed workloads, rolling updates, self-healing clusters… none of this is simple.
So why did I expect the tool to be?
That realization hit like a zen gong.
I stopped fighting it.I learned to use helpers not hide from them.
Lens to visualize clusters.K9s to tame logs.Portainer to manage the chaos without losing my mind.
I started seeing the elegance in the design.
The logic in the madness.
Every controller, every pod, every restart a silent symphony keeping apps alive while I sleep.
Sure, it still breaks.
Sure, I still curse when a service doesn’t route.
But now I do it with love.
When I finally reached peace, I realized:
It was never about escaping Kubernetes.
It was about accepting that every abstraction eventually becomes it.
In the end, we don’t outgrow the cluster.
We just learn to breathe inside it.
Conclusion the infinite DevOps cycle
It’s funny after all the tools, the tears, the YAML… I ended up right where I started staring at a cluster.
But now, it doesn’t scare me anymore.
I see it for what it is: not a monster, just a mirror.
Every platform we build, every framework we invent it’s all just us, trying to make order out of chaos.
And Kubernetes? It’s the chaos tamer we secretly all rely on.
I used to think the “next big thing” would replace it.
Now I realize: even the tools trying to kill Kubernetes… run on Kubernetes.
The irony is cosmic.
Fly.io? On clusters.
Render? Under the hood, same game.
Even AI-powered deployment tools guess what’s orchestrating their inference servers? Yep. Kubernetes.
So no, we’re not escaping the cluster.
We’re just theming it differently.
Giving it friendlier names, prettier dashboards, and darker themes.
But it’s still there, humming beneath the surface like the heartbeat of modern infrastructure and that’s okay.
Because maybe, after all this time, Kubernetes isn’t something we need to defeat it’s something we finally learned to live with.
“In DevOps, as in life you don’t escape complexity.
You just learn to containerize it.”
Helpful Resources
If you want to explore the tools and ideas from this story or spiral into your own Kubernetes enlightenment here’s where to start:
One thing you still need to realize is that you can have a totally deterministic setup using Nix, that extends to cloud infrastructure, elimimating drift and all by only allowing changes in you config