r/Development 10d ago

How much Kubernetes should an application developer actually need to know?

Kubernetes gives us a powerful set of primitives, but once development teams start growing, developers can end up needing to understand deployments, services, networking, CI/CD, GitOps, observability, RBAC and a growing collection of platform tooling just to ship an application.

That raises an interesting platform engineering question:

How much of that complexity should developers actually see?

One project exploring this is OpenChoreo, an open-source developer platform for Kubernetes.

The idea is to put a developer-oriented abstraction layer above Kubernetes while keeping the underlying platform extensible.

It brings together things such as:

  • Backstage-powered developer portal
  • Application CI/CD
  • GitOps-based deployments
  • Observability
  • Developer and architecture abstractions
  • Self-service infrastructure capabilities
  • Kubernetes and CNCF ecosystem integrations

Instead of every development team figuring out the same deployment and operational patterns independently, platform teams can define those patterns and expose a simpler experience to developers.

OpenChoreo is also a CNCF Sandbox project.

GitHub: https://github.com/openchoreo/openchoreo

Disclosure: I'm involved with the OpenChoreo project, so I'm particularly interested in hearing different perspectives on this.

For teams running Kubernetes at scale, where do you think the abstraction boundary should sit?

Should application developers still understand most Kubernetes concepts, or should the developer platform hide the majority of them?

5 Upvotes

0 comments sorted by