What Customers Want From the Kubernetes Ecosystem

This article is based on analysis originally published on Forbes.com (January 2020). The observations about Kubernetes adoption trends and customer pain points remain highly relevant to teams evaluating or operating Kubernetes today.

Kubernetes as Enterprise Infrastructure Backbone

Over the past several years, Kubernetes has matured from an experimental container orchestrator into the de facto foundation of modern enterprise infrastructure. It underpins major hybrid cloud platforms and has become one of the most widely adopted infrastructure technologies in large organisations. Despite this momentum, two structural challenges continue to slow enterprise adoption and frustrate day-to-day operations:

• A lack of clear separation between the developer experience and the operator experience.
• A lack of application context — the platform’s inability to treat a collection of related resources as a single logical application.

Challenge 1: The Blurred Line Between Dev and Ops

Kubernetes was architected to solve some of the hardest problems in scalable infrastructure. Built on containers, it delivers excellent workload scalability and reliability. However, its design philosophy is rooted in the concerns of system administrators and infrastructure operators — those who manage compute, network, and storage resources.

In traditional IaaS and PaaS environments, there is a reasonably clean boundary between developers and operators. Developers own the application lifecycle — they package, deploy, and iterate on code. Operators own the stability of the underlying platform. Each role has distinct responsibilities, tooling, and success metrics.

Kubernetes collapses that boundary. Regardless of whether a person’s title is Developer or Platform Engineer, anyone working with Kubernetes must develop a comparable depth of understanding of cluster concepts: packaging workloads, configuring resource requests and limits, defining health probes, managing scaling policies, and more. This uniform expectation creates real friction:

• Developers want to focus on rapid feature iteration and bug fixes. Being required to deeply understand Kubernetes primitives slows them down and increases cognitive load.
• Operators are measured on platform stability. Sharing ownership of deployment decisions with developers introduces risk and blurs accountability.

Enterprise Kubernetes customers are asking vendors and the open-source community for a better-defined developer experience — one that abstracts the infrastructure layer while still exposing the capabilities developers genuinely need, such as environment configuration, scaling hints, and observability hooks. Projects like the Open Application Model (OAM) and platforms like Knative and various internal developer platforms (IDPs) have emerged partly to address this need, but no single solution has become a universal standard.

Challenge 2: Kubernetes Lacks Application Context

When you deploy even a modest application on Kubernetes, the platform decomposes it into a collection of independent objects. Consider a basic web application backed by a database. A typical deployment might involve all of the following Kubernetes resources:

• Deployment — runs the frontend web server pods.
• StatefulSet — manages a highly available database instance.
• ConfigMap — holds configuration settings for the database server.
• Secret — stores credentials used by the application to connect to the database.
• PersistentVolume and PersistentVolumeClaim — provide durable storage for the database.
• Service — exposes the database to the frontend within the cluster.
• Ingress — exposes the web frontend to external traffic.

That is seven or more distinct objects for a simple two-tier application. Each object is managed independently by Kubernetes. The platform has no native concept of the application as a whole — it does not model the relationship between these objects or understand that they collectively represent a single unit of business logic.

Why Application Context Matters

Without application context, common lifecycle operations become unnecessarily complex:

• Health assessment: Determining whether the application is healthy requires checking multiple independent objects rather than querying a single entity.
• Deletion: Removing an application means tracking down and deleting each constituent resource individually, or relying on labels applied consistently at deploy time.
• Upgrades and rollbacks: Coordinating a change that spans a Deployment, a ConfigMap, and a Secret requires manual orchestration or tooling layered on top of Kubernetes.
• Auditing and cost attribution: Attributing resource consumption to a specific application requires consistent label discipline across all related objects — a discipline that is easy to let slip.

What the Ecosystem Has Done (and Not Done)

Helm, the most widely used Kubernetes package manager, partially addresses this problem at install time. A Helm chart groups related resources into a named release, making it possible to install or delete an application as a single operation. However, once a release is deployed, Kubernetes itself still treats each resource independently. If resources are modified outside of Helm — through kubectl apply, for example — the application context stored in the Helm release can diverge from the actual cluster state.

GitOps tools such as Argo CD and Flux address some of this gap by continuously reconciling desired state (stored in Git) with cluster state, and by surfacing application-level health. Custom Resource Definitions (CRDs) and Operators allow platform teams to define higher-level application abstractions that the Kubernetes API can then manage natively. These approaches move in the right direction, but they require significant investment and expertise to implement well.

What Customers Are Asking For

Enterprise teams adopting Kubernetes to run line-of-business applications are asking the ecosystem for several concrete capabilities:

1. A richer developer abstraction layer — tooling that lets developers define what their application needs (a web server, a cache, a database) without requiring them to author raw Kubernetes YAML for every primitive.
2. First-class application entities — a supported mechanism within or alongside Kubernetes to declare, package, and manage a unified application object, rather than a loosely coupled bag of resources.
3. Lifecycle management at the application level — the ability to deploy, update, roll back, inspect, and delete an application as an atomic unit.
4. Clear role boundaries — platform tooling that enforces sensible defaults and guardrails for developers while preserving operational control for platform engineers, without requiring every developer to become a Kubernetes expert.

The Bottom Line

Kubernetes has solved many of the hardest problems in distributed systems infrastructure. Its adoption across enterprises and cloud providers is a testament to that. But the platform’s infrastructure-centric design creates real usability gaps when it is used as the runtime for application teams who do not live and breathe cluster operations.

The next wave of progress in the Kubernetes ecosystem is less about raw platform capability and more about usability, abstraction, and application-level semantics. Teams evaluating Kubernetes platforms, internal developer platforms, and GitOps tooling should prioritise solutions that address these two pain points directly: clear developer/operator boundaries and genuine application-level lifecycle management.