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.

What Is the DevOps Market?

DevOps — the practice of integrating software development (Dev) and IT operations (Ops) into a continuous, collaborative workflow — has grown from an engineering philosophy into a substantial global software and services market. Organisations across virtually every industry vertical now invest in DevOps toolchains, platforms, consulting services, and training to accelerate software delivery, improve reliability, and reduce time-to-market.

The market encompasses a wide range of product categories: continuous integration/continuous delivery (CI/CD) platforms, container orchestration tools, configuration management software, monitoring and observability solutions, and cloud-native infrastructure services.

Major Vendors in the DevOps Space

The competitive landscape includes established enterprise software vendors alongside specialist DevOps tooling providers. Frequently cited participants in market analyses from this period include:

• CA Technologies (now Broadcom) – enterprise value stream management and release automation
• IBM Corporation – hybrid cloud DevOps tooling and consulting services
• Dell EMC – infrastructure and storage solutions underpinning DevOps pipelines
• Cisco Systems – networking and security tooling integrated into DevOps workflows
• Docker, Inc. – container runtime and image registry technology foundational to modern CI/CD
• Clarizen – project and work management integrated with delivery pipelines

Beyond this list, the broader ecosystem includes vendors such as HashiCorp, GitLab, Atlassian, Microsoft (Azure DevOps), Amazon Web Services, Google Cloud, JFrog, and many others. The market is highly fragmented, with significant activity in mergers, acquisitions, and partnership agreements.

Key Industry Verticals Driving Adoption

DevOps adoption is not uniform across sectors. Research consistently identifies several verticals as leading adopters:

• Information Technology (IT) and Software – the natural home of DevOps; pure-play software companies and IT service providers have the highest adoption rates.
• Banking, Financial Services, and Insurance (BFSI) – regulatory pressure and competitive disruption from fintech drive heavy investment in rapid, auditable software delivery.
• Retail and E-commerce – high transaction volumes and seasonal demand spikes make continuous deployment and infrastructure elasticity business-critical.
• Telecommunications – network function virtualisation (NFV) and 5G rollouts demand DevOps-style automation for both software and infrastructure provisioning.

Growth Drivers

Several structural forces sustain demand for DevOps tooling and services:

• Cloud migration – moving workloads to public and hybrid clouds creates demand for infrastructure-as-code and automated provisioning tools.
• Agile adoption at scale – as organisations mature beyond team-level Agile, DevOps practices bridge the gap between development velocity and operational stability.
• Containerisation and microservices – the widespread adoption of Docker and Kubernetes requires supporting CI/CD, secrets management, and observability tooling.
• Security integration (DevSecOps) – embedding security scanning, policy enforcement, and compliance checks into pipelines is now a procurement requirement for many enterprise buyers.
• Digital transformation programmes – legacy modernisation projects across banking, government, and manufacturing generate sustained consulting and tooling spend.

Market Restraints and Challenges

Despite strong tailwinds, several factors can slow or complicate DevOps adoption:

• Cultural and organisational resistance – siloed teams and legacy approval processes are often harder to change than technology stacks.
• Skills shortages – demand for engineers with cross-functional expertise in both development and operations outpaces supply in most markets.
• Toolchain complexity – the breadth of the DevOps ecosystem can lead to integration debt and vendor sprawl, increasing total cost of ownership.
• Regulatory constraints – heavily regulated industries face compliance requirements that can conflict with continuous deployment models, requiring careful pipeline design and audit logging.
• Security concerns – faster delivery cycles can introduce vulnerabilities if security gates are not properly integrated into the pipeline.

Regional Dynamics

North America — particularly the United States — has historically led DevOps adoption, driven by a mature cloud ecosystem, a high concentration of software companies, and large enterprise IT budgets. Europe follows, with strong uptake in financial services and manufacturing sectors in the UK, Germany, and the Nordic countries.

Asia-Pacific represents the fastest-growing region, with rapid digitalisation in India, China, Australia, and Southeast Asia. Emerging markets in Latin America and the Middle East are also investing in DevOps capabilities as part of broader digital infrastructure programmes.

Competitive Trends: M&A, Partnerships, and Innovation

The DevOps vendor landscape has been shaped by significant consolidation. Acquisition activity — such as Broadcom’s purchase of CA Technologies and VMware, IBM’s acquisition of Red Hat, and Microsoft’s acquisition of GitHub — reflects the strategic importance of DevOps capabilities to large platform vendors. These moves signal a shift toward integrated, opinionated platforms rather than point solutions.

At the same time, open-source projects continue to drive innovation at the tooling layer. Projects under the Cloud Native Computing Foundation (CNCF) — including Kubernetes, Argo CD, and Tekton — set de facto standards that commercial vendors build upon.

What to Watch Going Forward

For DevOps engineers and platform teams, the following trends are worth tracking:

• Platform engineering – internal developer platforms (IDPs) that abstract infrastructure complexity and provide self-service capabilities to development teams.
• AI-assisted operations (AIOps) – machine learning applied to log analysis, anomaly detection, and incident response automation.
• GitOps – using Git as the single source of truth for declarative infrastructure and application configuration, enforced by continuous reconciliation loops.
• Supply chain security – software bill of materials (SBOM), provenance attestation, and signed artefacts becoming baseline requirements in enterprise procurement.
• FinOps integration – tighter coupling of cost visibility and budgeting controls into delivery pipelines to govern cloud spend at the team level.

The DevOps market continues to mature, but adoption is far from complete — particularly in mid-market and public sector organisations. Engineers who can demonstrate measurable delivery and reliability outcomes, not just tool proficiency, will remain in strong demand.