One thing we’ve heard from the mesh administrators and operators who use Istio is that its complexity makes it hard to adopt and integrate with their current stack. I’ve been involved with the development of Istio since Istio 0.6, and I’ve seen it become increasingly complex over time.

Enter Istio 1.5. This release has many new features, but those features are dwarfed by a major improvement. The improvement I’m most excited about is an architectural simplification of Istio that consolidates the control panel into a single binary called istiod. Essentially, istiod dramatically simplifies Istio’s architecture, which we think will improve the feasibility of making improvements to the project.

Read the Istio community’s official release blog for more information.

Why Istio started with a microservice architecture

Initially, Istio used a microservice architecture to support the way our teams within Istio were working. At the time, we were delivering updates and releases for services on different schedules, we were using API contracts between our teams, and we needed independent horizontal scaling.

As Istio’s team and technology matured, the advantages of a microservice architecture waned. As we wrapped up development of Istio 1.4, the Istio Environments working group received a proposal to compose a monolith of the existing components. The Environments working group led the technical debates, and the istiod concept was born! During the Istio Technical Oversight Committee meeting that followed, the Environments working group proposed using the istiod binary.

What exactly is Istiod?

Put simply, istiod is the reversal of the microservice architecture model. To understand how the istiod binary improves Istio, let’s look at its current structure.

Istio’s 1.4 control plane consists of five services and plugins for extensibility:

• sidecar proxy loading. Provided by the sidecar-injector service (not picutred).
• extensibility. Provided by the Mixer services (istio-telemetry and istio-policy services).
• extensibility plugins. Provided by the Mixer Adapter plugins.
• Sidecar proxy config generation and serving. Provided by the Pilot service.
• security. Provided by the Citadel service.
• validation. Provided by the Galley service.

Here’s a picture of what Istio 1.4’s architecture looks like:

Istio 1.5 reorganizes the control plane into one service and reimplements extensibility:

• istiod. Provides proxy sidecar loading, mesh calculation, security and validation.
• Data plane. Mixer Adapater plugins are reimplemented within the mesh as Envoy plugins.

As you can see, Istio 1.5’s architecture is simplified:

Why Istiod?

So, why did we make the choice to adopt the istiod binary? One main reason was that as the Istio development matured, we began to work as a single team with a single delivery, so we no longer met the criteria for needing a microservices architecture. Other specific reasons include:

• Easier operation of the control plane. The simplified architecture makes it easier for mesh administrators and operators to control and monitor the Istio control plane. Monitoring one istiod service is much easier than six or seven services in Istio 1.4.
• Improve performance. In other releases of Istio, there was a large amount of inter-control plane component communication over networking, which was causing performance issues. istiod reduces the number of components, so we hope this positively affects performance.
• Reduced internal API footprint. Much of our prior microservices implementation contain redundant code. Istio is improved by removing this redundant code that is used by each microservice typically for configuration.

Other enhancements in Istio 1.5

Istio 1.5 introduces a new model to extend Istio through the WebAssembly (Wasm) runtime in Envoy, which lets you implement extensions in many languages. These Wasm modules can be dynamically loaded while the proxy continues to serve traffic. They are great for reuse also, think of them like docker images for Envoy proxy to easily extend the platform in ways that Mixer simply couldn’t. Refer to Solo.io’s blog to learn more about the WebAssembly extension.

Other key enhancements include:

• Beta release of command line installation of Istio using istioctl
• Dozens of improvements to istioctl including better validation rules and easier intergration with CI systems
• Improved security experience by consolidating to a single CRD (beta), adding new security policy and authorizations, and more
• Better observability features, including default Telemetry v2

Istio’s strength is community

Istio’s open architecture and ecosystem combine to make the technology effective. There is no vendor lock-in that limits the types of services you can use with it. Plus, Istio can run in any cloud model — public cloud, private cloud, on-premises, or hybrid cloud.

Our strong, vibrant community makes Istio special. Istio was founded by IBM, Google, and Lyft in 2017. The Istio project benefits from an active, diverse community composed of over 800 developers from over 459 organizations. Istio and the Istio ecosystem has countless additional contributors working to make Istio a success.

Get involved with Istio

The Istio service mesh technology is open source. Istio relies on an active community of contributors to improve the technology.

Here are a few ways for you to get involved:

• Get Started with Istio on your Kubernetes cluster.
• Learn about contributing to Istio.
• Join Istio’s Slack by following these instructions.

Steven Dake is an open source leader at IBM. He is a maintainer within the Istio project, and serves as a workgroup lead within the Environments Working Group.