A platform team must decide how much to abstract the underlying infrastructure. What goes wrong at each extreme, and how do you choose?

The two failure modes

Too little abstraction: the platform exposes raw infrastructure, so every team must understand Kubernetes manifests, IAM policies, network configuration and storage classes. The platform provides no leverage, every team solves the same problems, and the results vary in quality — which is the situation the platform existed to fix.

Too much abstraction: the platform exposes a simple interface that covers the common case and cannot express anything else. Teams with legitimate needs are blocked, the platform team becomes a queue for exceptions, and when something breaks, the abstraction hides the mechanism so nobody can debug it.

The second failure is worse, and it is the more common one, because the abstraction is designed against the requirements known at the time and requirements accumulate.

The property that resolves it

A good platform abstraction is simple for the common case and does not prevent the uncommon one.

Concretely: a team specifies "a service with this much memory, this scaling behaviour, this database" without touching a manifest — and a team with a genuine need can drop to the underlying primitives without leaving the platform.

The abstraction is a default, not a wall. This is the same principle as the paved road: easier than the alternative, not the only permitted path.

Design guidance

• Abstract the composition, not the components. Generating a correct, complete set of resources from a small specification is high value. Hiding what those resources are is low value and costs debuggability.
• Keep the generated output inspectable. A team should be able to see exactly what was created. An abstraction whose output cannot be read is undebuggable at 3am, which is when it matters.
• Provide escape hatches at every layer, ideally graduated: override a field, supply a fragment, or take full control of one resource while the platform manages the rest.
• Make the escape visible rather than punished, and treat repeated escape in the same direction as roadmap input — the most valuable signal the platform team receives, and available only if escape is permitted.
• Do not abstract away the thing that will need debugging. Networking, permissions and scheduling behaviour will be debugged; abstraction over them must be transparent.
• Version the abstraction and keep it compatible, since teams depend on it and forced migrations at the platform's convenience destroy trust.

The diagnostic question

When something breaks, can the team debug it themselves?

If every incident requires the platform team, the abstraction is too opaque and the platform team has become a permanent bottleneck — which is both an operational failure and a scaling failure, since it grows with adoption.

What determines the right level for a given organisation

The capability and inclination of the teams using it. A platform serving hundreds of product engineers who neither know nor wish to know Kubernetes should abstract heavily. A platform serving twenty infrastructure- literate teams should be thin, providing composition and consistency rather than concealment.

Getting this wrong in either direction is the most common reason platforms are resented, and it is a question about people rather than about technology.