Istio: The Service Mesh That Spent a Decade Deleting Its Own Architecture

A private Google repo, before anyone had heard the name

The repository that would become istio/istio was created on November 18, 2016 — and its root commit is a literal Initial commit from Sven Mawson, with none of today's branding. Six months of private development followed before the project surfaced publicly. What was being built in that silence is unusually well documented, because the team explained it themselves a year later: Istio was the open-source rebirth of a Google-internal system. As the December 2017 Mixer design post puts it, Google's internal API and service management system was fronting "the world's biggest services (Google Maps, YouTube, Gmail, etc.) and sustains a peak rate of hundreds of millions of QPS." In 2014 Google replaced the "centralized fleet of fairly heavy proxies" with a lean distributed sidecar proxy plus sharded control-plane intermediaries, "saving in the process millions of dollars a month in ops costs." Then the line that explains everything: "Look familiar? Of course: it's just like Istio! Istio was conceived as a second generation of this distributed proxy architecture." IBM brought the other half of the founding DNA — per the launch announcement, "Google and IBM have extensive experience with these large scale microservices in their own applications and with their enterprise customers in sensitive/regulated environments."

GlueCon, May 24, 2017: the 0.1 that defined a category

The launch announcement reads today like a time capsule of every promise and every future apology: "Google, IBM, and Lyft are proud to announce the first public release of Istio: an open source project that provides a uniform way to connect, secure, manage and monitor microservices." The proxy underneath was already production-hardened — Lyft "developed Envoy to address their internal operability challenges" and had run "more than 100 services spanning 10,000 VMs, processing 2M requests/second" for over a year before open-sourcing it. The launch was Kubernetes-only, targeted at what the post calls the "solution: service mesh" — transparently injecting infrastructure into the network path "without requiring any changes to application code" — with mutual TLS pitched as "secure by default," aligned with "the emerging SPIFFE specification." Two details deserve a slow read: the cadence promise ("we plan to have major new releases every 3 months" — they would miss it), and the fact that the name is just the Greek word for "sail" — the helmsman's Helm steers, the sail catches the wind. Coverage was immediate; the TechCrunch launch story and the Google Cloud blog both landed the same day, and 0.2 followed on October 10, 2017 with the mechanics that still define mesh onboarding today — automated sidecar injection, TCP-level policy, virtual machine workloads, and the short-lived ambition to "run outside Kubernetes, leveraging Consul/Nomad or Eureka."

But the sentence that matters most for everything that follows was written in March 2020, in the project's own istiod announcement: "Istio's control plane is, itself, a modern, cloud-native application. Thus, it was built from the start as a set of microservices." The tool that existed to manage your microservices was itself deployed as microservices — dogfooding as a founding architectural decision. Hold that thought.

The architecture of record: six control planes and a per-request gRPC call

To understand every crisis that followed, you need the 1.0-era component census. The control plane was deployed as separate microservices — Pilot (xDS configuration for the data plane), Galley (config validation), Citadel (the CA that minted mTLS identities), the sidecar injector (a mutating webhook), and Mixer, split into a policy deployment and a telemetry deployment. The data plane was an Envoy sidecar beside every workload. And the request path had a property that every benchmark and every post-mortem circles back to. In the project's own words: "The Envoy sidecar logically calls Mixer before each request to perform precondition checks, and after each request to report telemetry... Whereas precondition checks are synchronous to request processing, telemetry reports are done asynchronously with a fire-and-forget pattern." Policy — authz, quotas, admission-style checks — was a synchronous, cacheable, cross-network call on the critical path of every single request in the mesh.

The project saw the risk coming and defended it publicly, in the December 2017 post titled "Mixer and the myth of the single point of failure": Mixer is stateless, designed for "> 99.999% uptime for any individual Mixer instance," and — the claim worth preserving for the post-mortem — "the surprising fact Mixer actually increases overall mesh availability and reduces average request latency," because its second-level caches shielded both proxies and backends. The 1.0 release notes leaned into the same design: "Policy Check Cache. Mixer now features a large level 2 cache for policy checks," and out-of-process adapters were now "the recommended approach moving forward." The security story was a similar mix of promise and ceremony — mTLS was "secure by default" in the launch deck, but the actual default lock-out was PERMISSIVE mode, and tightening it was (and remains) your job:

Crisis I: the benchmarks wrote the post-mortem before the project did

The first data point that the 1.0 architecture was the bottleneck came from Istio itself. The 1.1 release slipped to March 19, 2019 — 7.5 months after 1.0, the longest gap between minors in the project's history — and the same day the team published Architecting Istio 1.1 for Performance: versus 1.0, the new version delivered "up to 30% reduction in application average latency," "up to 40% faster service startup times," "up to 90% reduction in Pilot CPU usage in a large mesh," and "up to 50% reduction in Pilot memory usage." A 90% control-plane CPU reduction one minor version later is not an optimization — it is a diagnosis.

Two months later the independent numbers landed, and they were worse. Kinvolk's May 2019 benchmark measured Istio 1.1.6 against Linkerd 2.3 on real clusters; Linkerd's write-up of the results became the most-quoted performance document in mesh history. At 500rps, Istio's p99 was 643ms against Linkerd's 6.7ms — roughly 100x — and Istio consumed 5.5x the memory (4,307MB vs 517MB across data-plane proxies, 47MB vs 5.7MB per proxy). At 600rps Istio simply could not hold the load: p99 latency of 4.4 minutes, a median of 17.6 seconds, and an effective throughput of ~568rps. To Istio's credit, its team engaged with the methodology; Kinvolk re-ran the tests with Istio's tuning feedback, and the results stood up — Istio's p99 was still 26x to 59x Linkerd's.

Methodology fights flared for years — the Kinvolk numbers were produced before Istio's tuning guide existed, and third parties later published results where Istio's Envoy used less CPU than Linkerd's Rust proxy at high endpoint counts. But the durable finding survived every re-run: the 2021 benchmark ran against Istio 1.10, two majors after Mixer was deleted, and the data plane still cost 8x Linkerd's memory while the control plane still cost 2.5x. The proxy bet itself — full Envoy beside every pod — was the remaining gap. File that away, because in 2022 Istio would write its new data plane in Rust.

Crisis II: the trademark years — promised to the CNCF at inception, delivered five years late

The governance crisis is the one part of the Istio story where the receipts were published by the participants themselves. On July 8, 2020, Google announced it was transferring the Istio trademarks to a brand-new organization it had created for the purpose, the Open Usage Commons — framed as "neutral, independent oversight of the marks" after "the historic ownership has caused some confusion... at times this confusion has been a barrier to community growth." The problem was that virtually nobody outside Google wanted a Google-run alternative to the CNCF: as InfoQ reported at the time, the move covered Istio, Angular, and Gerrit, and the community's reaction was immediate. IBM's Jason McGee — whose company co-founded Istio — called it "disappointing because it doesn't live up to the community's expectation for open governance," and put the founding deal on the record: "At the project's inception, there was an agreement that the project would be contributed to the CNCF when it was mature. Google should reconsider their original commitment and bring Istio to the CNCF." IBM's Todd Moore was blunter: "IBM took Google at good faith that our agreement to take the project to the CNCF would be honored... This turned out to not be the case, but that has been put right."

The reversal took two more years. On April 25, 2022 the steering committee applied to join the CNCF — "It is almost 5 years since Google, IBM and Lyft launched Istio 0.1 in May 2017... we think it's time to unite the premier Cloud Native stack under a single umbrella" — and Google's Chen Goldberg framed the obvious: "Istio is the last major component of organizations' Kubernetes ecosystem to sit outside of the CNCF." Per CNCF DevStats, Google had made "over half of all contributions" and "two-thirds of the commits." The TOC voted to accept Istio as incubating on September 28, 2022, and on July 12, 2023 — less than ten months later — Istio graduated, which Tetrate called "the fastest project to do so in CNCF history." The graduation post's own claims are worth preserving: "the third most active CNCF project in terms of PRs, and with support from over 20 vendors and dozens of contributing companies, there is simply no better choice for a service mesh" — published just after Microsoft archived its own Open Service Mesh and joined Istio instead.

Pivot I: "embracing the monolith" — 1.5, the self-surgery

In March 2020 Istio performed the same operation on itself that it had been prescribing for everyone else's architecture. The istiod announcement (Craig Box, Google) is one of the most honest architecture posts any major project has published. Microservices are a good pattern, it opens, "when they map services to disparate teams that deliver them, or when the value of independent rollout and the value of independent scale are greater than the cost of orchestration. We regularly talk to customers and teams running Istio in the real world, and they told us that none of these were the case for the Istio control plane." Then the five assumptions, dismantled one by one: different languages (all control-plane components were Go; only Envoy was C++); independent teams (in the "vast majority" of installs one team runs everything); independent versions ("We have never tested or supported running different versions of (for example) Citadel and Pilot"); independent scaling (costs dominated by the xDS API); and security boundaries (Pilot, Citadel, and the injector "hold nearly equivalent permissions," all in one namespace). The conclusion: "Microservices have to be right sized, and we believe we have found the right size for Istio."

The 1.5 release notes named the operation — "we are dramatically simplifying the experience of installing, running, and upgrading Istio by 'embracing the monolith'" — and deleted Mixer in the same release, replacing its adapter model with WebAssembly extensions executed inside Envoy ("eliminating the need for running a Mixer component separately"). The before/after numbers are the post-mortem the 2017 design post never wrote: with Telemetry v2 in-proxy and Mixer gone, "90th percentile latency has been reduced from 7ms to 3.3 ms," and "the elimination of Mixer has reduced total CPU consumption by 50% to 0.55 vCPUs per 1,000 requests per second." Half the mesh's CPU and half its p90 latency had been its own architecture. 1.6 ("Simplify, simplify, simplify") finished the consolidation that May. The design doc's subtext, quoted by Red Hat's Christian Posta, had said it all a year earlier: "Complexity is the root of all evil or: How I Learned to Stop Worrying and Love the Monolith."

Pivot II: the sidecar betrayed — ambient mode

The sidecar pattern had a tax, and everyone paid it: two L7 processing passes per connection (one proxy out, one proxy in), a proxy's worth of reserved CPU and memory beside every workload, pods that restart when the mesh upgrades, and applications that break when a sidecar is added. The ambient GA post lists them without flinching: "sidecars can break applications after they are added, the large CPU and memory requirement for a proxy with every workload, and the inconvenience of needing to restart application pods with every new Istio release." The answer, announced September 7, 2022 — by a Google-and-Solo.io team — was to split the data plane in two: ztunnel, "a shared agent, running on each node... a zero-trust tunnel," that "performs no L7 processing on workload traffic, making it significantly leaner than sidecars"; and optional waypoint proxies — plain Envoy pods, per namespace, "auto-scaled... to the real time traffic demand of the namespaces they serve, not the maximum worst-case load operators expect." The tunnel between them is HBONE — HTTP CONNECT over mTLS, with FIPS builds by default. The security rationale for keeping L7 off the node is worth keeping: "Envoy is not inherently multi-tenant... By strictly limiting to L4 processing, we reduce the vulnerability surface area significantly."

The ztunnel repo appeared on October 19, 2022, and it is written in Rust — the same language choice Linkerd made in 2018, which the benchmarks had spent two years waving at Istio. The project's own ztunnel post describes "a purpose-built per-node proxy... responsible for securely connecting and authenticating workloads... without terminating workload HTTP traffic or parsing workload HTTP headers." Then the phase march: Alpha in 1.18 (June 2023), Beta in 1.22 (May 13, 2024), GA in 1.24 — November 7, 2024, twenty-six months after the announcement. Asked at announcement time whether this was the end of the sidecar, the post answered "Definitely not" — and interop between the modes remains a design invariant. What interop does not require is ceremony: enrollment is one namespace label, and — per the getting-started guide — "there is no need to restart or redeploy anything."

Pivot III: the operator pattern — evangelized, deprecated, outsourced

The install story is a parable about the operator pattern in miniature. In November 2019, Google and IBM introduced the Istio Operator — "Kubernetes operators provide a pattern for encoding human operational knowledge in software... Istio is a natural candidate for an automated operator as it is challenging to administer." Five years later the same pattern was retired by a different company: on August 14, 2024, Microsoft's Mitch Connors announced the in-cluster operator deprecated in 1.23 and removed in 1.24, noting that "Based on recent polls, we expect that this will affect fewer than 10% of Istio users" and recommending Helm as the migration target — "Because of Helm's popularity within the platform engineering ecosystem, we recommend most users migrate to Helm... istioctl install is based on Helm templates, and future versions may integrate deeper with Helm. Helm installs can also be managed with GitOps tools like Flux or Argo CD." Two ecosystem forks survived the removal: the Classic Operator Controller (the original controller's code and API, maintained outside Istio core) and Red Hat's Sail Operator, which went GA on April 3, 2025 with Istio, IstioRevision, IstioRevisionTag, IstioCNI and ZTunnel CRDs, two update strategies (InPlace and RevisionBased), and ambient support as an Alpha feature. The lesson underneath the churn is the post's own: the install path the project now blesses is the one your GitOps controller already reconciles (see our Argo CD and Flux tales).

Where does that decade of self-correction leave Istio this week? Stable on release mechanics: 1.31.0 (August 31, 2026) is the current major, patched through 1.31.4, with 1.32.0 at rc.2 as of November 6 — release candidates landing the same night as the security patches. On APIs: the core networking and security resources (VirtualService, DestinationRule, Gateway, PeerAuthentication and friends) graduated from v1beta1 to v1 in May 2024, Gateway API mesh support went Stable in the same release, and 1.30 added the TrafficExtension API — one extension surface for Wasm and Lua across sidecars, gateways, and waypoints, retiring the EnvoyFilter escape hatch. On performance: the project now publishes its own numbers against the eBPF competition, and wins some of them — the ambient performance post claims "the highest-bandwidth way to achieve a secure zero-trust network in Kubernetes," with ztunnel throughput up 75% across four releases on rustls and AWS-LC, and the October 2024 Cilium comparison — run at 1,000 nodes and 11,000 cores on AKS — found Istio delivering 56% more queries at 20% lower tail latency and 2,178 vs 1,815 queries per core, while conceding that Cilium's CPU was 30% lower if you ignore in-kernel encryption costs, and that "most defense-in-depth strategies will need to make use of both NetworkPolicy and TLS-based policy."

On AI: the newest bet is real and named. In July 2025, engineers from Google, Microsoft, and Red Hat shipped Istio support for the Kubernetes Gateway API Inference Extension — model-aware, KV-cache-aware, LoRA-aware routing for LLM inference, where "traditional load balancers lack the context" to route around queue depth, adapter load time, and cache-hit state. It plugs into the mesh without giving up "mutual TLS, access policies, and distributed tracing." Next week's Istio Day at KubeCon NA (Salt Lake City, November 11, 2026) is a preview of the roadmap's center of gravity: "AI-Aware Traffic Management: Scaling Inference with Istio Ambient Mesh," "The Sidecar-to-Ambient Migration Nobody Warned Us About," and "Translating Mesh Identity into MCP Impersonation: Governing AI Agent Identities with Istio" — the mesh positioning itself as the identity and traffic layer for AI agents, not just microservices.

On security: the cadence is industrial — nine security bulletins in 2026 alone — and the latest one is a reminder that every era of the architecture is still in production somewhere. ISTIO-SECURITY-2026-009 (November 6, 2026, patched the same day in 1.31.4 and 1.30.8) shipped eight CVEs: an ambient-mode port-level STRICT PeerAuthentication skipped under permissive workload modes (CVSS 8.2 — plaintext reaching a port that required mTLS); a mesh-identity-triggered istiod crash loop (7.7 — any workload could take down the whole mesh's control plane with a malformed debug request); a conntrack-reuse sidecar traffic bypass (7.4); a ztunnel panic that dropped every stream multiplexed on an inbound HBONE connection (6.5); and AuthorizationPolicy host-header and ipBlocks bypasses that failed open on ambient waypoints (6.5 / 5.6). The bulletin's own summary reads like the project's biography: "ambient mode authorization and mTLS bypasses, sidecar traffic interception bypass, and istiod and ztunnel denial of service issues" — every architectural era in one advisory. The audit trail is respectable — three external audits since 2021 (most recently Trail of Bits on ztunnel, April 2025: "passes with flying colors") — but the honest read is that a mesh is a security product, and this one ships exploitable bypasses often enough that your patch SLA matters more than your architecture diagrams.

Istio's corporate story is legible in the bylines of its own blog. The founding generation is Google (Sven Mawson's initial commit; Craig Box and John Howard writing the era-defining posts, Louis Ryan authoring the istiod design doc) and IBM (Frank Budinsky co-authoring the operator; the 1.1 performance study authored by IBM and Google engineers together). The CNCF years broadened the bench in a way the trademark fight made inevitable: the ambient announcement was co-authored by Google and Solo.io engineers — with Lin Sun and Idit Levine at Solo.io carrying the beta and GA milestones; the operator deprecation was announced by Microsoft's Mitch Connors, whose company had just archived its own Open Service Mesh to join Istio; Red Hat shipped the Sail Operator and co-authored the inference-extension support with Google and Microsoft; the TrafficExtension API post came from Docusign. Tetrate — founded in 2018 by Varun Talwar, Istio's founding product manager, and Zack Butcher — and Solo.io built the commercial ecosystem, and today's graduation-era claim still holds: "the third most active CNCF project in terms of PRs," backed by 20-plus vendors. The numbers from the repo itself: 26,864 commits on main, 364 contributors, 38,493 stars, and annual steering committee and TOC elections that no single company dominates — the governance Google withheld in 2017 and finally conceded in 2022.

One dependency deserves its own line: Envoy. Istio's entire data plane is a Lyft project that went its own way — accepted to the CNCF in September 2017, graduated November 28, 2018 (the third project after Kubernetes and Prometheus), now the L7 engine across much of the mesh and gateway landscape (see our Envoy 1.40 release coverage). The trademark war was only ever about the control plane; the data plane had been neutral and graduated the whole time. For the eBPF counter-narrative — Cilium's in-kernel L4 and the mesh it ships — see our Cilium tale and Cilium eBPF service mesh guide.

The verdict on Istio in late 2026 is that it is the only service mesh bet that survived contact with production, and it survived by being wrong in public — the 1.5 monolith post, the Mixer numbers, the operator deprecation, and the ambient sidecar retreat are all self-authored confessions, each one published with benchmarks. The 2025–2026 roadmap says the next chapter plainly: parity between sidecar and ambient mode, "a supported path for sidecar users to migrate to the ambient data plane when they are ready," and AI-era traffic management (inference routing, agent identity) as the growth surface. The project that spent 2017–2019 being the most complicated thing in your cluster is now competing on being the simplest way to get zero-trust — one namespace label, no restarts — and, unusually, on raw bandwidth: the highest-throughput encrypted overlay measured in the ecosystem.

Who should skip it?

• Teams that only need ingress or API gateway behavior. If you don't need east-west mTLS, L7 authz between services, or mesh telemetry, a Gateway API implementation without a mesh is strictly cheaper to run (see our Gateway API vs Ingress guide). A mesh you don't need is an outage domain you don't need.
• Clusters already standardized on Cilium eBPF networking. Running both means two data planes, two upgrade cadences, and two security bulletins — and the KubeCon NA main track runs a whole session on exactly that coexistence — "Managing Network Security in Multi-Tenant Environments with Istio and Cilium." Defense in depth is a valid reason; inertia is not.
• Small estates. Ambient lowered the mesh tax; it did not abolish it. A dozen services with no compliance driver do not need an identity plane — mutual TLS between pods nobody can reach is theater.
• Sidecar estates that are drifting. The roadmap promises parity and a supported migration path, but the KubeCon session title — "The Sidecar-to-Ambient Migration Nobody Warned Us About" — is the community telling you migration is real work. Decide deliberately; don't let two modes coexist for years.
• Anyone without a patch SLA. Nine security bulletins in 2026, including mTLS bypasses and control-plane crash loops reachable by any mesh identity. A mesh you cannot patch within a week is an amplification layer for your next incident.

For everyone else: Istio in 2026 is the mature choice it spent a decade becoming — ambient mode for the sidecar tax, v1 APIs for the YAML estate, Gateway API for the future, and a governance model that finally matches the size of the footprint. Ten years ago it promised to run your microservices; next week at KubeCon it will argue it should run your AI agents. Given its record of deleting its own mistakes, that is a bet worth taking seriously — and auditing annually.