Choosing Your Strategy: The Decision Matrix

There is no universally correct answer.

The right wrapper thickness depends on four variables: workload diversity, developer skill level, platform team capacity, and compliance requirements. Use this matrix as a starting point, not a prescription.

Choose Thin If:

1. Complex or diverse workloads. Your teams run stateful databases, GPU training jobs, ML inference servers, or other specialized workloads that require fine-grained Kubernetes control. A thick wrapper will constantly be playing catch-up.
2. Infrastructure-savvy developers. Your application teams have strong DevOps skills and want direct control. Abstracting Kubernetes away from them creates frustration, not productivity.
3. Small platform team. Building and maintaining a custom PaaS is a significant engineering investment. If your platform team is two people, a thin wrapper with good policies is far more sustainable.
4. Rapidly evolving requirements. If your workload patterns are changing quickly, a thick wrapper will become a bottleneck. Thin wrappers adapt faster because developers can use new Kubernetes features immediately.

Choose Thick If:

1. Uniform, stateless workloads. If 90% of your applications are standard HTTP microservices, a thick wrapper can handle them all with a single template. The 10% edge cases can use the escape hatch.
2. Product-focused developers. Your teams are hired to build product features, not manage infrastructure. Kubernetes YAML is a distraction from their core job.
3. Strict compliance requirements. In banking, healthcare, or government, you may need to guarantee that every workload has specific security controls applied — controls that developers cannot accidentally or intentionally remove. A thick wrapper enforces this structurally.
4. Large developer population. If you have 500 developers and a 5-person platform team, you cannot afford to onboard each developer to Kubernetes. A thick wrapper multiplies the platform team's leverage.

The Hybrid Model: Thick Default, Thin Escape Hatch

The most mature platforms converge on a hybrid model: a thick wrapper that handles the common case, with a structured escape hatch for the edge cases.

The key insight: the escape hatch is not a failure of the thick wrapper — it is a feature. It prevents the platform from becoming a bottleneck while still providing the standardization benefits for the common case. Over time, patterns that frequently appear in escape hatches should be promoted into first-class platform features.