While Kubernetes promised freedom, portability, scalability, and infrastructure abstraction, for many organizations, that promise came with a cost: increased delivery complexity, operational bottlenecks, and a mounting cognitive load for developers and platform teams.
In a recent Software Plaza interview, Garrett Schumann, CEO of Mogenius, unpacked why Kubernetes delivery has become so hard, and how platform teams can rethink internal developer platforms (IDPs) to restore speed, clarity, and control.
This article focuses on how to platform engineering itself as a software product, and the steps to be taken to avoid many Kubernetes struggles.
The hidden cost of Kubernetes success
For many organizations, Kubernetes adoption is the easy part. However, the struggles come after successfully adopting. Early wins, containerization, CI/CD pipelines, and managed clusters often lead to rapid expansion. Before long, organizations find themselves managing dozens of environments, multiple clusters, fragmented tooling, and inconsistent workflows.
This “environment sprawl” creates several familiar pain points, including developers dependency on DevOps or SREs for routine tasks, platform engineers becoming ticket processors instead of enablers, how governance increases friction instead of reducing risk, and how debugging and recovery times grow as systems become opaque.
Ironically, Kubernetes’ flexibility becomes the very thing that slows teams down.
The platform engineering paradox
Platform teams are expected to make developers' lives easier while dealing with increasing complexity themselves. Building an internal developer platform means “building a product on top of an infrastructure for building products.” That’s a paradox many teams underestimate. Too often, internal platforms emerge as stitched-together collections of scripts, YAML files, CLIs, and dashboards. While functional, they lack the cohesion and usability of a true product.
The result? Cognitive load merely shifted, never truly reduced.
Treat internal platforms like products
When a platform is product-led, success is guaranteed. The formula for success is in clear ownership and long-term roadmap thinking, defined user personas such as, developers, SREs, platform admins, UX design focused on workflows, not just interfaces, and iterative improvement, not one-time rollout.
Surprisingly, many platform teams lack roles common in product development, such as product owners or UX designers. The absence shows up in clunky workflows, inconsistent abstractions, and poor developer adoption. An internal developer platform should deliver a “golden path” while also allowing teams to go deeper when needed.
Abstraction without security
One of the biggest risks in platform engineering is over-abstraction. Mogenius takes a deliberate stance here: abstract complexity, but don’t hide it.
Developers should be able to deploy, scale, and troubleshoot applications without needing to master Kubernetes internals. At the same time, the platform must allow visibility into what’s happening underneath, manifests, pipelines, GitOps workflows, and cluster behavior.
This balance is critical for long-term maturity. Platforms shouldn’t turn Kubernetes into a black box. They should make it approachable.
Reducing Bottlenecks Through Workflow Abstraction
A recurring theme in the webinar was how operational bottlenecks form around access and context.
Traditional Kubernetes workflows often require developers to juggle various items, including kubeconfigs and cluster credentials, multiple dashboards for metrics, logs, and pipelines, and separate tools for GitOps, access control, and deployments. Mogenius addresses this by introducing workspace-based abstractions.
Instead of exposing entire clusters, platform teams define workspaces that group only the relevant namespaces, applications, and resources a team needs. Developers interact with a focused environment, reducing noise and risk.
This approach delivers several benefits:
- Lower cognitive load for developers
- Clear ownership boundaries for platform teams
- Simplified access control and auditing
- Faster onboarding and troubleshooting
GitOps as a first-class platform primitive
In Mogenius’ model, Git remains the single source of truth. Platform teams can choose whether changes are applied directly or routed through pull requests, depending on environment, policy, or risk level.
This flexibility allows organizations to balance developer self-service in development environments, govern and review in staging and production, and have full auditability for compliance and traceability
Crucially, developers don’t have to leave their workflow to understand what’s happening. Deployment history, pipeline logs, and configuration changes are visible in context, reducing the “tool hopping” that slows teams down.
The right approach to start platform engineering
While considering how to start platform engineering without boiling the ocean, it is always recommended to begin with a single high-value use case. For many organizations, that’s environment provisioning or application delivery. Solve that problem well, then iterate.
This incremental approach avoids the trap of building a monolithic “perfect platform” that never ships. Instead, teams evolve their platform as a living product, responding to new tools, regulatory needs, and organizational growth.
Taking the correct approach
The perennial question while considering Kubernetes is to build or buy. The answer, unsurprisingly, is rarely binary.
While early Kubernetes adoption leaned heavily toward custom builds, the platform engineering ecosystem has matured. Vendor solutions now offer credible building blocks that can accelerate progress without locking teams into rigid models.
Mogenius positions itself as one piece of a broader platform puzzle, focused on Kubernetes application delivery while remaining open-source-friendly and integration-ready. This blended approach allows teams to preserve flexibility and standards, reduce undifferentiated engineering effort, and focus internal teams on higher-value platform capabilities.
What does the future hold?
Looking forward, there are three forces that will shape the next phase of platform engineering:
- Platform-first thinking – Platforms are becoming the default operating model for infrastructure and delivery.
- AI-assisted operations – Mogenius is introducing AI agents that analyze events, surface root causes, and guide remediation, reducing mean time to resolution.
- Multi-cloud and sovereignty demands – Standardization and abstraction will be essential as organizations balance resilience, compliance, and portability.
The way teams interact with infrastructure is changing, from manual operations to intent-driven, assisted workflows.
Reclaiming simplicity without losing power
Kubernetes isn’t going away, and neither is its complexity. With the right platform abstractions, workflow design, and product mindset, platform teams can turn Kubernetes into an accelerator rather than a bottleneck. The key isn’t hiding complexity, it’s making it manageable, navigable, and human-centric. That’s the real promise of platform engineering done right.
This blog is based on a webinar with Gerrit Schumann, CEO & Co-Founder of mogenius. To watch the full video, click here.
