Your team wraps every provider call behind an in-house abstraction so services could move - what does owning it cost?

## The third seam When no open interface exists and self-running the component is too expensive, the remaining option is an abstraction of your own: internal interfaces - an object-storage interface, a queue interface, a secrets interface, a workload-identity interface - that the services call instead of the platform. The platform's client sits behind that boundary, and in principle a second implementation could be dropped in later. This is the most powerful seam, because it is the only one that can hide differences nobody else standardised. It is also the only seam whose entire cost lands on your own team, forever. ## The wrapper is a product, not a layer Once a dozen services depend on it, the abstraction has every property of a product you buy: 1. **Owners.** Someone must be named, and must still be named after they change teams. 2. **Releases and versions.** Consumers upgrade at different times, so you need versioning, a compatibility policy and a way to ship a fix without a coordinated push across a dozen repositories. 3. **Documentation.** An interface nobody can read is re-implemented badly by each consumer. 4. **A support path.** During an incident, somebody has to answer whether the fault is in the wrapper or beneath it - and that question now exists, where before it did not. 5. **Deprecation.** Your own interfaces age. Removing one is the same migration problem in miniature, with you as the vendor. 6. **Testing.** The wrapper must be tested in its own right, including against the failure behaviour of what it wraps. ## The two structural costs Beyond staffing, two costs are structural and show up on every wrapper that survives a year. **Feature lag.** A capability shipped by the platform is unusable by consumers until someone extends the wrapper, reviews it, releases it and the consumers upgrade. The wrapper's backlog has quietly become the roadmap for everything behind it, and the team that owns it becomes a scheduling dependency for teams it does not report to. **The bypass problem.** A team blocked by that lag and under its own deadline will call the platform directly. That is not misbehaviour; it is the rational response. What matters is whether the bypass is sanctioned and recorded or unsanctioned and invisible. An abstraction that forbids bypass without being able to keep up produces a codebase where nobody knows which services are actually portable. | | Thin wrapper (two or three narrow interfaces) | Thick wrapper (a facade over the platform) | |---|---|---| | What it protects | the few dependencies that would dominate a move | everything, in principle | | Feature lag | limited to the wrapped surfaces | every capability, every time | | Maintenance | affordable for a small team | a standing team of its own | | Bypass pressure | low, and easy to allow explicitly | constant, and usually denied | | Evidence it works | one interface can be given a second backend | almost never tested end to end | ## The proof problem The uncomfortable part is that a wrapper with exactly one implementation behind it is **unproven**. It was written against one platform, so it inherits that platform's assumptions about latency, error taxonomy, consistency and limits without anyone deciding to encode them. The interface may look neutral and still be unusable against anything else. The only strong evidence is a second implementation carrying real traffic for at least one interface. A second backend exercised only in tests is weaker evidence, but far better than an argument about naming. What is not evidence at all: a design document asserting neutrality, an absence of provider names in the type signatures, or a high count of services that adopted it. ## When the wrapper is worth it It pays where the wrapped interface is genuinely proprietary, where the interface is narrow enough to specify in a page, and where many services use it - because the fixed running cost is then spread across all of them and the rewrite it avoids multiplies by the same factor. One storage or secrets interface used by a dozen services can justify a maintainer. It does not pay where the platform already implements an open interface (you would be wrapping a seam you already have), where only one or two services touch the dependency (rewriting them later is cheaper than maintaining a layer for years), or where the proprietary capability *is* the reason you chose the platform - an abstraction over it either hides the value you are paying for or reproduces it badly.