Using Kubernetes is a love-hate relationship.
Love, because before it, deploying to production was something dark and uncertain. Many tools tried to solve this problem — Mesos, Fleet, Nomad — but only Kubernetes meaningfully solved container orchestration at scale. It's not without merit that today over 96% of organizations using containers run Kubernetes, according to the 2023 CNCF report.
But as nothing is perfect, a piece of software built by Google engineers fell short on design — not UI design, but how things actually work. Engineers think like engineers: it works, but Kubernetes complexity is something you'll likely need a dedicated course to truly understand. On one side it created entire careers — the CKA certification became a market commodity — on the other, small companies that can't afford a certified DevOps engineer find themselves at a crossroads: they feel the need for Kubernetes but can't manage it.
The concrete problem: a minimal Kubernetes cluster requires understanding at least 15 different abstractions — Pods, Deployments, Services, Ingress, ConfigMaps, Secrets, RBAC, PVCs, StorageClasses, NetworkPolicies, and so on. And incredibly, with each release that number grows. Kubernetes 1.29 introduced over 60 API changes. In 2024, more than 10 APIs that projects depended on were deprecated.
Several projects tried to reduce this complexity. Rancher added a solid UI layer on top of Kubernetes. Dokploy, which doesn't use Kubernetes but Docker Swarm instead, achieved something remarkable: the first time I used it, I had a project running in production in minutes, no course needed, no major concerns. Their UX is genuinely good.
But I have one problem with Dokploy: it uses Docker Swarm. And while Swarm is still technically maintained by Docker Inc., development has slowed dramatically in favor of Kubernetes-based solutions, the ecosystem stopped investing in it, and adoption has shrunk. It's a functionally stagnant project — which for critical infrastructure is a real risk.
HashiCorp's Nomad tried a different path — simpler than Kubernetes, single binary, without all the ceremony. But in my opinion it made the mistake of being too tightly coupled to the HashiCorp ecosystem: Consul for service discovery, Vault for secrets, Terraform for infrastructure. It works great if you adopt everything. If you don't, it's limiting. And now, after HashiCorp was acquired by IBM in 2024 and changed its license from MPL to BSL, that dependency became even riskier for anyone building on top of it.
Something about me you should know: I love studying anything related to IT. Beyond being my profession, it's a hobby. And I like giving meaning to what I study.
With that said, I recently started a personal project. I have three VPS instances, started analyzing what I'd need, and realized I didn't need the full complexity of the Kubernetes stack. I went with Dokploy — it works fine for an MVP. But the question remained: what happens when it grows?
So one day, in the shower, reflecting on all of this, I thought: I can use Dokploy while it's an MVP, I can take a Kubernetes course and hope the AI configures everything correctly, or I can build a real alternative. I went with the obvious choice: build the alternative.
You might think I'm crazy. But Kubernetes itself was born from Google engineers who thought they could do better than Borg. Docker was born from someone who thought LXC could be simpler. Real projects emerge when people decide to think differently about known problems.
My goal isn't fame or money. The project will be 100% open source, Apache 2 license, no paid tiers. What I want is to solve a real problem: unnecessary complexity in container orchestration. I'm not promising I'll succeed — but it's worth trying.
I've been working on this for a few weeks now. The repository is still private, but soon, once I have a more stable version, I'll make it public. In the next posts I'll detail the architecture decisions and the reasoning behind them — including why I built my own orchestrator instead of layering on top of Kubernetes.
If you also feel that Kubernetes complexity is out of proportion with the problem it solves, follow along. I'll probably make a lot of mistakes — but I'll document everything.
Top comments (25)
building an alternative sounds exciting but I'd push back - Kubernetes complexity is mostly ecosystem lock-in, which your alternative won't fix. teams complaining about k8s usually struggle with helm charts, not the scheduler itself.
Fair point — but I'd argue Helm exists precisely because Kubernetes doesn't package things natively. That's not ecosystem lock-in, that's a gap the ecosystem had to fill.
And it keeps going: CNI, Ingress controller, cert-manager, secrets management. None of it is the scheduler. All of it is complexity you have to own.
the scheduler-vs-everything-else divide is the real tell — lock-in you can architect around, but filling 4 structural gaps with 4 independent tools is a complexity floor that any alternative has to confront too
I agree, I wrote a second article where I detailed what I thought of as architecture, I would be happy to have your opinion.
dev.to/denerfernandes/i-decided-to...
will check it out, specifically curious how you handled the scheduler boundary. that's usually where multi-tool architectures get messy.
Love this kind of project. Kubernetes solved a huge problem, but it also normalized a level of complexity that’s overkill for a lot of real-world teams. I think there’s a massive gap between “docker-compose on a VPS” and “learn 15 abstractions + YAML archaeology.”
What I especially like here is that you’re not just saying “K8s bad,” you’re clearly thinking about the tradeoffs: Swarm stagnation, Nomad ecosystem lock-in, operational simplicity vs flexibility, etc. That’s the interesting part.
Even if the final result ends up being opinionated rather than universal, that’s still valuable. Some of the best infra tools started exactly like this: someone got tired of unnecessary complexity and built the thing they wished existed.
Looking forward to the architecture posts.
Thank you for your kind words, I will definitely share them in future posts.
This is the kind of “crazy” project that is worth doing even if it does not replace Kubernetes.
Kubernetes became the default because it solves a huge class of problems, but a lot of teams are absolutely paying for flexibility they do not need. If your workload model is simpler, the operational surface can probably be simpler too.
The hard part is deciding what not to support.
Most Kubernetes alternatives start clean, then slowly re-invent scheduling, networking, service discovery, secrets, rollbacks, health checks, autoscaling, logs, multi-tenancy, and policy until they accidentally become a smaller Kubernetes with fewer contributors.
If the project keeps a narrow opinionated scope, it could be useful. If it tries to be a general platform, the complexity comes back.
I like the idea. Would love to see what you end up with. But still, k8s has it's spot and sometimes when you think you need it your actually better of without, but more often I find cases where no one even thought k8s is a option, because there is nothing to scale andots of state to deal with yet weirdly enough it still was the best solution.
Sure, Kubernetes is amazing. I think the best thing about Kubernetes is the ecosystem that surrounds it, which has matured over the years.
Anything that wants to replace k8s for AI workloads will hit the same wall we did. GPU scheduling, OTel, and multi-tenant cost isolation are the three load-bearing problems. Curious how the project handles graceful node drain when model weights are paged into GPU memory. We saw cold-start penalties of 90 seconds on Llama-3.3-70B and ended up writing custom pre-drain hooks. Worth sharing how cost attribution works at the namespace level too.
Great points but Houdini isn't targeting AI workloads, at least not in v1. The goal is the opposite end of the spectrum — the developer who just wants to deploy a web app without a 40-hour Kubernetes course.
GPU scheduling, OTel, and multi-tenant cost isolation are genuinely hard problems, but they belong to a space where K8s (with the right operators) probably stays king for good reasons. I'd rather do one thing well first.
That said, the architecture is being designed to stay extensible — so nothing closes that door for the future. Appreciate the insight.
Wonderful
thanks!
I've been seeing a lot of kubernetes server and cluster stuff in my reels and shorts. This gives me a lot of insight to some of the questions I had. Thanks for taking the time to break it down <3
Thanks!
Prefect! Best way to learn the fundamentals of technologies
Sure! thanks
I think for more small projects you can use things like k3s, but I am curious what you are building, cant wat for the rest of the posts and your journey.
Totally agree on k3s — it's a solid choice and way easier than full K8s for small setups.
Thanks for following along — the next posts will get more concrete. 🙏
Looking forward to it!
⏳
Some comments may only be visible to logged-in visitors. Sign in to view all comments.