Het echte probleem was nooit Istio

De ene keer was het een angstaanjagende foutmelding, de andere keer een verlopen patch-window, dan weer een VirtualService die andermans traffic omleidt, of een groen dashboard dat tijdens een incident zwijgt. Negen symptomen, technisch zagen ze er allemaal anders uit.

Daaronder lag elke keer dezelfde vraag. Wie is er echt verantwoordelijk voor het netwerkgedrag in het cluster. Welke regels zijn bindend en niet alleen op een slide. Of een incident reproduceerbaar geanalyseerd kan worden of van één persoon afhangt.

Dit is geen tool-vraag. Istio doet hier niets fout. Istio maakt het alleen zichtbaar. Een mesh voert uit wat jullie vooraf hebben besloten. Hebben jullie ownership, regels en methode helder, dan maakt het een goede organisatie sneller en robuuster. Hebben jullie dat niet, dan versnelt het de onduidelijkheid, en wel de dure kant op.

Daarom strandt een mesh-project zelden op de YAML. Het strandt doordat het gepland werd als tool-rollout in plaats van als organisatieverandering. De dure vraag is nooit “welk mesh”. De vraag is “hebben we besloten wie het netwerkgedrag bezit en hoe we dat aantonen”.

Precies daar begin ik in assessments. Niet bij de config. Bij de drie vragen die geen enkele tool voor jullie beantwoordt. De antwoorden blijven bij jullie, de ervaring om ze aan te scherpen breng ik mee.

Een tool dwingt af wat je vooraf hebt besloten. Ook je niet-beslissen.

Volgende week kijk ik bewust verder dan Istio. Linkerd, Ambient, de Envoy-resources naast elkaar, een eerlijke actuele vergelijking. Maar welk mesh is nooit de eerste vraag.

Welke beslissing hadden jullie voor jullie mesh-rollout graag eerder genomen?