Istio 1.5 – “We developed Istio to allow users to incrementally adopt features”

JAXenter: Historically, Istio has been quite a complex and complicated service mesh platform to implement and use. As more features were added, this fact only compounded. What inspired the change of approach for Istio 1.5?

Daniel Berg: In general, managing a highly distributed system of services is complex. Trying to do so without a modern service mesh such as Istio makes the task even more daunting. As with any tool, if you want to take advantage of every single one of Istio’s rich features, you must commit significant time and resources to learning the concepts, resources, and configurations necessary to program Istio.

Once you learn a core set of concepts and resources, you can achieve most of your requirements.

This learning cost is not unique to Istio. Take a look at Kubernetes. Kubernetes is arguably the best container orchestration platform, with thousands of successful customers running in production. Kubernetes is rich with features, but it can be complex as well. Most Kubernetes users learn a core set of concepts and resources that allow them to achieve 80% of their goals. Istio is similar. Once you learn a core set of concepts and resources, you can achieve most of your requirements. We developed Istio to allow users to incrementally adopt features, which means you can incrementally learn concepts and resources as you use more features—you add value as you need).

SEE ALSO: Istio 1.5 simplifies its deployment model with Istiod

With any healthy project, you need to take time to retrospect on your architecture. We do the same with the Istio project. Yes, we add features to the project based on user input, but we are always looking for opportunities to improve the platform in areas like user experience, installation, upgrade support, and overall day-to-day operations. Another key area where we look for improvements is with the overall architecture of the project where we examine the APIs, performance, and component architecture. The changes that users see in the Istio 1.5 release are natural outcomes of these retrospectives.

JAXenter: In DevOps conversations we often talk about breaking monoliths down into microservices, but what you’ve done with Istiod is consolidate a number of microservices into a monolith. How did you come to decide this was the way to go?

Daniel Berg: I know it may seem odd that a project that is designed to help customers manage microservices has itself decided to package its release as a single binary (monolith) versus multiple separate binaries as is common with microservices. The change was not made because of the technology itself, but, rather, because of how teams collaborate. A key benefit of microservices is to help organizations reduce friction when delivering changes. Yes, this is done with loosely coupled, API-driven services but, more importantly, friction is reduced when teams can develop and deliver their code independently from one another (i.e., there is less ceremony to deliver a change).

Microservice architectures allow small, loosely coupled teams to develop, deliver, and maintain their services independent of one another. The Istio open source project is organized with multiple loosely coupled teams that have historically developed and delivered their components as microservices (i.e., Pilot, Citadel, Telemetry, Policy, Galley). Such an approach makes complete sense if the same team that developed the Istio components were actually operating those components as well.

The change was not made because of the technology itself, but, rather, because of how teams collaborate.

However, this is not the case for Istio. The Istio team develops and releases the components, but our project adopters are installing and operating Istio. Because these adopters are generally not the individuals who developed the code, the need for teams to develop and deliver the code independently to reduce friction is completely null and void in this context.

Istio is still developed as a set of loosely coupled components, but, as part of Istio 1.5, we decided to package those components into a single binary to improve the install and operational experience for the Istio adopters. Since the Istio adopters were not responsible for developing the Istio component code, it is simpler for them to manage and operate Istio as a single component versus multiple loosely coupled components.

To learn more about the technical reasons why we made the decision to move to Istiod, check out our Istio blog.

JAXenter: Do you expect to see a higher number of implementations now that Istiod makes implementation easier?

We are super excited about the Secret Discovery Service (SDS) support becoming default in Istio 1.5.

Lin Sun: By consolidating multiple control plane components to Istiod, it makes it easier for mesh admins and operators to install, configure, and manage the lifecycle of the Istio control plane. We expect the simplified configuration of the Istio control plan to benefit both single-cluster Istio mesh and multicluster Istio mesh configurations. This is not only a statement for single-cluster Istio mesh, but also our multicluster Istio mesh configuration. Instead of requiring mesh admins or operators to remember which configuration is for which control plane component, they now have a single plane component where they can apply the configuration. Further, we eliminated some control plane configuration such as the controlPlaneSecurityEnabled flag.

JAXenter: What else are you excited about in the 1.5 release?

Lin Sun: Besides Istiod, we are super excited about the Secret Discovery Service (SDS) support becoming default in Istio 1.5, for both ingress gateway and Istio sidecar proxy. Based on many conversations with our users, we know SDS is extremely important for them. We are particularly excited about the benefits it brings to our users including:

• Having keys and certificates distributed from Istiod to istio-agent to istio-proxy via the SDS API is more secure than secret-volume mounted files.
• When running ingress gateway or Istio proxy in SDS mode, there is no downtime during certification rotation.
• For ingress gateway, it allows users to easily configure multiple hosts with multiple keys and certificates.

We are also excited that Telemetry v2 is being rolled out as the default for 1.5. This enables users to observe their microservices without running the istio-telemetry service. We heard your feedback regarding performance problems when using telemetry and have addressed the issues with Telemetry v2 by distributing the telemetry support to all istio-proxies. This provides a more scalable and performant approach to enable observability between services.

SEE ALSO: Making microservices micro with Istio and Kubernetes

Another benefit in the Istio 1.5 release is that a Pod Security Policy configuration is no longer needed for citadel agent since citadel agent is moved from running per node (citadel-agent) to per pod (istio-agent).

JAXenter: What about the future – what happens next for Istio and Istiod, both in the short and long term?

We are also excited that Telemetry v2 is being rolled out as the default for 1.5.

Lin Sun: In the short term, we expect to:

• Develop reasonable addon stories for users to easily integrate addons.
• Simplify installation, configuration, and management of multicluster.
• Harden the Istio operator so users can easily install and upgrade Istio via operator.
• Provide samples and tooling around the new model to extend Istio through the WebAssembly (Wasm) runtime in Envoy, which lets you implement extensions in many languages.

A long-term goal of ours is to develop mesh federation stories to allow multiple heterogeneous mesh or homogeneous mesh to federate.

You can read more about the plans for Istio in 2020 in this recent blog.

The post Istio 1.5 – “We developed Istio to allow users to incrementally adopt features” appeared first on JAXenter.