Service Mesh Field Report #1
When "Secure" Is Just a Gut Feeling
This is an English translation. The report was first published in German. Read the German original
A familiar scene in Istio audits: mTLS enabled everywhere, dashboards green, compliance boxes ticked.
Three hours later, it’s clear: nobody on the team can reliably say which services actually communicate over encrypted connections. The setup is “secure” - by gut feeling.
Not an isolated case. That’s the pattern.
Istio gets adopted to increase security and stability. In practice, I regularly see the opposite. Istio isn’t the problem. The rollout is: approached as a technical exercise, with no structural thinking behind it.
What that costs:
An engineer quits, and the knowledge of how incidents in the mesh even get analyzed leaves with them. Bus factor of 1 as a business risk that shows up in no risk register.
An auditor asks which traffic policies apply where. The answer takes two days and still isn’t conclusive.
In a production incident, time-to-recovery depends on whether “that one person” happens to be reachable.
The actual problem is rarely the configuration. It’s the lack of clarity about who really owns the network behavior in the cluster, which rules are binding (and not merely documented), and whether an incident can be analyzed reproducibly or depends on individual people.
Without these foundations, Istio becomes riskier with every new service instead of safer.
The question is not whether Istio is configured correctly. The question is whether the system behind it was designed to scale - or whether you are certifying technical debt right now.
Which of these symptoms do you recognize in your setup? I’ll turn your answers into the topics for the coming weeks.
Join the discussion on LinkedIn (in German)
From the field, for the field
Every report is built on patterns from real mesh setups. If one of them sounds like your cluster, an architecture call is the place to look at it together.
Request an architecture call