Platform Abstraction Level
How far a platform hides the underlying infrastructure, and the leak-versus-flexibility trade it makes at that height.
Every platform picks a height and lives with the consequences. Low abstraction — thin wrappers over cloud primitives — is flexible, teaches transferable skills and rarely blocks anyone, but leaves each team solving the same problems and producing forty inconsistent answers.
High abstraction — a manifest describing a service, from which everything is generated — delivers enormous leverage and consistency, right up to the moment a team needs something the abstraction cannot express. Then the choice is to extend the abstraction, which grows it towards the complexity it was hiding, or to break out of it, which forfeits the leverage.
The governing rule is that abstractions leak under failure. A developer who never sees the cluster cannot debug the cluster, so at 3 AM the platform team becomes the escalation path for every team it abstracted for. That is a staffing consequence, not a design detail.
The pragmatic position most successful platforms land on: a high-level default that covers the large majority of services, with a documented, supported escape hatch to the layer beneath rather than a cliff.