A familiar programme still opens in too many regulated technology organisations. A platform team is stood up to “own Kubernetes”. Another workstream is funded to “industrialise Istio”. The roadmap stretches across fiscal years. Boards hear about maturity models, golden paths and control-plane ownership while product teams wait for namespaces, certificates and east-west policy that competitors already consume as a product. The uncomfortable truth is not that Istio is weak. It is that the market has already productised the same capability and you are paying for a rebuild that no longer buys differentiation.
Kubernetes ceased to be frontier technology years ago. The CNCF’s 2025 Annual Survey reported that 82 per cent of organisations using containers run Kubernetes in production. Service mesh followed the same arc: from pioneering sidecar estates to CNCF-graduated projects, ambient and eBPF data planes, enterprise distributions and hyperscaler add-ons. Treating either as a multi-year moonshot is no longer prudence. It is an expensive habit.
The problem: commodity plumbing treated as a moonshot
Istio remains a capable mesh. It graduated in the CNCF in July 2023. Ambient mode reached general availability with Istio 1.24 in November 2024, replacing the per-pod Envoy sidecar tax with a node-level ztunnel for Layer 4 and optional waypoint proxies for Layer 7. None of that settles the organisational question. Capability does not oblige you to reinvent the operating model. Many firms still stand up large platform programmes to rebuild what Google Cloud Service Mesh (formerly Anthos Service Mesh), the AKS Istio add-on, commercial multi-zone meshes and open-source alternatives already ship with support contracts, upgrade paths and documented blast-radius controls.
The cost is rarely the open-source licence line, because there often is not one. The cost is years of platform engineering, on-call theatres around upgrades, certificate and identity glue and delayed product work while the mesh “matures”. Independent commentary on DIY internal developer platforms repeatedly finds that operational headcount and opportunity cost dwarf compute. The New Stack’s analysis of build-your-own platforms put full enterprise platform estates in the tens of millions of dollars a year when payroll is counted honestly across cost centres. Even directional figures matter less than the pattern: you are spending scarce engineers on plumbing the industry already sells.
Why Istio became the default and why that no longer settles the question
Istio earned its early lead for clear reasons. Envoy as the data plane, rich Layer 7 policy and gravity from Google and IBM made it the default answer in conference corridors and architecture reviews. For a stretch, choosing Istio looked like choosing the market itself. That history still matters when you hire and when you evaluate managed offerings built on the same APIs. It does not mean every bank should fund a permanent Istio construction programme.
Ambient mode reduced the sidecar tax that made Istio notorious for memory and upgrade churn. Official Istio performance material and vendor benchmarks show material resource savings when L4 runs in ztunnel and L7 is paid only where waypoints are needed. That is a real improvement. It does not remove control-plane complexity, multi-cluster federation work, policy authoring discipline or the need for people who understand failure modes when traffic policy goes wrong at 2 a.m. A mesh is now a capability you consume. Inventing one inside the firm is optional; for most regulated multi-cloud estates it is the wrong default.
The market has already built the alternatives
The open-source shelf is crowded in a useful way. Istio (sidecar and ambient), Linkerd with its Rust micro-proxy, Cilium’s eBPF-based service mesh, HashiCorp Consul and Kuma all address connectivity, mutual TLS and traffic policy with different trade-offs. Linkerd remains the simplicity benchmark for Kubernetes-only estates that want automatic mTLS and golden-signal metrics with a narrow operating surface. Cilium is often the rational choice when it is already the cluster CNI and eBPF can cover identity, policy and observability without a second control plane. Consul still fits shops deep in the HashiCorp stack with multi-datacentre needs.
Enterprise and multi-zone products sit on top of that substrate. Kong Mesh builds on Kuma and Envoy with multi-zone control, FIPS 140-2 support via Envoy’s BoringSSL mode, embedded Open Policy Agent (MeshOPA) so Rego travels in the data plane rather than as yet another sidecar farm, audit-oriented controls and alignment with Kong Gateway for operators who want north-south and east-west policy under one vendor relationship. That combination maps cleanly to hybrid estates that mix Kubernetes with VMs and need a supported global control plane across zones and clouds.
Hyperscalers productised Istio operations as well. Google Cloud Service Mesh manages the control-plane lifecycle on GKE fleets. Microsoft’s Istio-based service mesh add-on for AKS provides tested version compatibility, managed control-plane scaling and official Azure support. On Amazon EKS the pattern is more marketplace-led: add-ons and distributions from specialist vendors rather than a single first-party managed Istio control plane identical to Azure’s. “Widely available” for a regulated multi-cloud estate now means you can buy supported mesh capability on each major cloud, consume open source with commercial support, or run a multi-zone product that spans Kubernetes and VMs without pretending every workload lives in one greenfield cluster.
How to read the options without a beauty contest
Start with the data plane. Sidecar Envoy remains the mature L7 workhorse. Ambient mode and Cilium’s eBPF path cut per-pod overhead. Linkerd’s Rust proxy keeps the sidecar model but narrows the binary and the feature surface. None is universally superior; each changes memory, upgrade disruption and how much L7 policy you can express without bolting on extras.
Then scope. Kubernetes-only meshes (classic Linkerd, many ambient Istio deployments, Cilium-on-cluster) are fine when the estate truly is containers on Kubernetes. Multi-zone products such as Kong Mesh on Kuma matter when you still run VMs, need zone-spanning identity and refuse to run a different mesh story on every cloud. Hyperscaler-managed Istio is excellent when you are standardised on one cloud and want Microsoft or Google to own control-plane upgrades. It is a weaker answer when the strategy deck says multi-cloud and the audit team asks how the same policy graph is evidenced on Azure, AWS and private Kubernetes.
Operations and governance finish the frame. Ask how many platform engineers the upgrade cadence and blast radius demand. Ask whether mutual TLS, workload identity, policy-as-code and an audit trail arrive as product features or as a two-year internal project. Commercial support is not a moral failing. For regulated operators it is how you convert open-source capability into something you can defend in front of an auditor when a control fails.
What actually fits banks and insurers
Hybrid and multi-cloud is the norm, not a future state. Workloads sit on more than one hyperscaler, plus private Kubernetes and a stubborn population of VMs that will not vanish because a platform slide said “cloud native”. Zero-trust east-west traffic, cryptographic workload identity and evidence for auditors are table stakes. Greenfield single-cluster purity is a fantasy that burns budget.
That pattern favours a supported control plane that spans zones over a single-cloud mesh you must re-explain on every other platform. Kong Mesh and similar multi-zone products map to that reality: policy and identity that travel across Kubernetes and VMs, FIPS-oriented crypto options, embedded OPA for authorisation evidence and a commercial support path. They are not magic. They are plumbing bought once rather than rebuilt per cloud.
Local choices still win in bounded cases. Linkerd is often better when the problem is a pure Kubernetes estate, the team wants the smallest day-two burden and Buoyant Enterprise support is budgeted (stable release artefacts for larger organisations moved behind that subscription model from early 2024). Cilium remains the better local choice when it is already the CNI and eBPF covers the required mTLS and policy depth without introducing Istio’s full surface. A hyperscaler-managed Istio add-on remains the better local choice when you are deep on GKE or AKS, happy for that provider to own the control plane and not trying to run the same mesh control story unchanged across three clouds. Fair selection beats brand loyalty.
The hidden bill for building Kubernetes and Istio from scratch
Platform headcount is the visible line. On-call rotations, upgrade theatres, certificate authority operations, sidecar or ambient rollout failures and the permanent backlog of “make the mesh safer” tickets are the quieter ones. Industry write-ups on Istio total cost of ownership consistently find that operational overhead outruns sidecar compute for medium estates; the expensive part is people who understand the system when it misbehaves. DIY Kubernetes platforms amplify the same arithmetic across networking, ingress, observability and security tooling.
Opportunity cost is worse. Every engineer debugging injection failures or drafting yet another internal Istio operator is not shipping risk models, customer journeys, claims automation or resilience work that moves the P&L. The New Stack’s DIY platform critique puts the velocity gap bluntly: vendors keep shipping while your build programme chases a moving target, often falling a year or more behind commercial roadmaps. The lock-in that hurts most is not a vendor logo. It is lock-in to your own unfinished platform: config, runbooks and tribal knowledge that only work inside a stack nobody else will support when the original team leaves.
Set the developers free
Buy commodity Kubernetes where a managed or supported distribution is good enough. Buy a supported mesh that matches estate shape: multi-zone products such as Kong Mesh when hybrid and multi-cloud policy must be applied once; Linkerd, Cilium or a hyperscaler-managed Istio when the local boundary is clear and narrower. Put engineering time into policy design, data classification, customer journeys and the resilience of the business, not into reinventing Envoy configuration management.
A CTO or CIO can take a short set of decisions this quarter. First, declare Kubernetes and service mesh commodity plumbing in the technology strategy, with an explicit ban on new multi-year rebuild programmes without a written exception. Second, inventory where mesh is required for zero-trust east-west and where it is cargo cult. Third, select a default: multi-zone supported mesh for cross-cloud and VM-mixed domains; managed Istio or Linkerd or Cilium for bounded Kubernetes islands. Fourth, fund policy-as-code, identity and audit evidence as the platform product, not “more Istio YAML”. Fifth, measure platform success as time-to-governed workload and policy restore across clouds, not as lines of internal control-plane code.
Stop rebuilding the mesh. The industry already sells the pipes. Banks and insurers that buy them will spend the next years on problems that actually differentiate. Those that keep treating Istio and Kubernetes as moonshots will keep staffing the plumbing and calling it strategy.