Das eigentliche Problem war nie Istio

Zehn Field Reports. Wenn ich auf die neun davor schaue, hatten fast alle dieselbe Wurzel. Und die saß nie in Istio.

Mal war es eine furchteinflößende Fehlermeldung, mal ein abgelaufenes Patch-Fenster, mal ein VirtualService, der fremden Traffic umleitet, mal ein grünes Dashboard, das im Incident schweigt. Neun Symptome, technisch sahen sie alle anders aus.

Darunter lag jedes Mal dieselbe Frage. Wer verantwortet das Netzwerkverhalten im Cluster wirklich. Welche Regeln gelten verbindlich und nicht nur auf einer Folie. Ob ein Incident reproduzierbar analysiert werden kann oder an einer einzelnen Person hängt.

Das ist keine Tool-Frage. Istio macht hier nichts falsch. Istio macht es nur sichtbar. Ein Mesh führt aus, was ihr vorher entschieden habt. Habt ihr Ownership, Regeln und Methode geklärt, macht es eine gute Organisation schneller und belastbarer. Habt ihr das nicht, beschleunigt es die Unklarheit, und zwar in Richtung teuer.

Deshalb scheitert ein Mesh-Projekt selten am YAML. Es scheitert daran, dass es als Tool-Rollout geplant wurde statt als Organisationsänderung. Die teure Frage ist nie „welches Mesh”. Sie ist „haben wir entschieden, wer das Netzwerkverhalten besitzt und wie wir es belegen”.

Genau da setze ich in Assessments an. Nicht bei der Config. Bei den drei Fragen, die kein Tool für euch beantwortet. Die Antworten bleiben bei euch, die Erfahrung, sie zu schärfen, bringe ich mit.

Ein Tool setzt durch, was du vorher entschieden hast. Auch dein Nicht-Entscheiden.

Nächste Woche schaue ich bewusst über Istio hinaus. Linkerd, Ambient, die Envoy-Ressourcen nebeneinander, ein ehrlicher aktueller Vergleich. Aber welches Mesh ist nie die erste Frage.

Welche Entscheidung hättet ihr vor eurem Mesh-Rollout gern früher getroffen?