Konstantin Emelyanov - Fotolia

Istio service mesh revamp may ease use, or sow confusion

Istio 1.5 reworks a microservices-based control plane into a monolith as the service mesh project seeks to simplify management and improve performance.

A new version of the Istio service mesh rolled out this week introduces significant changes to the project's architecture but leaves key questions about the project's future direction unanswered.

Istio service mesh version 1.5 introduces Istiod, a monolithic package that combines what had been four separate control plane microservices into one utility. These include a sidecar injector service; the Pilot service, which handled sidecar proxy configuration; Citadel, which provided security functions, including a certificate authority; and Galley, which performed validation.

A fifth set of modules and plugins provided by the Mixer telemetry collection service within the Istio control plane in previous versions will shift to a new set of plugins for the Envoy sidecar with version 1.5.

Istio, an open source project founded by Google, IBM and Lyft, has developed a popular approach to service mesh, a network architecture that collects monitoring data and enforces fine-grained policies in complex microservices environments. It boasts powerful backers that now also include Red Hat, but has yet to achieve the same dominance over the cloud-native software market as Kubernetes container orchestration. In fact, Istio rival Linkerd has been profiting from its competitor's reputation for cumbersome management for at least a year, and steadily closing Istio's early lead with support for features such as mutual TLS (mTLS).

Team leads at IBM want to see Istio enjoy the same ubiquity as Kubernetes, and this desire informed the significant changes in Istio 1.5. Removing the Mixer service, which had been associated with performance bottlenecks in earlier versions, is also intended to improve Istio's control plane performance and boost its appeal to a wider audience.

"We want Istio to be like Kubernetes -- 'boring' infrastructure for microservices," said Lin Sun, IBM's technical lead for Istio. "That's our high-priority goal for 2020: To be able to move services to service mesh faster without [requiring] as many configuration changes to microservices."

In the short term, the change is likely to cause tumult in the industry, which is still in the early stages of service mesh adoption, analysts said.

There is irony in [adding] a monolith for a service mesh whose purpose is to discover, connect and do traffic management for microservices.
Brad CasemoreAnalyst, IDC

"There is irony in [adding] a monolith for a service mesh whose purpose is to discover, connect and do traffic management for microservices," said Brad Casemore, analyst at IDC. "It may cause some folks to say, 'If they were off on their assumptions about a microservices-based architecture for the service mesh, can I be confident they'll manage to get it right this time?'"

Brad CasemoreBrad Casemore

It will take until the first version 1.5 fix pack for all of Istiod's features to be supported in multi-cluster environments, where the newly unified Istiod daemon doesn't yet support Citadel's certificate authority or the sidecar injection service*. Users at KubeCon who intended to deploy Tiller-less Helm v3 with newer versions of Istio will also have to wait for future releases, as the finer details of Helm v3 support under Istiod have yet to be finalized.

IBM's Sun said she doesn't expect many technical hurdles to implementing these features by the next release, but Istio's core audience is accustomed to the microservices architecture. These early adopters may chafe at the sweeping changes to the platform, particularly if they must wait too long for the new architecture to match the capabilities of earlier versions, Casemore warned.

"Simplified management will appeal to shops whose platform teams are not as adept [as early adopters], but I wonder if it sends a mixed message," he said.

Another potential challenge for the next few versions of Istio service mesh lies in the transition to the new Envoy-based mechanism for integrating third-party extensions to the project. Documentation for the Mixer adapter conversion process to Envoy plugins is still being developed, Sun said. The success of this transition will dictate whether third-party makers of network infrastructure products such as application delivery and ingress controllers continue to support Istio service mesh or switch their loyalties to a competing alternative, another possible blow to Istio's market momentum.  

The project also faces broader, longer-term questions about its governance -- namely, whether it will be donated to a foundation such as the CNCF by Google, as Kubernetes was.

Istio’s Steering Committee, which includes IBM's Sun, is holding discussions about reworking the project's charter to widen the steering committee to include vendors and users beyond today's members from Google, IBM and Red Hat*. Sun declined to share any further specific details about the charter changes. Donating Istio to a foundation remains non-negotiable for now, she said.

"It's something we don't like, but we spent a lot of time within IBM on the new steering charter, and most of our proposals were accepted," she added.

* Clarifying details added after initial publication.

Dig Deeper on Systems automation and orchestration