This article is based on a piece originally published on containerjournal.com. The analysis and context below expand on the original arguments.
Kubernetes as Infrastructure: A Platform in Search of Developers
Over the last several years, Kubernetes has grown from a nascent open source project into a cornerstone of enterprise IT conversations. But look closely at those conversations and a pattern emerges: they are overwhelmingly focused on Kubernetes as an infrastructure platform.
Teams talk about network policies and load balancing, persistent storage and standards such as the Container Storage Interface (CSI), cluster provisioning and cloud provider integrations. These are legitimate and necessary topics—without solving them, Kubernetes cannot reliably run production workloads at scale. But solving infrastructure challenges alone does not make Kubernetes a compelling platform for the application developers who ultimately create business value on top of it.
Why the Application Layer Matters More Than the Infrastructure Layer
The business value of a platform like Kubernetes is not measured by how elegantly it is operated. Running Kubernetes is a means to an end—the end being applications that serve users and generate value. As responsibilities including testing, packaging, and security continue to shift left toward development teams, the pressure on Kubernetes to become genuinely developer-friendly grows correspondingly.
Kubernetes’ API-first design was an early strength. It attracted systems-oriented engineers who were comfortable reasoning about controllers, reconciliation loops, and declarative state. But the core primitives that underpin Kubernetes—ReplicaSet, Service, Ingress, PersistentVolumeClaim—remain relatively low-level compared to the abstractions offered by competing application platforms.
This low-level nature produces a real-world verbosity problem. Deploying even a modest application often requires authoring a Deployment manifest, a Service manifest, an Ingress manifest, possibly a CronJob, ConfigMaps, Secrets, and more—spread across multiple files, each with its own API version and schema considerations. For developers who simply want to ship software, this overhead is a genuine barrier.
Community-Led Efforts to Improve the Developer Experience
The cloud-native community has recognized the problem and is responding. Several coordinated efforts are underway to raise the abstraction level and reduce friction for developers working with Kubernetes.
CNCF SIG App Delivery
A Special Interest Group (SIG) dedicated to Application Delivery was established under the Cloud Native Computing Foundation (CNCF). SIG App Delivery focuses on the full lifecycle of cloud-native applications—developing, distributing, deploying, managing, and securing them. Its formation signals that the CNCF itself acknowledges the gap between Kubernetes as infrastructure and Kubernetes as an application platform.
The "Ruby on Rails Moment" for Kubernetes
At KubeCon + CloudNativeCon in San Diego, Bryan Liles—senior staff engineer at VMware at the time—used his keynote to call for Kubernetes to have its "Ruby on Rails moment." The analogy is instructive: Ruby on Rails transformed web development not by introducing new capabilities, but by applying the principle of convention over configuration. It made the right path the easy path. Liles argued Kubernetes needs an equivalent inflection point—one that lowers the cognitive cost of building and deploying applications without sacrificing power.
Tools Raising the Abstraction Level
Beyond community working groups and keynote aspirations, concrete tooling has emerged to address the developer experience gap. Below are several noteworthy examples.
Knative
Knative builds on top of Kubernetes and adds higher-level abstractions for common application patterns, particularly around serving and eventing. Its CLI tool, kn, illustrates the intended experience well: deploying an application can be reduced to specifying a name and a container image—a dramatic simplification compared to authoring raw Kubernetes manifests. Knative does require additional cluster-side components, which means it is best suited for environments where operators can manage that overhead centrally.
Kapp (part of the Carvel toolchain)
Kapp is a client-side tool that treats a collection of Kubernetes resources as a single, named application. It provides straightforward commands for deploying, listing, and deleting applications as coherent units, rather than managing individual resources in isolation. Crucially, Kapp requires no server-side components installed in the cluster, which lowers adoption friction and makes it easier to layer on top of existing environments. The underlying resources remain standard Kubernetes objects, preserving compatibility with the broader ecosystem.
Kapp is part of the broader Carvel toolchain (formerly known as k14s), a modular set of tools for templating, packaging, and deploying Kubernetes applications in a composable way.
Configuration Languages: ytt and CUE
Two tools tackling the verbosity of Kubernetes configuration from a different angle are ytt and CUE. Both aim to replace or augment raw YAML with more expressive, data-centric languages that allow templating and validation without sacrificing structure. Rather than bolting a general-purpose templating engine onto YAML (as Helm’s approach involves), they treat configuration as data that can be programmatically reasoned about—reducing duplication and improving correctness.
Other Notable Projects
- Rio (from Rancher): An application deployment engine for Kubernetes that provides higher-level abstractions for routing, scaling, and CI/CD integration.
- Open Application Model (OAM): A specification developed collaboratively—with Microsoft among the contributors—that separates application definition from operational concerns, allowing developers and operators to work from clearly delineated interfaces.
What a True Application Phase Would Look Like
For Kubernetes to fully enter its application phase, a few shifts need to take hold:
- Sensible defaults: Developers should not need to understand every infrastructure primitive to deploy a working application. Conventions should handle the common case, with escape hatches for advanced use.
- Application-centric tooling: CLI tools, dashboards, and APIs should speak the language of applications—deploy, scale, roll back, observe—not just of resources like Deployments and ReplicaSets.
- Reduced manifest verbosity: Configuration should express intent concisely. Higher-level languages and abstractions reduce the surface area for errors and the time spent on boilerplate.
- Developer-operator separation of concerns: Models like OAM explicitly delineate what developers control (application components and their traits) from what operators control (runtime environment and infrastructure). This boundary is essential for Kubernetes to serve both audiences well.
The Road Ahead
Progress on making Kubernetes a stronger application platform has been slower than some in the community anticipated—a sentiment that surfaced as far back as the earliest KubeCon Europe events. But the trajectory has shifted noticeably. The emergence of dedicated SIGs, widely discussed keynote themes, and a growing ecosystem of developer-focused tooling all point toward a maturing understanding of what Kubernetes needs to become.
The infrastructure foundations are solid. The next meaningful wave of Kubernetes adoption will be driven not by platform engineers tuning controllers, but by application developers who expect the platform to get out of their way. The tools and community energy to support that transition are increasingly in place.
Whether any single tool or standard delivers the definitive "Rails moment" for Kubernetes remains to be seen. But the direction of travel is clear, and the ecosystem is moving with real momentum.