Developers want Kubernetes environments available on demand. What they do not want is waiting weeks for provisioning tickets to clear. Platform teams, by contrast, bear responsibility for infrastructure costs, access permissions, and compliance with organizational policy. This fundamental tension shapes how Kubernetes self-service actually works: determining what developers can provision themselves versus what the platform team must control.

Marius Bogoevici, Senior Principal Product Manager at Hewlett Packard Enterprise (HPE), and Karthik Subramanian, Principal Product Manager for HPE Morpheus Software, recently discussed these friction points with The New Stack. Rather than debating whether self-service is worthwhile, the conversation centered on where to draw operational boundaries.

HPE's approach combines HKS, a CNCF-certified Kubernetes distribution, with HPE Morpheus Software to enable platform teams to deliver and manage Kubernetes environments across a broader operating model spanning Kubernetes, virtual machines, infrastructure, and cloud platforms. HPE Morpheus Advanced Software handles on-premises private-cloud scenarios using HKS, while HPE Morpheus Enterprise Software extends Kubernetes and application operations across hybrid and public-cloud deployments.

The two products work together to move beyond simple infrastructure provisioning. Service and application catalogs allow platform teams to connect pre-approved Kubernetes environments with CI/CD pipelines, container registries, automation tools, and other services developers already depend on. Rather than manually assembling toolchains for each project, developers get a governed, ready-to-use path from code to deployment.

The self-service paradox

Open-source Kubernetes provides orchestration and declarative APIs, but it does not deliver a complete operating model. Teams attempting to build their own self-service layer typically encounter two persistent challenges.

  1. Tool and package sprawl: Making upstream Kubernetes production-ready requires platform teams to curate and maintain a constantly evolving ecosystem of third-party CNCF tooling for networking (CNI), storage (CSI), ingress, identity, and policy enforcement. Supporting this fragmented stack creates substantial maintenance overhead for internal platform teams.
  2. Day-2 lifecycle and hybrid footprint complexity: Launching a Kubernetes cluster is straightforward, but maintaining it across development, QA, staging, and production environments is where complexity accumulates. HPE notes that every Kubernetes upgrade must be validated against the networking, storage, ingress, identity, and policy components surrounding it. The challenge intensifies when clusters span bare metal, private clouds, edge locations, and public clouds, since custom scripts and environment-specific configurations quickly introduce drift. This maintenance burden belongs with platform teams, not with developers focused on shipping applications.

Granting developers direct access to raw Kubernetes APIs does not eliminate operational work—it merely relocates it. Developers end up debugging manifests and storage drivers instead of writing code. Operations teams meanwhile contend with overprovisioned resources, idle clusters, and configurations that reach production without proper review.

What developers control — and what the platform supplies

The practical solution is not unlimited access. It is a paved path: pre-approved Kubernetes services that developers can request themselves, with access, configuration, placement, approvals, and lifecycle controls defined by the platform team.

The best candidates for self-service are requests that are repeatable, low-risk, and well-understood. For example, a developer should be able to request a development cluster, deploy an approved application, create a namespace, or select resources from pre-approved configurations without opening a ticket. The platform team decides what a safe configuration looks like, and the developer chooses from a supporting menu.

Marius Bogoevici, HPE

Rather than requiring developers to write YAML for ingress, storage classes, and RBAC, HPE Morpheus exposes these choices through service catalogs, reusable layouts and blueprints, workflows, role-based access control, approvals, APIs, and automation. Developers retain Kubernetes access through standard Kubernetes interfaces and tools where permitted, while the platform team standardizes the request, governance, and lifecycle processes surrounding them.

Catalog items can package more than infrastructure settings. They can integrate approved services and application components supporting the development workflow—including CI/CD tooling, source and artifact repositories, container registries, and runtime dependencies—while the platform team controls how those components are configured and governed.

Developers choose parameters that matter to their applications:

  • Approved Kubernetes versions and cluster sizes: Select from pre-tested Kubernetes runtime releases and node count templates.
  • Resource quotas: Specify required CPU, RAM, and persistent storage capacity tailored to the workload.
  • Integrated toolsets and IDE environments: Select required developer toolchains, container registries, and runtime dependencies.
  • Lease and duration limits: Define explicit operational lifetimes for temporary development or sandbox clusters to prevent abandoned infrastructure sprawl.

Network isolation, identity-provider integration, security policy, and cost allocation remain with the platform team and are applied automatically through the approved service configuration. The same division of responsibility applies to the delivery toolchain: developers choose from approved services, while the platform team manages the integrations, credentials, policies, and automation behind them. This delivers developers a consistent experience without shifting toolchain maintenance and governance onto individual application teams.

The division of responsibility breaks down as follows:

  • Developer control: Approved Kubernetes service, version, size, target environment, and duration.
  • Platform team control: Reusable layout or blueprint, access controls, placement rules, storage and network defaults, and lifecycle policy.
  • Exception handling: Nonstandard versions, placements, configurations, or requests outside quota.
  • Developer control: Application artifacts, target namespace, and deployment request through the approved path.
  • Platform team control: RBAC, tenancy, policy, audit, backup, and release controls appropriate to the environment.
  • Exception handling: Formal review for production changes and exceptions.
  • Developer control: CPU, memory, storage, and other approved capacity parameters within project limits.
  • Platform team control: Project quotas, upper bounds, placement constraints, and supported resource profiles.
  • Exception handling: Requests above quota or for specialized resources.
  • Developer control: Application endpoints and permitted connectivity within approved patterns.
  • Platform team control: Identity integration, RBAC, tenant isolation, network policy, secrets, and audit controls.
  • Exception handling: Cross-tenant access, elevated privileges, or changes to baseline security policy.
  • Developer control: Service lifetime and approved operational actions.
  • Platform team control: Visibility, policy, approvals, retirement workflows, and applicable cost controls for the licensed variant.
  • Exception handling: Long-running exceptions, nonstandard lifecycle actions, or budget exceptions.

From ticket queues to a repeatable paved path

In traditional IT environments, provisioning a dedicated Kubernetes environment for a new project typically involves cross-departmental ticket handoffs spanning infrastructure, networking, security, and storage teams. This friction frequently extends provisioning timelines from days to weeks.

By unifying infrastructure orchestration, role-based access controls, and multi-tenancy into a single operational experience, HPE Morpheus Software can compress these provisioning workflows to minutes or hours, according to HPE. Developers receive a usable environment that complies with organizational controls and policies without needing to understand the complex infrastructure steps underneath.

When you reduce provisioning time from weeks to hours, that is super meaningful and tangible.

Marius Bogoevici, HPE

The benefit extends beyond faster cluster provisioning. HPE Morpheus Software can automate the handoff into the developer's established delivery process by making approved CI/CD and application services available with the environment. Instead of waiting for separate teams to connect pipelines, registries, credentials, and runtime dependencies, developers receive a ready-to-use path from development through deployment.

Faster provisioning introduces a different challenge: teams can lose track of what was provisioned and why. HPE Morpheus Software provides administrators visibility into utilization and cost, while lease controls can automatically shut down temporary development clusters when their time expires.

Bogoevici notes that ticket volume is a poor measure of success, particularly early on when more developers may be trying the catalog. He recommends tracking deployment success, exception rates, resource utilization, and the day-to-day effort required to keep the service running.

Security belongs in the service design

Security represents another boundary that must be designed into the self-service path. If identity, access, tenancy, and policy are added only after a cluster is created, every request generates additional work and inconsistency.

Security must be a core design consideration built directly into the service, not an afterthought during deployment. HPE Morpheus Software brings identity integration, role-based access, tenant isolation, approvals, and policy into the operational workflow.

Marius Bogoevici, HPE

A newly provisioned environment should arrive through an approved configuration with the applicable identity, RBAC, tenant, policy, and audit controls attached. Platform teams can validate the paved path by testing an allowed request, a request that should be rejected, and the resulting audit record.

The operating-model test

The strongest Kubernetes self-service model does not hide Kubernetes or make it the control plane for every workload. It gives developers useful, approved choices and direct access to the Kubernetes workflows they need, while the platform team standardizes the enterprise processes around those workflows.

This matters because enterprises still run virtual machines, clouds, and existing infrastructure alongside Kubernetes. HPE Morpheus Software helps platform teams use common request, governance, automation, and lifecycle processes across these environments without forcing every workload onto one runtime or creating another operational silo.

In practice, self-service should deliver more than a Kubernetes cluster. With HPE Morpheus Software, a catalog request can bring together the approved environment, application services, and DevOps toolchain integrations developers need, while preserving the governance and lifecycle controls the platform team requires. Developers spend less time assembling and troubleshooting delivery infrastructure and more time building and releasing applications.

Looking toward 2027, the goal is not unrestricted control. It is faster access, predictable results, transparent guardrails, and a clear exception path when the standard service does not fit.