Istio 1.7: Development Stays on Track Despite Controversies

Istio, an open-source service mesh used to manage microservices, has been the subject of ongoing dispute between Google and IBM. But the August release of Istio 1.7 indicates that the continuing controversy around the open source service mesh project's governance hasn't affected the project’s ongoing development. It also hasn't stopped IBM, which has been the most vocal opposition to Google's moves to keep the project under its thumb, from continuing to contribute to the project.

Istio is a service mesh used to manage microservices across a variety of infrastructures that include on-premises data centers, public clouds, Kubernetes containers, or in services running on virtual machines. It's supported and distributed by large vendors such as IBM, Red Hat, and VMware, numerous small startups, and public clouds like Amazon Web Services and Microsoft Azure. Built to take advantage of Envoy, the cloud native network proxy originally developed by Lyft, Istio reached its production-ready 1.0 release more than two years ago.

The latest Istio 1.7 release is a minor point release that pushes several new features into play and includes several alpha and beta features that point the way forward.

Most notable in the new features: Canary, Istio's way of letting DevOps teams deploy new applications or services without risk of bringing the entire system down, can now be applied to the tool for installing and upgrading Istio, Istio Operator.

Zack Butcher, an early Istio developer at Google who is now a founding engineer at Istio-focused company Tetrate, explained that Canary works by letting users deploy a new application or service on an extremely limited basis into order to detect and correct configuration problems before going into full deployment.

"The novel thing that shipped in 1.7 is finally that Istio can Canary its own control plane to the Envoys that are deployed in the mesh," Butcher told ITPro Today. "One of the biggest risks historically has been when I deploy a new version of Istio, I have to replace the old one, so if the upgrade doesn't go well, I have an outage. Now you can do that upgrade gradually and incrementally with the two side by side – say just send 5% of Envoys to the new one and if it's not good, pull it back."

Another completed new feature in Istio 1.7 eliminates a false start problem by delaying an application's start until after the start of its sidecar (i.e. a small utility container that is automatically deployed alongside containers and central to how Istio works). In the past, Butcher said, this created a "race situation," in which a containerized application might start and attempt to connect before the sidecar was up and running.

The new version also includes an enhancement for running virtual machines in Istio, which has always been possible but not quite straightforward. The goal is to eventually make a VM appear in the control plane as if it were just another container pod.

"This is about making a VM look more like a pod in Istio, adding base level support so that it's easy to model non-Kubernetes stuff in Istio," Butcher said. "This is a lot of the baseline groundwork for making VMs a real first-class citizen in terms of how Istio works, and how applications that are deployed on VMs can interact with all the other things in the mesh."

While this Istio 1.7 feature is considered as nearing "beta" stage, this doesn't necessarily mean it's not ready for production. Butcher said that the beta designation mainly points to the amount of use a feature has seen, as well as to a need for further testing before the feature can be dropped into the "stable" column.

"There is more opportunity to hit bugs potentially, but that's not really the main risk of beta," he said. "The main risk of beta mostly tends to be things like a bunch of the corner cases aren't well documented, so you might hit some corner cases that behave oddly because we don't have full testing yet."

Getting VMs as easy to handle as containers within the mesh is a top priority, as this will make it easier for enterprises dependent on monolithic legacy apps to begin taking advantage of modern cloud native technologies.

Another alpha feature in Istio 1.7, "central Istiod," was developed and contributed by IBM. When fully implemented, this feature will give users the option of configuring Istio so that all pods in an infrastructure can be controlled from a single control pane, instead of each pod having its own control pane, which is now the case.

IBM Involvement

IBM's involvement at this stage is interesting given Big Blue’s public opposition to Google’s approach to the project’s control and ownership.

In October, Google announced it wouldn't be contributing Istio to a foundation but would be keeping it in-house. This caused something of a stir among Istio developers, who were under the understanding that Google planned to eventually turn the project over to the Cloud Native Computing Foundation, which is also home to Kubernetes and Envoy, two technologies required by Istio.

Google then announced it had created an organization, the Open Usage Commons, to protect the Istio trademark along with the trademarks of two other Google led open source projects.

However, IBM had been a founding member of the current Istio project in 2017 when it agreed to open source its microservice fabric, Amalgam8, and merge it into Google's fledgling Istio code. In July, IBM published an entry on its developers’ blog reading, "there was an agreement that the project would be contributed to the CNCF when it was mature."

The Istio project is governed by a steering committee, which at the time consisted of seven seats, four of them controlled by Google. Since any action required only a majority vote, this put Google completely in the driver's seat.

This week the steering committee rules changed and the total number of seats expanded to 13. Under the new rules, nine of these seats will be based on code contribution (with merged pull requests being the criteria this year) with a minimum of three companies represented in these Contribution Seats.

The remaining four seats will be Community Seats, "for representatives from four different organizations who are not represented in the Contribution Seat allocation," according to Istio. The Community Seats will be open to anyone who has been an Istio member for at least a year, and will be chosen by Istio community members in an annual election.

According to the new rules, a cap has been put on the number of seats a single organization can hold so that no single vendor can have majority voting control over the project.

Will that be enough to satisfy Big Blue? Two days before the changes with Istio's Steering Committee were announced, IBM sent ITPro Today a statement from Jason McGee, VP and CTO of IBM Cloud:

"We are committed to further developing Istio and supporting the community, and there is a strong desire within the group of contributors to follow through on the original intent to donate the project to the CNCF where it can be maintained under a true structure of open governance," he said. "At the same time, we know the open source community moves quickly and we continue to contribute to making Istio the best service mesh technology and to enable our clients to realize enhanced security and productivity using it."