The Istio community this week unveiled the latest updates to the service mesh platform at a time when the space it was expected to dominate continues to search for direction.

From a high level, the Istio 1.8 update includes features that make Istio easier to upgrade, clearer information about maturity of each feature, better documentation, and some new experimental features. Those features were touted by some of the initial Istio backers that continue to use Istio in their managed service offerings.

And interest in Istio remains high. As part of this week’s virtual KubeCon + CloudNativeCon North America 2020 event, the Cloud Native Computing Foundation (CNCF) released its annual user survey that found 27% of respondents were using a service mesh in production, a 50% increase over last year. The survey also found that 23% of respondents were “evaluating a service mesh” and another 19% were “planning to use one in the next 12 months.”

Of those using a service mesh in production, 47% said they use Istio, followed by Linkerd, which is part of CNCF, and Consul, both at 41%.

However, the latest release also comes four months after Google made the controversial decision to move Istio into the newly established Open Usage Commons (OUC) group instead of into the CNCF as most – including those that had helped Google establish the platform – had expected.

“At the project’s inception, there was an agreement that the project would be contributed to the CNCF when it was mature,” Jason McGee, VP and CTO of IBM’s Cloud Platform, wrote in a blog post at the time of Google’s decision. “IBM continues to believe 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. Google should reconsider their original commitment and bring Istio to the CNCF.”

Prior to that move, Istio was viewed by many as becoming the service mesh platform that the industry would rally around. Instead, the space has sort of stalled as vendors and organizations have worked through the licensing impact of Google’s decision.

“I do have deep concerns about the impact of this on the health of the community,” said Craig McLuckie, VP of VMware’s Modern Apps and Platform business unit, about Google’s decision. “I’m concerned that much of the promotion and growth of Istio was on the assumption that it was already part of CNCF. In fact, many people didn’t even realize that Istio was not at this point. It’s going to be very challenging for this community to navigate just given that there are no signs around an intent to move it into open governance, and it was still not clear what Google’s proposing actually meets the needs of the community from a trademark management perspective.”

While the service mesh space remains messy, the underlying technology continues to solidify. Many of the most widely used service mesh platforms are actually user planes running on top of the Envoy data plane. Envoy, which was originally created by Lyft in 2015, provides common utilities such as service discovery, load balancing, rate limiting, circuit breaking, stats, logging, and tracing to heterogeneous application architectures.

At a practical level, Envoy operates on the data plane of a service mesh where it sits next to running container pods. It’s designed to ease the transition to and the operation of cloud-native architectures by managing the interactions among microservices to ensure application performance.

Matt Klein, who developed Envoy at Lyft, not surprisingly said that Envoy will continue to spread throughout the service mesh ecosystem. But, when it comes to the control plane running on top, that remains to be seen.

“In terms of the technologies and solutions that people converge on at the control plane layer, or from the cloud provider layer, I think that's less clear,” Klein said during a service mesh panel discussion at this week’s KubeCon event.

That sentiment was echoed by Idit Levine, founder and CEO of Solo.io, who during the same panel noted that Envoy was indeed the “way to go,” but adding that the service mesh space lacked maturity.

“Mainly what I see is a lot of marketing around it and less execution,” Levine said. She added that a lot of enterprises are hearing this marketing and expressing interest in adopting a service mesh platform, “but then discover that it's not really a lot to adopt.”

Klein did add a wrinkle to the traditional service mesh argument by stating that he thought that control plane could actually turn toward a serverless model like Knative. That project is a Google-led effort to run a serverless user plane on top of Kubernetes. It’s also been given a bit more freedom compared to Istio from Google.

“My personal view is that applications are going to increasingly move to be ‘serverless,’” Klein said. “So I think we're going to see more platforms that are combined into offering container scheduling, and service mesh, and deploys, and all of that. I think it's hard to know what will happen over the next few years, but I'm interested in projects like Knative.”