The Core Misconception: Kubernetes as an Instant Platform

Many teams declare they have “built a platform” simply because they are running Kubernetes. This statement often masks a fundamental misunderstanding of what Kubernetes delivers. The reality for many developers is that after adopting Kubernetes, they still must manually assemble numerous components to ship a service. This includes defining Deployment objects for application deployment, Service resources for network access, HorizontalPodAutoscaler for scaling, NetworkPolicy for network segmentation, PodDisruptionBudget for availability, and ServiceAccount for identity. On top of these, they often need to craft custom, environment-specific configurations and integrations, or “glue” code, to make everything work together.

This is a category error. Kubernetes provides the foundational infrastructure, the substrate, but the actual developer platform—the cohesive, opinionated, and easy-to-use system that abstracts away operational complexity—is typically still missing or incomplete. The raw tools provided by Kubernetes, like kubectl and YAML manifests, require significant effort to transform into a true platform experience.

Diagram illustrating the difference between Kubernetes substrate and a built developer platform

What Kubernetes Actually Provides: The Building Blocks

The official Kubernetes documentation itself clarifies this distinction. Under the heading “What Kubernetes is not,” the project explicitly states that Kubernetes is “not a traditional, all-inclusive PaaS.” Instead, it is designed to provide “the building blocks for building developer platforms.” This means the core project offers primitives—fundamental components and APIs—that developers and operators can use to construct higher-level abstractions and services. Think of Kubernetes less like a finished house and more like a meticulously organized lumberyard, complete with precise measurements and a catalog of materials. You have all the essential components, but you still need an architect and builders to construct the actual dwelling.

The Kubernetes API server, etcd, kubelet, and controller manager are the engines that power the system, managing desired states for pods, services, volumes, and more. However, these powerful capabilities are exposed through APIs and command-line tools that are inherently low-level. To achieve a platform-like experience, teams must layer additional tooling, automation, and opinionated workflows on top of this core. This includes:

  • CI/CD Pipelines: Automation for building, testing, and deploying applications.
  • Observability Stack: Integrated logging, monitoring, and tracing solutions (e.g., Prometheus, Grafana, ELK stack).
  • Service Meshes: Advanced traffic management, security, and observability for microservices (e.g., Istio, Linkerd).
  • Policy Enforcement: Tools for managing security policies, network rules, and resource quotas (e.g., OPA Gatekeeper).
  • Developer Portals: Self-service interfaces for developers to provision resources, manage deployments, and access documentation.
  • Secrets Management: Secure handling of sensitive information.

Without these layers, developers are left to navigate the complexities of Kubernetes directly, often relying on tribal knowledge or extensive documentation to perform routine tasks. This significantly slows down development velocity and increases the cognitive load on engineering teams.

The Cost of a "Toolkit" Approach

When Kubernetes is treated solely as a toolkit, the burden falls heavily on individual development teams. Each team might end up reinventing wheels, creating their own deployment scripts, monitoring setups, and environment configurations. This leads to:

  • Inconsistency: Different teams adopt different approaches, making it difficult to manage, secure, and operate applications uniformly across the organization.
  • Duplication of Effort: Engineering time is spent on operational concerns rather than on building product features.
  • Steep Learning Curve: Developers must become Kubernetes experts, diverting focus from their primary application development responsibilities.
  • Security Gaps: Without a centralized, opinionated platform, it’s easier for security best practices to be overlooked or inconsistently applied.
  • Operational Overhead: Maintaining the underlying Kubernetes infrastructure alongside the assembled tooling becomes a significant challenge.

The claim that a team has “built a platform” often signifies that they have successfully orchestrated a set of Kubernetes primitives and external tools to meet their specific needs. However, this is distinct from Kubernetes itself being the platform. The distinction is critical because it highlights the ongoing work required to abstract complexity and deliver a true developer experience.

Building the Platform on Kubernetes

The path to a true developer platform on Kubernetes involves creating abstractions that simplify the developer’s interaction with the cluster. This can be achieved through various means:

  • Internal Developer Platforms (IDPs): Companies like Backstage, Humanitec, and Port provide frameworks and tools to build these abstractions. They offer self-service capabilities, standardized workflows, and curated access to underlying Kubernetes resources.
  • Platform Engineering Teams: Dedicated teams focused on building and maintaining the internal developer platform, ensuring it meets the needs of product teams.
  • Managed Kubernetes Services: Cloud providers offer managed Kubernetes services (EKS, GKE, AKS) that handle the control plane's operational burden, but they still require the customer to build the platform layer on top.
  • Kubernetes Distributions: Some distributions package Kubernetes with additional components and management tools, offering a more integrated experience out-of-the-box, but often still require customization for a full platform.

The key is to move beyond raw Kubernetes primitives and provide developers with a higher-level interface. This interface should handle the intricacies of resource creation, deployment strategies, scaling policies, and security configurations, allowing developers to focus on writing code and delivering business value. If your developers are still writing `Deployment`, `Service`, and `HorizontalPodAutoscaler` YAML by hand for every new service, your organization has a robust Kubernetes cluster, but it has yet to fully realize its potential as a developer platform.