Was niemand mehr versteht, aber alle benutzen

20, 100, 500+ Konfigurationsobjekte - und niemand traut sich, etwas zu löschen.

Datum
Thema
Config-Lifecycle
Lesezeit
2 Min.

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.

Grafik: OMNI52 Abbildung in voller Größe öffnen
Abbildung als Text

Flussdiagramm zum Lebenszyklus von Service-Mesh-Konfiguration: Objekte von Plattform-Team, Service-Teams, Migrationen und unbekannter Herkunft fließen in den Cluster, aber nur ein kleiner Teil wird bewusst wieder entfernt. Der größte Strom bleibt aktiv bei unklarer Ownership, so wachsen über Jahre technische Schulden.

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.

Über den Autor

Porträt von Uli Renz

Uli Renz baut und härtet seit Istio 1.4 Service Meshes in streng regulierten Enterprise-Umgebungen. Die Muster in diesen Reports stammen aus dieser Arbeit.

Läuft dein Mesh schon in Produktion, ist der Posture Check der Einstieg: 13 Prüfbereiche, jeder Befund mit Schweregrad und Config-Beleg. In 90 Minuten gehen wir die Liste gemeinsam durch.

Strategiegespräch anfragen