Wat niemand meer begrijpt, maar iedereen gebruikt

Een middelgrote setup heeft al snel 20 configuratieobjecten in het mesh. Een gegroeide setup 100. Een grote meer dan 500. Verdeeld over VirtualServices, DestinationRules, ServiceEntries, AuthorizationPolicies, EnvoyFilters.

Bij vijf clusters praten we over meerdere duizenden objecten. Bij tien of meer verliest vroeg of laat iedereen het overzicht.

Het probleem is niet de hoeveelheid. Het is de asymmetrie.

Er komt veel bij. Er gaat bijna niets meer uit.

Elke nieuwe feature brengt een nieuwe policy mee. Elke migratie een handvol ServiceEntries. Elke externe consultant, elk proof of concept, elk “dit hebben we even nodig” laat configuratie achter in het cluster. En daar blijft die dan staan.

Een voorbeeld dat ik vaak zie: ServiceEntries in een mesh met REGISTRY_ONLY. Ooit heeft iemand een externe host opengezet. De use case is allang verdwenen. De ServiceEntry staat er nog. Niemand durft hem te verwijderen, omdat niemand weet of er nog iets van afhangt.

Zo groeit er in de loop van de jaren een laag objecten die actief zijn, maar waarvan niemand meer kan uitleggen waar ze vandaan komen of waarvoor ze dienen. “Wordt waarschijnlijk nog gebruikt, laat maar staan.” Dat is technische schuld die zich vermomt als voorzichtigheid.

De kern van het probleem is een vraag die in de meeste teams nooit beantwoord is: wie mag er eigenlijk iets weer weghalen?

Aanmaken mag bijna iedereen. Verwijderen durft niemand. Zolang die asymmetrie bestaat, groeit de rode zone sneller dan de groene, en wordt het mesh elk jaar een stukje onbegrijpelijker.

Wie bepaalt bij jullie wat er weer uit mag? Dat wordt het onderwerp voor volgende week.