Wat niemand meer begrijpt, maar iedereen gebruikt

20, 100, 500+ configuratieobjecten - en niemand durft iets te verwijderen.

Datum
Onderwerp
Config-lifecycle
Leestijd
2 min
Versie
Vertaling

Lees het Duitse origineel

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.

Grafiek: OMNI52 Afbeelding op volledige grootte openen
Afbeelding als tekst

Sankey-diagram van de configuration lifecycle in een service mesh: van wie de objecten heeft aangemaakt, via actief in het cluster, naar de status van vandaag. Kernboodschap: de rode zone groeit sneller dan de groene.

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.

Over de auteur

Portret van Uli Renz

Uli Renz bouwt en beveiligt sinds Istio 1.4 service meshes in sterk gereguleerde enterprise-omgevingen. De patronen in deze reports komen uit dat werk.

Draait je mesh al in productie, dan is de Posture Check de eerste stap: 13 controlegebieden, elke bevinding met een ernstniveau en een onderbouwing uit de configuratie. In 90 minuten lopen we de lijst samen door.

Strategiegesprek aanvragen

Het aanvraagformulier op istio-consulting.de is in het Duits.