There is an invisible tax on backend engineering that rarely gets talked about in job descriptions.
You built the service. The logic is solid, tests pass, code reviewed and merged. Now comes the other thing. Write the Deployment manifest. Figure out the resource limits. Configure the Service and the Ingress. Set up the NetworkPolicy. Wire the environment variables per env. Make sure staging is not accidentally talking to prod dependencies.
None of that is backend engineering. But it regularly falls on backend engineers because the platform layer underneath them was never properly abstracted.
The gap between “I write services” and “I also manage Kubernetes primitives”
The core problem is that most Kubernetes setups expose too much surface area to developers who should not need it. Namespaces, HTTPRoutes, resource quotas, Kustomize overlays. These are platform concerns, not service concerns.
A well-designed platform should let a backend engineer express intent. I want to deploy this service. I want it to be reachable from this other service. I want it exposed publicly on this path. And the platform should compile that intent into whatever Kubernetes primitives are needed, without the engineer ever touching them.
Developers define application intent through high-level abstractions. The platform compiles this model into the necessary Kubernetes resources, network policies, gateways, and observability hooks.
That is the shift. From “here is a Deployment YAML, good luck” to “tell me what you need and I will handle the infrastructure.”
A deployable unit within a project maps to workload resources like Deployment, Job, or StatefulSet. A network-accessible interface exposed by a component includes routing rules, supported protocols, and visibility scopes such as public, organization, or project level. The backend engineer thinks in those terms. The platform handles the rest.
Where I saw this working
I contribute to OpenChoreo, an open source CNCF project built around exactly this idea. Working on it made me appreciate how much developer velocity is lost when the abstraction boundary sits in the wrong place.
Backend engineers should spend their time on services, not on becoming accidental platform engineers.
Is this a problem your team has solved, or is Kubernetes still leaking into your development workflow?
_If you are curious: _<a href="https://openchoreo.dev/" target="_blank" rel="noopener nofollow">https://openchoreo.dev/</a>

You can share you thought with this squad 

Backend Developer 

Most backend engineers are burdened with Kubernetes complexity that shouldn't be their concern. Writing Deployment manifests, configuring Ingress, setting NetworkPolicies, and managing resource limits are platform concerns, not service concerns. A well-designed internal developer platform should let engineers express intent at a high level — what to deploy, how it should be reachable, what paths to expose — and compile that into Kubernetes primitives automatically. OpenChoreo, an open source CNCF project, is cited as an example of this abstraction model in practice. The argument is that the abstraction boundary in most orgs sits too low, forcing backend engineers to become accidental platform engineers.

Backend engineers shouldn't need to understand Kubernetes to deploy their services. But most still do.