Istio 1.3: What’s New, What’s Coming

Here’s a look at the features included in Istio 1.3

Istio is an open source service mesh that enables developers to “connect, secure, control, and observe services.” Spearheaded by Google, IBM and Lyft, Istio is a collaborative initiative meant to solve operational hurdles associated with distributed microservices development.

Since its release in mid-2017, Istio has been evolving. I recently sat down with Lin Sun, senior technical staff member and master inventor at IBM, to discuss the latest version of Istio. Below, we’ll see what features are new in Istio 1.3, what user hiccups this update responds to and where Istio is heading.

What is Istio?

Launched at GlueCon in 2017, Istio is a service mesh to enable capabilities such as connecting, securing and observing for Kubernetes and virtual machines. 

Utilizing the Envoy proxy developed by Lyft, Istio can be used for load balancing, service-to-service authentication and monitoring. Also possible is traffic shifting, canary testing and more with Google analytics.

“Istio is an important technology to look at throughout the cloud-native journey,” Lin says. “It’s a natural progression as clients adopt Kubernetes and break apart their monolithic services.”

Issues From 1.0-1.2 Solved

Istio 1.3 improves developer experience with onboarding mechanics and remedies for certain configuration issues. Istio 1.3 also enables developers to connect to services outside of Kubernetes easily with a single command—a feature also in prior releases, though previous iterations required crafting and applying Istio resources.

Many of the new changes focus on extensibility. As Lin says, developers shouldn’t feel trapped within the confines of Istio. To that end, they’ve made changes to meet developer expectations by introducing the following features:

  • Protocol Agnostic: No longer must developers specify a protocol (HTTP, TCP, etc) within their YAML files. Istio 1.3 utilizes automatic protocol detection for outbound traffic (inbound traffic is still being actively developed).
  • Container Port: Similarly, in previous iterations, Istio required developers to declare a container port in their YAML files. In Istio 1.3, this has been eliminated.
  • Flags: Debugging and tooling helps flag when services don’t meet requirements.

“We continue focusing on user experience, and how users can easily onboard their microservices,” Lin says. This equates to reducing developer requirements to and match the expectations of Kubernetes and virtual machine configuration settings.

Other Features

Other features introduced in Istio 1.3 include:

  • Describe command: This new command helps analyze a pod, its deployment method and resources associated with that pod. This helps understand what is missing in services and deployments and also analyzes whether it meets the requirements for Istio in general.
  • Add to Istio with a single command: Istio 1.3 introduces a command to add services from Kubernetes or a virtual machine with a single command. The goal is to improve developer ease with consistency.
  • New dashboard command: Istio 1.3 introduces a new dashboard command to launch dashboards more easily help monitor an Envoy app console.
  • Improved handling of telemetries: The community has re-engineered the Mixer Component. Within Istio 1.3, telemetry (one of the Mixer Components; the other is Istio Policy) is no longer necessary.
  • Leave mesh: Istio 1.3 introduces an ability to leave the mesh with a single command. Features such as this are designed to create reusable YAML files that don’t require too much extra action from developer users.

A full list of Istio 1.3 features can be found here.

According to Lin, developers saw the Mixer Component as a single point of failure, which has drawn concern. The community is hard at work with delegation features to reduce the risk of failure with additional checks. 

Lin sees the “community working towards eliminating mixer altogether and [to] push that function as envoy extensions for services.”

Future Evolution

In terms of future evolution, the Istio team is looking to increase extensibility for Istio. 

“We want the mesh to be transparent to our users—that’s one of our big goals,” Lin says. “We want users to be able to easily add services to the mesh.”

In addition to a single service mesh, users are starting to think on a larger scale. Lin predicts that tooling around multicluster service mesh is the next logical stride for the technology. Such improvements will likely bring traffic control, new cluster-cluster integration capabilities and new administration configurations.

“We want to make sure users can easily add Kubernetes clusters or remove them from an existing service mesh,” Lin says.

The Istio Community

Istio, which initially was dogfooded internally at IBM to gain telemetry and security of microservices, has assisted with debugging and discovering issues. It’s also been advocated for by American Airlines, Autotrader and others. 

Istio considers anyone with an approved pull request to be approved as members. The Istio project can be located here on GitHub. For discussion, there is also a Discuss, Slack group and weekly community call.

Bill Doerrfeld

Bill Doerrfeld

Bill Doerrfeld is a tech journalist and analyst based in Seattle. His beat is cloud technologies, specifically the web API economy. He began researching APIs as an Associate Editor at ProgrammableWeb, and since 2015 has been the Editor at Nordic APIs, a high impact blog on API strategy for providers. He loves discovering new trends, researching new technology, and writing on topics like DevOps, REST design, GraphQL, SaaS marketing, IoT, AI, and more. He also gets out into the world to speak occasionally.

Bill Doerrfeld has 9 posts and counting. See all posts by Bill Doerrfeld