Some time ago, while designing an infrastructure architecture and evaluating Kubernetes (K8s) for our stack, I stumbled upon a highly publicized article in the tech community: “I Didn’t Need Kubernetes” The internet is flooded with similar posts advising developers that K8s is too heavy, complex, and bloated, and that they should migrate to lightweight serverless or managed container platforms instead. In fact, a member of my own team — who was hesitant about adopting K8s — used that exact article as ammunition to oppose our transition. However, the architectural reality and business requirements of that blog post were fundamentally different from ours.

Let’s be honest: if your goal is simply hosting a lightweight web service on a single cloud, serverless or PaaS options like Google Cloud Run or AWS ECS are cheaper, faster, and simpler. That is not a groundbreaking insight; it is common sense. Packaging this obvious trade-off as a grand architectural revelation to dismiss Kubernetes altogether is a narrow-minded view that misses the forest for the trees.

The true value of Kubernetes is not just as a “container runner.” It is a tool for environment standardization, infrastructure portability, and a robust blueprint for hybrid and on-premises environments. In this article, I want to unpack the real purpose of Kubernetes, the limitations of its lightweight alternatives, and the practical enterprise scenarios where K8s is not just “overengineering,” but the most rational choice.

There Is No Silver Bullet, but Why Does Kubernetes Still Reign?

Today, Kubernetes has become the de facto standard for container orchestration. With its declarative configuration, self-healing capabilities, automated scaling, and massive open-source ecosystem, it offers a set of specs that would make any infrastructure engineer’s heart beat faster.

Yet, like any technology, K8s is not a silver bullet. Behind its immense power lies a notoriously steep learning curve, complex configuration management, and significant maintenance overhead.

This has triggered a recent trend in tech circles: developers proudly proclaiming, “We don’t need K8s,” and returning to managed container platforms like GCP Cloud Run or AWS App Runner. But is Kubernetes truly just an overengineered monument built for developer vanity? Or are we drawing the wrong boundaries for its adoption?

The Blind Spots of Kubernetes Skeptics

Kubernetes Is Not a Cure-All (The Overengineering Trap)

Let’s make one thing clear: Kubernetes is absolutely not a fit for every project.

If your service is small, your traffic is stable, and you lack a dedicated platform or DevOps team, adopting K8s is a recipe for disaster. The overhead of managing control plane costs, complex networking (CNI), storage orchestration (CSI), and strict security policies will quickly dwarf any benefits. In this context, forcing K8s onto your stack is indeed the textbook definition of overengineering.

The Shallow Logic of “Leaving K8s” Articles

The thesis of articles like “I Didn’t Need Kubernetes” is almost always the same:

“Managing K8s gave us sleepless nights. Once we migrated to Google Cloud Run (GCR), our infrastructure bills went down, and deployments became trivial. You shouldn’t use K8s either.”

For that specific author and their business context, this was undoubtedly a smart decision. But generalizing this personal success story into a universal “K8s is useless” narrative is a massive logical leap. When my own teammate pointed to this post to argue, “Look, even top-tier engineers are leaving K8s, so why are we bothering?” it became clear how easily these narratives can mislead a team.

If you read these articles and conclude that K8s is just a waste of money and engineering hours, you are missing the core architectural essence of the platform.

The Real Value of K8s: An “Infrastructure Blueprint,” Not Just a Platform

A system built on Kubernetes is not merely a collection of running containers. It is a highly portable, self-contained “infrastructure solution package.”

Cloud-native container services (Google Cloud Run, AWS ECS, etc.) are deeply coupled with their respective vendor ecosystems — proprietary IAM, VPCs, and specialized load balancers. If you design an architecture tailored perfectly to AWS ECS, migrating that setup to an on-premises data center or another cloud provider is incredibly difficult. It often requires completely re-engineering your infrastructure.

In contrast, as long as K8s is running on the target environment — whether it is a public cloud, a hybrid setup, or bare-metal servers — you can take your existing manifests (YAMLs, Helm Charts) and replicate your entire infrastructure in minutes. This extreme portability and consistency is the true superpower of Kubernetes.

Real-World Case: Bridging Public Cloud SaaS and On-Premises Private Networks

Let’s look at how this value plays out in a real B2B enterprise scenario.

Imagine a B2B SaaS company that hosts its services on a public cloud. They sign a contract with a high-security client — such as a bank, a large enterprise, or a government agency — who drops a heavy constraint on them:

“Due to strict regulatory compliance and data leakage concerns, we cannot use your public cloud SaaS. You must deploy and run your system entirely inside our private, air-gapped on-premises network.”

Without K8s, this is an operational nightmare. The engineering team has to maintain two separate deployment pipelines: one for the public cloud and one for the client’s custom bare-metal servers. Applying patches and maintaining parity between these environments becomes an endless cycle of manual configuration.

However, K8s elegantly solves this problem. By running K8s on both the public cloud and the client’s private infrastructure, the deployment target is unified. When the dev team patches a bug in their public cloud SaaS, they build the container image, package it into a Helm chart, and deploy it to the client’s private network with a single helm upgrade command. The application and networking environments remain identical because K8s abstracts the underlying physical hardware.

The “Docker Compose is Enough” Misconception

Skeptics often counter: “Why bother with K8s? Docker Compose can handle multi-container deployments just fine.” This argument completely overlooks the realities of scaling and infrastructure heterogeneity.

As your B2B business grows, you won’t be dealing with just one client. You will deal with dozens, each with vastly different hardware constraints. One enterprise client might have state-of-the-art datacenters, while a smaller partner might ask you to run your software on a few spare machines in an office closet.

K8s is designed to handle this chaos. It dynamically manages container scheduling, scaling, self-healing, and node failures out of the box.

If you rely on Docker Compose in this scenario, you are signing up to manually SSH into remote servers every time a container crashes or a machine reboots to run docker compose up -d. You cannot ask an enterprise client’s operations team to manually run shell scripts to keep your service alive.

I experienced this firsthand during a project where public-sector clients were legally barred from using our public cloud SaaS. By packaging our solution into an on-premises K8s cluster, we bypassed strict compliance bottlenecks, delivered high availability, and made updates trivial. Without K8s, the sheer maintenance overhead of supporting these fragmented environments would have paralyzed our development team.

Too Heavy for K8s? Enter Docker Swarm!

If you appreciate the architectural benefits of container orchestration but still dread the operational overhead of Kubernetes, Docker Swarm is an incredibly pragmatic middle ground.

If your team is already comfortable with Docker in development but lacks the bandwidth to learn K8s’ complex ecosystem, Docker Swarm gets you up and running instantly. Run docker swarm init followed by docker service create, and you have a multi-node cluster. You don’t have to worry about configuring complex Ingress Controllers or CNI plugins—basic port binding handles internal load balancing automatically.

However, keep in mind the broader trajectory of the container ecosystem. The industry has shifted towards unified standards, specifically the Container Runtime Interface (CRI). The CNCF and Kubernetes famously deprecated and removed Docker-specific integration layers (Dockershim) in favor of lightweight, standard runtimes like containerd. While Docker Swarm remains a solid, operational tool for many use cases, evaluating long-term ecosystem support, security standards, and platform modernizations before cementing it into your stack is a highly worthwhile exercise.

Related Read: If you’re curious about container security, here is a deep dive on why running standard Docker in production poses critical security risks

Conclusion: The Weight of the Business Dictates the Weight of the Tool

Admitting “our team doesn’t need Kubernetes” is not a sign of weakness; for many projects, it is a smart, cost-effective decision. Leveraging serverless or managed PaaS alternatives is often the best way to focus engineering hours on writing actual business logic.

But we must stop labeling K8s as “useless” or “overengineered” simply because we haven’t encountered the problems it was built to solve.

• If you need to stay entirely independent of public cloud vendor lock-in,
• If you must support both public cloud SaaS and air-gapped on-premises deployments simultaneously,
• If you need to deploy a highly complex application stack consistently across heterogeneous physical environments,

Then Kubernetes is no longer an overengineered luxury. It becomes a highly rational, robust, and cost-effective blueprint.

As engineers, we must guard against two distinct pitfalls: blindly chasing hype cycles, and dismissively labeling powerful architectures as “overengineering” because of our own limited scope. The weight of your tools should always be determined by the weight of your business challenges. When you look past the buzzwords and understand the underlying architectural purpose of K8s, you can finally build systems that solve real-world problems.