A platform provides service templates and teams' services diverge from them within months. What should the template strategy be?
Show the full answer Hide the answer
Why divergence happens
A template is a copy taken at a point in time. Once generated, the service is the team's, and every subsequent platform improvement — a security fix, a new observability standard, an updated base image — has to be applied by each team individually.
Within months, services span every template version ever issued, and a platform-wide change requires touching all of them.
The strategies, and their trade-offs
1. Template as a starting point. Simple, and divergence is guaranteed. Fine for genuinely one-off scaffolding and inadequate for anything the platform must be able to update.
2. Template plus a shared library. The generated code is thin; the behaviour lives in a versioned library the team upgrades. Platform changes ship as library releases. This is usually the right primary mechanism — but it only covers what can live in a library, and teams still control when they upgrade.
3. Automated update propagation. The platform opens a change against every service when the template updates. Teams review and merge rather than implementing. This is the mechanism that makes fleet-wide change feasible, and it requires the platform to have the tooling and the right to propose changes across repositories.
4. Runtime injection. Observability, identity and policy supplied by the platform at runtime — a sidecar, an admission controller, a base image — rather than by generated code. The strongest option where it applies, because it requires no team action at all.
The workable combination
Runtime injection for what can be injected; a versioned library for what cannot; automated propagation for what must live in the repository; and a thin template for genuine scaffolding.
That minimises what is copied and therefore what can diverge.
The obligation this creates
Backward compatibility and a deprecation policy for platform interfaces. Internal consumers are as broken by a breaking change as external ones, and a platform that breaks its users loses them permanently — after which they build their own and never return.
The measure
The spread of template and library versions across the fleet, and the time for a platform change to reach the majority of services. Both are direct measures of whether the platform can actually change anything.