The "everything on Kubernetes" era is ending
A few years ago, if you were running containers in production, Kubernetes was the default choice. Looking at 2026, that assumption is shifting. According to several industry reports, Kubernetes adoption in production workloads has plateaued at roughly 68%, slightly down from its 2024 peak, as teams increasingly split workloads between traditional clusters and serverless container platforms (The New Stack).
By serverless containers, we mean services like AWS Fargate, Google Cloud Run, and Azure Container Apps — ways to run containers without managing a cluster. Lighter-weight options such as Nomad and AWS ECS have reportedly grown to a combined 22% as well.
Rather than framing this as an either/or between Kubernetes and serverless containers, this post lays out how to decide between them from a practical standpoint.
Why the plateau?
Kubernetes adoption flattening does not mean Kubernetes got worse. If anything, the opposite: many teams have started to realize that Kubernetes was overkill for their scale.
Kubernetes is powerful, but that power comes with operational cost. Cluster upgrades, node management, network policy design, permission configuration — keeping all of that running safely requires something close to a dedicated team. For small-to-mid-sized teams, that operational load is not negligible.
AWS recognizes this too. At KubeCon, they showcased efforts to "make Kubernetes complexity invisible" with tools like Karpenter, Kro, and Cedar (The New Stack). In other words, two trends are advancing at once: making Kubernetes itself easier to use, and expanding the options that avoid touching Kubernetes directly.
A framework for deciding
When we help clients design infrastructure, we organize the options around these considerations.
When serverless containers fit
- Your team's ops resources are limited. If you cannot dedicate people to running clusters, a managed service is the rational choice.
- Traffic varies widely. It scales automatically with requests and keeps costs down while idle.
- The workload is relatively simple. Plain web APIs or batch jobs that do not need complex orchestration.
# An illustrative Fargate task definition (conceptual excerpt)
# No node management; you declare only the CPU/memory you need
family: web-api
cpu: "512"
memory: "1024"
containerDefinitions:
- name: api
image: myapp/api:latest
portMappings:
- containerPort: 8080When Kubernetes fits
- You coordinate many services. Dozens of microservices with complex communication control.
- You need fine-grained control. Scheduling, networking, and storage that you want to tune precisely.
- You span multiple clouds or on-prem. Its value as a portable common platform pays off.
- You already have the operational know-how. Your team has accumulated Kubernetes expertise.
Hybrid is the pragmatic answer
The key point is that this is not a one-or-the-other decision. In practice, many teams use both. Running steady core services on Kubernetes while offloading variable peripheral workloads and batch jobs to serverless containers is a realistic setup.
When we support a design, we recommend moving away from the "build everything on Kubernetes first" mindset. Looking at each workload's characteristics and placing it based on the balance between operational load and the need for control is better for both long-term cost and stability.
Things to watch when migrating
If you already run on Kubernetes, you may consider a partial move to serverless containers. A few things to keep in mind.
First, the degree of lock-in. Cloud Run and Fargate each have cloud-specific parts, and portability is lower than Kubernetes. If multi-cloud matters to you, this is not something to ignore.
Second, the difference in cost structure. Serverless containers make it easy to keep idle costs down, but for consistently high-load workloads, reserving dedicated resources can be cheaper. Estimating against your real traffic patterns is essential.
Third, observability design. Once you span platforms, you need a unified approach to aggregating logs and metrics, or incident investigation gets hard. Decide your monitoring strategy before migrating.
Wrapping up
Kubernetes adoption plateauing is not because Kubernetes became unnecessary — it is because the "everything on Kubernetes" mindset is being reconsidered. Serverless containers have matured, and matching the tool to the workload's characteristics is becoming standard practice.
The decision axis is simple. If your ops resources are limited and the workload is simple, reach for serverless containers; if you need to coordinate many services or exercise fine-grained control, reach for Kubernetes. And in many cases, the answer is to combine both well. Being honest about your scale and staffing is the shortest path to infrastructure that lasts.
webhani consults on cloud infrastructure design and migration. If you want to talk through choosing between Kubernetes and serverless, reach out anytime.