This article is based on reporting originally published at datacenterknowledge.com (January 2020).
The Serverless Lock-In Problem
Serverless computing has delivered genuine productivity gains for development teams, but it has come at a cost: every major cloud provider’s serverless offering is essentially a walled garden. AWS Lambda, Azure Functions, and Google Cloud Functions each use proprietary APIs and event models. Moving workloads between providers—or running them consistently across hybrid and multi-cloud environments—is difficult, often requiring teams to maintain separate deployment pipelines for each platform.
Knative is the open-source project designed to break that pattern. Originally initiated by Google and developed with contributions from IBM, Pivotal, Red Hat, and others, Knative layers a serverless runtime on top of Kubernetes, making it possible to deploy event-driven functions on any infrastructure that runs Kubernetes—whether that’s a private data center, a public cloud, or a combination of both.
What Serverless Actually Means
The term “serverless” is frequently misunderstood. Functions-as-a-service (FaaS) workloads absolutely run on servers; the key distinction is that developers don’t manage those servers. Instead, functions are packaged in containers, started on demand when an event triggers them, scaled automatically to meet load, and shut down when the task is complete. Users pay only for the compute time consumed while the function is active.
AWS popularised this model with the launch of Lambda in 2014. Microsoft Azure followed with its own Functions service. The appeal is straightforward: tasks that don’t need to run continuously—sending a notification when a database record changes, processing an uploaded file, responding to a webhook—are a natural fit for short-lived, event-triggered execution.
Serverless is sometimes conflated with microservices, but they are distinct. Microservices decompose an application into loosely coupled services that are typically always running. Serverless functions, by contrast, are dormant until triggered. As Brian Gracely, then senior director of product strategy for Red Hat OpenShift, explained to Data Center Knowledge:
“Those types of tasks don’t need to run all the time, they just need to run when an event happens. Maybe a database table got updated for an order, so I’m going to kick off a small job to send a text message to the customer with this updated status. There are lots of things like that which go on in IT with applications all the time, so this became something that a subset of developers found really appealing.”
How Knative Works
Because serverless workloads run in containers, Knative integrates directly with Kubernetes. It also relies on a service mesh—most commonly Istio or Linkerd—to handle request routing and traffic management. In Kubernetes terms, Knative introduces a new deployment type tailored to event-driven, short-running, auto-scaling workloads, sitting alongside existing primitives like Deployment (for long-running applications) and StatefulSet (for stateful services that need stable network identities).
Richard Seroter, then VMware’s senior director of technical marketing and developer relations, described Knative’s scope to Data Center Knowledge:
“It’s not just a function platform, it is a kind of a Kubernetes native app runtime. Vendors might use it to put a ‘dev experience’ on top of Kubernetes that developers who don’t want to know all the plumbing of Kubernetes can use.”
This is an important point for platform teams: Knative is not only about serverless. It can serve as a higher-level abstraction that makes Kubernetes more accessible to application developers who don’t need—or want—to understand every detail of cluster configuration.
Knative’s Core Components
Knative is designed with a modular architecture. At the time of writing (early 2020), it comprised two primary components developed on independent release tracks:
Serving
The Serving component handles the actual execution of application code. It manages the lifecycle of containerised workloads: starting them when a request or event arrives, scaling them up under load, scaling them down to zero when idle, and routing traffic to the appropriate revision of a service. Serving is closely aligned with existing Kubernetes patterns and was the more mature of the two components.
Eventing
The Eventing component defines how external signals—a new database entry, a file appearing in object storage, a message on a queue, an inbound webhook—trigger Serving workloads. Eventing is broader in scope than Serving because it must accommodate a wide variety of event sources and delivery semantics, which is why it lagged behind Serving in its progression toward general availability.
Gracely summarised the relationship between the two components concisely:
“Events are the things that trigger your application code to work… Those are going to be the things that trigger your function to start. ‘Serving’ means actually start the application, do whatever computation I need to do, and then I have an action that comes out of that.”
Tekton: The Spun-Off Build Component
Early Knative development included a third component, Build, intended to provide CI/CD pipeline capabilities. The community decided that build functionality was generic enough to be useful far beyond the Knative project itself, so it was extracted and released as an independent project called Tekton. Tekton has since become a widely adopted, Kubernetes-native CI/CD framework in its own right.
Governance: Who Controls Knative?
Google transferred control of the Kubernetes project to the Cloud Native Computing Foundation (CNCF), a Linux Foundation project, in 2018. Developers widely expected Knative to follow the same path. However, shortly before KubeCon North America 2019 in San Diego, Google announced that it would retain stewardship of Knative for the foreseeable future—a decision that surprised parts of the community and raised questions about the project’s long-term neutrality.
This governance question is worth monitoring for any organisation evaluating Knative as a strategic platform component.
Ecosystem Integration
By early 2020, several commercial Kubernetes platforms were incorporating Knative. Red Hat indicated that Knative would become an integrated part of OpenShift and included in its core subscription. VMware (which had acquired Pivotal) was also positioning Knative as a layer for delivering improved developer experience on top of Kubernetes.
Why Knative Matters for DevOps Teams
- Portability: Knative workloads run on any conformant Kubernetes cluster, eliminating the need to rewrite function code when changing or adding cloud providers.
- Hybrid and multi-cloud support: Teams can run the same serverless workloads on-premises and in the public cloud without maintaining parallel deployment pipelines.
- Kubernetes simplification: The Serving abstraction provides a higher-level interface to Kubernetes that shields application developers from cluster-level complexity.
- Ecosystem compatibility: Tekton integration gives teams a Kubernetes-native CI/CD path that works alongside Knative without being tightly coupled to it.
- Cost model: Scale-to-zero behaviour means idle workloads consume no compute resources, preserving the economic advantage of serverless even when running on self-managed infrastructure.
Summary
Knative represents a practical attempt to standardise serverless on top of Kubernetes, giving DevOps teams a path to event-driven, auto-scaling workloads that aren’t tied to any single cloud provider. Its modular design—separating the concerns of event ingestion (Eventing) and workload execution (Serving)—makes it flexible enough to fit into a range of infrastructure configurations. For teams already invested in Kubernetes, Knative is a natural extension worth evaluating as serverless adoption grows beyond individual cloud platforms.