"Just give me your code."
In a Thick Wrapper approach, the platform team builds a custom abstraction layer that sits on top of Kubernetes. Developers never write Kubernetes YAML. They interact with a simplified interface — a short config file, a CLI command, or a web UI — and the platform translates that into the full set of Kubernetes objects behind the scenes.
Think of it like a food delivery app. You tap "order pizza." You don't know which restaurant, which driver, which route, or which payment processor was used. The complexity is entirely hidden. This is the Heroku model applied to internal infrastructure.
The Interface: A simplified developer-facing file — often called an app.yaml, service.yaml, or a custom Kubernetes Custom Resource Definition (CRD) — that only asks for high-level information:
# app.yaml — the developer writes only this
name: payment-service
image: internal-registry.company.com/payment:v2.1.0
port: 8080
replicas: 3
public: true
environment: production
The Abstraction: The platform reads this file and generates the full set of Kubernetes objects: Deployment, Service, Ingress, HorizontalPodAutoscaler, ServiceAccount, NetworkPolicy, PodDisruptionBudget, and any required annotations for logging and monitoring. The developer never sees these objects. The platform team owns them.
A common implementation pattern uses a Kubernetes Operator — a controller that watches for custom resources and reconciles the desired state by creating and managing the underlying K8s objects. Tools like Crossplane, KubeVela, and Backstage are frequently used to build thick wrapper platforms.
Pros and Cons
Advantages:
- Near-zero cognitive load. Developers don't need to know Kubernetes exists. They focus entirely on their application code and business logic.
- Guaranteed standardization. Every application deployed through the platform gets the same security posture, logging configuration, resource tagging, and network policies — automatically. There is no way to accidentally skip a PodDisruptionBudget.
- Faster onboarding. A new developer can deploy their first service in minutes, not days.
- Compliance by default. In regulated industries, the platform can enforce controls (encryption, audit logging, network segmentation) that developers cannot bypass even if they wanted to.
Disadvantages:
- The Leaky Abstraction problem. Every abstraction eventually meets a use case it didn't anticipate. When a Data Science team needs to mount a shared memory volume, or a team needs a custom init container, they are blocked until the platform team adds support. The abstraction "leaks."
- Platform team burden. The platform team is now building and maintaining a complex software product. This requires dedicated engineering capacity, versioning, backward compatibility, documentation, and a support model.
- Reduced developer agency. Experienced developers may feel constrained. They know exactly what Kubernetes setting they need, but they cannot apply it without going through the platform team.