Hi, I'm Vim. I work on the infrastructure here at Tower. If everything is going well, you won't have seen me around 😉. I have a ton of experience in building distributed systems, and I wanted to use that experience to tell you why you don't have to use Kubernetes (unless you want to, of course!).
A Bit About Me
I haven't yet written a blog with Tower, so here is a little about who I am and my experience with Kubernetes (which makes me so bold as to tell you what to not do with it). I have been working with Kubernetes for about eight years now. My journey with Kubernetes started back in 2018 when I was building distributed systems in the crypto space. In that industry, you are often deploying across multiple clouds to ensure high distribution and avoid any single point of failure. Prior to that, being locked into a single cloud provider like AWS was a massive limitation.
Kubernetes solved that problem elegantly. It gave us a unified API across clouds and a simple, declarative controller architecture, a reconciliation loop concept that evolved from Google's internal Borg system. I am a distributed systems nerd, and I genuinely like Kubernetes. Even for my personal projects, I still deploy on it because I know the internals inside and out.
But here is the hard truth for most companies today: you probably do not need to run your own Kubernetes infrastructure.
A Business Decision, Not a Technical Dunk
Before we go further, let me clarify something. This is not a technical dunk on Kubernetes. There are plenty of people out there who will tell you to use some other tool because they think Kubernetes is poorly designed. I do not believe that. Kubernetes is exceptionally good at what it does: scaling and reliably maintaining cloud workloads.
It is true that at extreme scales, even the best systems face limits. For example,
Modal recently published a breakdown of their internal architecture, walking through why traditional
container platforms hit hard limits at that size: Kubernetes schedules serially and in the worst case does O(n x p) work for n nodes and p pods, every pod means multiple writes to
etcd, and node heartbeats alone put write load on etcd proportional to the size of the fleet. To run millions of concurrent sandboxes, they run their own horizontally scaled scheduling
layer instead.
But for 99% of businesses, the issue is not that Kubernetes cannot handle the technical load. The issue is that taking it on is a bad business choice.
The Hidden Costs of Complexity
Running internal Kubernetes comes with a massive overhead that most companies underestimate. When you choose to host your own infrastructure, you are taking on a heavy burden:
- Hiring constraints: Platform engineers who truly understand the internals are incredibly hard to find. We struggle with this ourselves, and I know other major enterprises do too.
- Maintenance overhead: You are responsible for keeping the cluster updated, secure, and patched.
- Configuration risks: Even highly experienced teams encounter unforeseen challenges. When dealing with complex network configurations, especially those required for rigorous compliance standards like SOC 2, the margin for error is razor-thin. When you manage your own cloud infrastructure, subtle misconfigurations or routing issues can happen all too easily to anyone.
Unless you already have a dedicated, experienced Kubernetes team, the return on investment simply is not there.
Offload the Infrastructure, Keep the Control
This brings us to the core reason why I advocate for a different approach. At Tower, we are building a data lakehouse orchestration engine. Our goal is to let you deploy reliable pipelines and apps without needing to spin up your own clusters.
Look at enterprise companies. They run Kubernetes internally for their core database infrastructure because it makes sense for that specific, highly specialized use case. But when it comes to running automated apps and orchestrating workflows, they likely don't want to take on additional, unnecessary complexity. Instead, they can use a platform like Tower to handle the compute. You can just hit our API or use our CLI, give it a state, and let us maintain it.
You get the elegant, declarative architecture of a modern distributed system, but without the headache of managing the underlying nodes, network policies, or schedulers.
If you have spent eight years learning the internals of Kubernetes like I have, by all means, use it. But if your goal is to build and scale your business quickly, skip the infrastructure burden and let us run the compute for you.