What Nobody Understands Anymore, but Everyone Still Uses
20, 100, 500+ configuration objects - and no one dares to delete a thing.
- Date
- Topic
- Config lifecycle
- Reading time
- 2 min
- Version
- Translation
A mid-sized setup quickly ends up with 20 configuration objects in the mesh. One that has grown over time has 100. A large one, more than 500. Spread across VirtualServices, DestinationRules, ServiceEntries, AuthorizationPolicies, EnvoyFilters.
Figure as text
Sankey diagram of the service mesh configuration lifecycle, flowing from who created each object, to what is active in the cluster, to its status today. The takeaway: the red zone grows faster than the green one.
With five clusters, we’re talking several thousand objects. At ten or more, sooner or later everyone loses track.
The problem isn’t the volume. It’s the asymmetry.
A lot goes in. Almost nothing ever comes back out.
Every new feature brings a new policy. Every migration, a handful of ServiceEntries. Every external consultant, every proof of concept, every “we just need this for a bit” leaves configuration behind in the cluster. And then it stays there.
An example I see a lot: ServiceEntries in a mesh running REGISTRY_ONLY. At some point, someone opened up an external host. The use case is long gone. The ServiceEntry is still there. Nobody dares to delete it, because nobody knows whether anything still depends on it.
Over the years, this builds up a layer of objects that are active, but whose origin and purpose no one can explain anymore. “Probably still needed, better leave it alone.” That’s technical debt disguised as caution.
At the core of the problem is a question most teams have never answered: who is actually allowed to take something back out?
Almost anyone can create. Nobody dares to delete. As long as that asymmetry exists, the red zone grows faster than the green one, and every year the mesh gets a little harder to understand.
Who decides in your team what gets to come back out? That’s the topic for next week.
