This article is based on a piece originally published on forbes.com (2019). The core architectural arguments remain relevant as both serverless and Kubernetes ecosystems continue to mature.
A Pattern of Disruption—or Evolution?
A few years ago, OpenStack was widely regarded as the inevitable future of private cloud infrastructure. Then Docker redrew the map, and Kubernetes followed, becoming the de facto container orchestration standard. Now, serverless computing—also called Functions as a Service (FaaS)—is the technology capturing engineering teams’ imaginations.
This raises two pointed questions: Did Kubernetes render the OpenStack engineer obsolete? And is serverless about to do the same to Kubernetes engineers?
The short answer: no, and understanding why matters for anyone making architectural decisions today.
Cloud Infrastructure Is Not a Zero-Sum Game
Each wave of cloud infrastructure innovation—bare metal, VMs, OpenStack, containers, Kubernetes, serverless—tends to be framed as a replacement for what came before. In practice, the relationship is almost always additive rather than destructive.
- OpenStack deployments still exist and run production workloads at scale for many organizations.
- Kubernetes can run inside OpenStack environments, and frequently does.
- Serverless functions can run on top of Kubernetes clusters—most visibly through projects like Knative.
Knative, an open-source project backed by Google and others, lets teams deploy serverless workloads onto existing Kubernetes infrastructure. This means organizations can adopt the simplicity of a serverless programming model without abandoning the operational control and flexibility that Kubernetes provides. Even when serverless is delivered as a managed cloud service (AWS Lambda, Google Cloud Functions, Azure Functions), Kubernetes is increasingly the underlying runtime those platforms use internally.
What Serverless Does Well—and Where It Falls Short
Serverless is a genuinely powerful model for specific problem types. It is not a universal solution.
Serverless excels at:
- Event-driven, short-lived workloads — image processing on upload, webhook handlers, scheduled jobs
- Highly variable traffic patterns — workloads that need to scale from zero to peak and back automatically
- Reducing operational overhead — no servers, nodes, or cluster upgrades to manage for the function itself
- Cost efficiency at low utilization — pay-per-invocation models eliminate idle compute costs
Serverless struggles with:
- Long-running or stateful workloads — most FaaS platforms impose strict execution time limits
- Latency-sensitive applications — cold start delays can be problematic depending on the runtime and provider
- Complex inter-service communication — orchestrating many functions introduces its own coordination overhead
- Vendor lock-in risk — proprietary FaaS APIs and trigger integrations can be difficult to abstract away
Kubernetes as a Foundation, Not a Competitor
Serverless didn’t eliminate operating systems any more than containers did—it built on top of them. The same logic applies to Kubernetes. Rather than competing with serverless, Kubernetes is increasingly becoming the platform on which serverless runs.
Projects that illustrate this convergence include:
- Knative — serverless workload management built on Kubernetes primitives
- OpenFaaS — an open-source FaaS framework deployable on any Kubernetes cluster
- Kubeless — a Kubernetes-native FaaS framework (now deprecated, but historically notable)
- KEDA (Kubernetes Event-Driven Autoscaling) — extends Kubernetes autoscaling to event-driven workloads, bridging the gap between traditional deployments and serverless patterns
This ecosystem demonstrates that the industry is not choosing between Kubernetes and serverless—it is building serverless using Kubernetes.
Practical Advice: When to Reach for Serverless
Very few teams should go all-in on a fully serverless architecture for an entire application stack. Similarly, dismissing serverless entirely as hype means missing genuine productivity gains for the right workloads. A more useful mental model:
- Evaluate each component or service independently on its runtime characteristics, traffic profile, and state requirements.
- Use serverless for the edges of your system—event handlers, data transformation pipelines, scheduled tasks—where its strengths align.
- Keep long-running, stateful, or latency-critical services on container-based or traditional infrastructure.
- If you’re already on Kubernetes, explore Knative or KEDA before adopting a proprietary FaaS service, to reduce lock-in.
The Bigger Picture: Iterative, Not Revolutionary Change
The pace of cloud infrastructure innovation over the past decade has been remarkable. Best practices from 2015 often look naive today. But the underlying pattern is iterative—each new layer builds on the abstractions provided by the layer below it. Serverless abstracts away node management; Kubernetes abstracts away host management; containers abstracted away OS-level dependencies.
This is why Kubernetes continues to matter even as serverless matures. It is forming the substrate on which the next generation of cloud-native tooling is being built. Teams that invest in Kubernetes expertise are not making a bet that will be invalidated by serverless—they are building knowledge that transfers directly into the serverless-on-Kubernetes paradigm.
Serverless is a key part of the future of cloud infrastructure. So is Kubernetes. The question is not which one wins—it is learning how to use both appropriately.
Originally adapted from a Forbes article (2019). Technical context has been expanded and updated for accuracy.