You know that sinking feeling when you deploy another Kubernetes manifest and realize you’ve just added 47 new dependencies, three sidecars, and a control plane that no one in your team fully understands? You’re not alone. Every DevOps engineer I talk to is quietly terrified of their own infrastructure — not because it won’t scale, but because it’s become a black box of supply chain vulnerabilities and configuration spaghetti.
The industry has sold you a lie: that complexity equals capability. It doesn’t. It equals risk.
Stefan, a developer who’s been running production infrastructure for years, recently open-sourced a framework called Autoops. It’s a Makefile. Yes, a Makefile. And it operates a distributed service mesh across 150+ nodes across multiple regions — with built-in WireGuard mesh, DNS, S3-compatible object storage, and reverse proxy. No Kubernetes. No Helm charts. No CRDs. Just a transparent, auditable, out-of-band binary setup that enforces a zero-trust supply chain.
Let that sink in. While you’re wrestling with OpenShift or EKS, someone is running a global mesh with a Makefile and a couple of PyInfra scripts. How is that possible?
The trick is that proof-of-concept tooling, when stripped of abstraction, actually scales better than an orchestrator designed for Google.
Here’s the reality: most teams don’t need Kubernetes. They need a way to deploy services, discover each other, and stay secure. Autoops gives you that without the attack surface of a container runtime, without the complexity of service meshes like Istio, and without the supply chain nightmare of pulling a thousand images from public registries.
Stefan’s approach forces you to put binaries out-of-band into an assets/ folder. No ephemeral pulls, no piped curl scripts, no hidden dependencies. If you run containers, you provide your own Dockerfiles in a structured directory. The result: a deployment that a single developer can fully understand, audit, and debug. Try doing that with a Kubernetes cluster that has been patched by six different tools.
Security through simplicity — not through layers of abstraction that even the creators can’t fully vet.
Now, the skeptics will say: “But what about autoscaling? What about rolling updates? What about declarative state?” Autoops handles horizontal scaling with Traefik-kop for service autodiscovery, uses docker-rollout for container draining, and the Makefile itself is the declarative state — it’s just text. You version it. You review it. You trust it.
The real question is: why has the industry convinced itself that a pile of YAML files and a control plane are necessary for anything more than a handful of nodes? The answer is vendor lock-in and the fear of being seen as unsophisticated. But sophistication is not complexity. Sophistication is solving the hardest problems with the simplest tools.
The next time someone tells you to “Kubernetize” your infrastructure, ask them to explain the supply chain of every image in their cluster. If they can’t, you’re not scaling — you’re accumulating risk.
Autoops isn’t for everyone. If you need multi-tenant, multi-team orchestration with fine-grained RBAC, maybe Kubernetes is your escape hatch. But if you’re running a service mesh for a product, a startup, or even a mid-sized company, consider this: a Makefile that you can read end-to-end, with binaries you verified yourself, operating across 150 nodes — that’s not a hack. That’s engineering.
FAQ
Q: Is a Makefile really scalable enough for production workloads?
A: Yes, if your scalability needs are about number of nodes, not about multi-tenant orchestration with dynamic scheduling. Autoops has been running in production for hundreds of services across 150+ nodes. The key is that the Makefile triggers PyInfra scripts that handle idempotent provisioning and service discovery — it's not 'just a Makefile', it's a Makefile orchestrating battle-tested primitives like WireGuard, Traefik, and Garage.
Q: What's the practical implication for my team?
A: You can reduce infrastructure complexity by 90% and eliminate most supply chain attack vectors. Your entire deployment stack becomes a single repo with a Makefile, a few configs, and out-of-band binaries. Onboarding a new engineer takes hours, not weeks. Audits become straightforward. You gain control and visibility — and you don't have to patch a control plane every week.
Q: Is this just anti-Kubernetes hype? What about large enterprises?
A: It's not hype — it's a legitimate alternative for teams that don't need the full Kubernetes feature set. For large enterprises with hundreds of teams, complex RBAC, and custom schedulers, Kubernetes still makes sense. But for most product companies, startups, and even mid-market, Kubernetes is overkill and a security liability. The contrarian truth is that 'enterprise-ready' often means 'enterprise-bloated', and a Makefile approach can be more robust for your actual workloads.