After years of community bickering, bug fixing and governance debate, Google has finally proposed that Istio become a Cloud Native Community Foundation (CNCF) member, giving the five-year-old open source service mesh project a vendor-neutral and open governance home — if it is accepted by the CNCF (part of the Linux Foundation and home to 16 graduated open source projects, 34 incubating projects, and 68 sandbox projects.)
The move may yet push Istio more firmly into the developer mainstream — the tooling was developed to connect, manage, and secure networks of different microservices running in a Kubernetes cluster.
What is Istio? Read on…
The decision was welcomed by Istio contributor IBM, which in 2020 had publicly lamented Google’s failure to transfer governance to the CNCF (it instead transferred Istio trademarks to a newly formed “Open Usage Commons”), with IBM calling on Google at the time to rethink the move, saying that “the best way to manage key open source projects such as Istio is with true open governance, under the auspices of a reputable organization with a level playing field for all contributors, transparency for users, and vendor-neutral management of the license and trademarks…”
Such open source community bickering over the governance of a project — that whilst attracting considerable attention has remained what one experienced cloud-native developer described to The Stack recently as “still fairly avante garde for most” — may not be hugely relevant for those outside the community, but the move by Google this week does suggest that it feels Istio is now mature and adoption may pick up.
What is Istio?
So, what is Istio? The project describes itself as providing a “uniform, efficient and transparent way to secure, connect, and monitor services in cloud native applications. It supports zero-trust networking, policy enforcement, traffic management, load balancing, and monitoring; all without requiring applications to be rewritten.
“Istio extends Kubernetes to establish a configurable, application-aware network leveraging the Envoy service proxy. It can manage cloud native and traditional workloads alike, supporting from single-cluster to complex multi-network deployments” its own documentation says. If that sounds a little garbled, here’s a simple version.
In a world stumbling ever deeper towards “cloud native” applications (arguably a misnomer, let’s just say containerised applications that abstract applications away from underlying platforms and make them, in theory, more portable) Kubernetes lets users deploy containers to the hosts powering them and then scale up or down their workloads, but fundamentally does not provide robust routing, traffic rules, or strong monitoring or debugging tools.
Managing a tonne of microservices is hard and why some people still favour monoliths.
That’s where Istio comes in to help. It layers on top of Kubernetes, adding “sidecar” containers that help direct traffic and monitor the interactions between components. While the Istion control plane runs on Kubernetes (you can’t escape it if you want Istio), users can add applications deployed in that cluster to your “mesh”, extend the mesh to other clusters, or even connect VMs or other endpoints running outside of Kubernetes.
Istio implementations are built in to Kubernetes services from: Red Hat, Cisco, Huawei, SAP and many others. Among its founding members is Solo, whose founder and CEO Idit Levine noted this week that “the explosion in adoption of enterprise service mesh technologies proves the shift to microservices is accelerating.
“In the same way Kubernetes has become the industry standard for container orchestration, Istio has become the Kubernetes of service mesh. In joining the CNCF, Istio became the de facto standard in this space. Our Gloo Mesh customers’ are already some of the largest Istio environments, and they trust Istio to network their business-critical workloads. This news will encourage others to follow suit” Levine added in an emailed comment.
Used Istio in production? Think the bugs have been ironed out? Favour a different open source tooling? Views on the CNCF move? We’d welcome your comments, just pop us an email here.