Kubernetes is one of the most impressive pieces of infrastructure software ever built. It solves genuinely hard problems—container scheduling, self-healing deployments, horizontal scaling, service discovery—at a scale that would otherwise require an entire platform engineering team to manage manually. I have enormous respect for what it does. I also think the majority of teams running it right now should not be. Kubernetes adopted too early is one of the most expensive infrastructure mistakes a small or mid-sized engineering team can make, and the cost is paid not in licensing fees but in the thing teams can least afford to waste: time, focus, and operational sanity.
What Kubernetes actually solves
To understand why most teams do not need it yet, you have to understand what Kubernetes actually does and for whom it was designed.
Kubernetes emerged from Google's internal systems for managing containers at massive scale across thousands of machines. Its core value proposition is orchestration: deciding where containers run, restarting them when they fail, routing traffic between them, scaling them up and down based on load, and doing all of this across a fleet of nodes without human intervention per container.
That is a real problem. When you are running hundreds of services across dozens of machines with traffic patterns that spike unpredictably, manual container management is not viable. You need a scheduler. You need automated recovery. You need declarative configuration that describes desired state and a system that enforces it.
The question worth asking honestly is: does your team have that problem? Most do not. Most teams are running a handful of services on a manageable number of servers with traffic patterns that a competent engineer can reason about without a distributed scheduler. The problem Kubernetes solves is real. It is just not your problem yet.
What you actually inherit when you adopt Kubernetes early
The gap between "Kubernetes in a tutorial" and "Kubernetes running production workloads" is enormous. The operational surface area you take on is not optional complexity—it is the price of entry:
- Cluster management: Control plane health, node provisioning, version upgrades, certificate rotation. Even with a managed service like EKS, GKE, or AKS, your team owns significant operational responsibility for the cluster itself.
- Networking complexity: Kubernetes networking is its own discipline. CNI plugins, service mesh configuration, ingress controllers, network policies. Getting traffic to flow correctly and securely requires deep knowledge that takes time to build.
- YAML sprawl: Kubernetes configuration is verbose by nature. A simple web application requires Deployment, Service, Ingress, ConfigMap, and Secret manifests at minimum. As complexity grows, so does the surface area for misconfiguration.
- Debugging difficulty: When something breaks in a Kubernetes cluster, the diagnostic chain is long. Is it the pod? The node? The scheduler? The CNI? The ingress? The service mesh? Each layer adds a new place for failures to hide.
- Security hardening: Default Kubernetes configurations are not production-secure. RBAC, pod security policies, network policies, secrets management—each requires deliberate configuration and ongoing maintenance.
- Specialist knowledge dependency: Running Kubernetes well requires at least one engineer with serious platform engineering expertise. Small teams that adopt it without that expertise spend months learning concepts that are irrelevant to their actual product problems.
This is not a list of theoretical concerns. These are the things that consume engineering time in practice. I have watched two-person teams spend entire sprints debugging Kubernetes networking issues on a product with fewer than a hundred daily active users. The infrastructure was fascinating. The product was stalled.
The counterargument: standardizing early reduces pain later
The most common defense of early Kubernetes adoption is the same argument that comes up with microservices and Clean Architecture: better to build the right foundation now than to migrate under pressure later.
There is a version of this that is true. Migrating a production system to Kubernetes while traffic is growing and the team is stressed is genuinely hard. If you are going to need it eventually, there is an argument for learning it before the stakes are high.
But this argument requires a strong prior that you will actually reach the scale where Kubernetes becomes necessary. Many teams never do. They reach a perfectly serviceable steady state with manageable traffic, a small number of services, and infrastructure that a simple setup handles without complaint. They spent six months learning Kubernetes for a migration they never needed.
Even for teams that do eventually reach Kubernetes-necessary scale, the migration is more tractable than it sounds when you have containerized your applications from the start. A team running Docker containers on a simple platform can migrate to Kubernetes in weeks when the time is right, with the domain knowledge that comes from actually understanding their traffic patterns and failure modes. That knowledge makes the migration better, not worse.
What you should use instead
The good news is that the gap between "nothing" and "Kubernetes" is full of excellent options that handle the real problems most small and mid-sized teams face without the operational overhead:
Managed container platforms
AWS App Runner, Google Cloud Run, Azure Container Apps, and Railway all run containers without requiring you to manage orchestration. You push a container image, configure scaling rules, and the platform handles the rest. For the vast majority of web applications and APIs, this is all you need. The operational surface area is a fraction of a self-managed cluster.
Platform as a Service
Render, Fly.io, and Heroku's successors offer simple, opinionated deployment platforms that handle scaling, SSL, routing, and rollbacks with minimal configuration. For early and mid-stage products, the simplicity is a feature, not a compromise.
Simple VM-based deployments with Docker Compose
A well-configured server running Docker Compose with a reverse proxy is a legitimate production setup for applications with modest traffic. Kamal—the deployment tool extracted from Basecamp's workflow—makes this approach production-grade with minimal ceremony. It handles zero-downtime deploys, service coordination, and rollbacks without a scheduler in sight.
Single-server setups for early products
A properly configured single server handles more traffic than most early-stage teams realize. Vertical scaling is underrated. Before you distribute anything, maximize what a single well-tuned instance can do. The answer is often "enough for longer than you expected."
The right time to actually adopt Kubernetes
There are conditions that genuinely justify Kubernetes adoption, and I want to name them clearly rather than leave the impression that it is never the right answer:
- You have a platform engineering team or at least one dedicated engineer with serious Kubernetes expertise whose job is infrastructure—not product features.
- You are running enough services with enough traffic variability that manual scaling decisions are creating real operational incidents.
- You have specific compliance, multi-cloud, or data residency requirements that managed platforms cannot satisfy.
- You are at a company large enough that standardizing on Kubernetes creates genuine economies of scale across multiple teams.
- The alternative is building a bespoke orchestration system, at which point Kubernetes is clearly the better option.
If those conditions do not describe your team, Kubernetes is not the right answer yet. It might be eventually. It is not now.
Where I land
I am not anti-Kubernetes. I am anti-adopting-Kubernetes-before-you-have-the-problems-it-solves. The distinction matters because the cost of early adoption is not abstract—it is engineers spending weeks on infrastructure complexity instead of building the product that will determine whether the company survives.
The best infrastructure for your stage is the simplest infrastructure that meets your actual requirements. For most teams, that is not Kubernetes. It is a managed container platform, a simple deployment tool, or even a well-configured server. These are not consolation prizes. They are appropriate tools for the problems you actually have.
When your traffic, your team size, and your operational complexity genuinely require an orchestration system, you will know. The pain will be specific and real, and Kubernetes will solve it clearly. Until then, spend the time on your product. The infrastructure complexity will wait. Your runway will not.
