Was niemand mehr versteht, aber alle benutzen

Ein mittelgroßes Setup hat schnell 20 Konfigurationsobjekte im Mesh. Ein gewachsenes hat 100. Ein großes über 500. Verteilt auf VirtualServices, DestinationRules, ServiceEntries, AuthorizationPolicies, EnvoyFilters.

Bei fünf Clustern reden wir über mehrere tausend Objekte. Bei zehn und mehr verliert irgendwann jeder den Überblick.

Das Problem ist nicht die Menge. Es ist die Asymmetrie.

Vieles kommt rein. Fast nichts geht wieder raus.

Jedes neue Feature bringt eine neue Policy. Jede Migration eine Handvoll ServiceEntries. Jeder externe Berater, jeder Proof of Concept, jedes “das brauchen wir kurz” hinterlässt Konfiguration im Cluster. Und dann bleibt sie da.

Ein Beispiel, das ich oft sehe: ServiceEntries in einem Mesh mit REGISTRY_ONLY. Irgendwann hat jemand einen externen Host freigeschaltet. Der Use Case ist längst weg. Der ServiceEntry steht noch. Niemand traut sich, ihn zu löschen, weil niemand weiß, ob noch etwas davon abhängt.

So wächst über die Jahre eine Schicht aus Objekten, die aktiv sind, aber deren Herkunft und Zweck niemand mehr erklären kann. “Wird wahrscheinlich gebraucht, lass mal stehen.” Das ist technische Schuld, die sich als Vorsicht tarnt.

Der Kern des Problems ist eine Frage, die in den meisten Teams nie beantwortet wurde: Wer darf eigentlich etwas wieder rausnehmen?

Anlegen darf fast jeder. Löschen traut sich keiner. Solange diese Asymmetrie besteht, wächst die rote Zone schneller als die grüne, und jedes Jahr wird das Mesh ein Stück unverständlicher.

Wer entscheidet bei euch, was wieder raus darf? Das wird das Thema für nächste Woche.