Istio 1.5: What’s in it for Developers?

In the cloud-native technology ecosystem, first came containers and Kubernetes and then challenges to how applications, developers, and operators interact with storage, networking, and security. Service Mesh has emerged, in particular, to solve the service-to-service communication challenge of distributed microservices. By abstracting the networking code from the business logic, the service mesh deploys a sidecar proxy next to each service to facilitate all incoming and outgoing traffic. This network of proxies is the data plane of the service mesh and how the network patterns are controlled (secured, shaped, and shifted) through a control plane.

Istio is an open source service mesh led by Google, IBM, and Lyft to connect, monitor, and secure microservices and has gained popularity among Kubernetes end users. Often referred to as being overly complex, Istio provides a robust feature set for controlling application traffic and has had a dedicated focus on improving usability (simplicity, performance) in 2019 and is continuing that path for 2020.

What’s New in Istio 1.5

The latest version, Istio 1.5, was released March 5 and carries forward the focus on improving the usability, security, and extensibility of Istio for end users, community, and the ecosystem. The highlights of this release include:

Istiod consolidates the control plane into a single binary to simplify the install, run, and upgrade experience.
A new model for extensibility with WebAssembly to provide a more flexible and efficient way to extend Istio and Envoy proxy.
Easier to use with about a dozen improvements to istioctl (including the ability to install) and mTLS configuration.
More secure with simplified and automatic mTLS, improvements to auth and removing the need to mount certs on every pod.
Better observability with Telemetry v2 supporting metrics for TCP connections and enhanced support for gRPC workloads.

Having worked with Istio for the last few years, it’s great to see the project flourishing (#4 on Github’s top ten list of fastest growing projects) and the focus of new releases on usability for both developers and operators, stronger defaults and opportunities for the community to engage with the project. In particular, the work on WebAssembly brings together the Istio and Envoy Proxy community together with a unified model in how proxies can be extended and creates opportunities for the broader community and ecosystem to participate in building and sharing extensions.

Having worked with Istio for the last few years, it’s great to see the project flourishing (#4 on Github’s top ten list of fastest-growing projects) and the focus of new releases on usability for both developers and operators, stronger defaults and opportunities for the community to engage with the project. In particular, the work on WebAssembly brings together the Istio and Envoy Proxy community together with a unified model in how proxies can be extended and creates opportunities for the broader community and ecosystem to participate in building and sharing extensions.

Extensibility For Envoy Proxy and Istio with WebAssembly

WebAssembly, or Wasm for short, is a portable binary format to execute code at near-native speed. For the past 18 months, the Istio and Envoy communities have been working together to bring WebAssembly into the upstream Envoy project, whose popularity comes from its speed and extensibility.

Envoy’s extensibility comes in the form of filters but until this point they were the domain of developers well versed in C++ and needed to be compiled directly into an Envoy instance. This meant that anyone who wanted to write and use custom filters had to ship and maintain their own distro.

The addition of Wasm allows developers to build and compile custom extensions in any language and execute them in an isolated instance from the Envoy instance. This opens up Envoy to more developer communities to write extensions in the language they prefer and makes the environment more resilient to failure with a “separation of concerns” between the extension and the proxy, thus solving two primary issues related to its accessibility and sustainability.

Having this implemented into upstream Envoy also means that every downstream solution (Istio, Gloo) can benefit from using WebAssembly to customize the behavior of the proxies in their technology.

Providing a “Docker like” developer experience for WebAssembly

Alongside the Istio 1.5 announcement and in collaboration with Google and the Istio community, Solo.io released an update to WebAssembly Hub to expand the support of Istio and Envoy.

First launched in December 2019, WebAssembly Hub is a place for developers and operators to build, publish and share their Wasm extensions for Envoy based solutions. WebAssembly Hub enables developers with a workflow to very easily and quickly spin up a new WebAssembly project, build it using Bazel in Docker, and push it to an OCI-compliant registry to share with their team and community.

From the Hub, operators can pull the module and configure Envoy proxies themselves to load it from disk. Behind the scenes, the WebAssembly Hub is the tooling that smooths the developer experience by pulling in the correct toolchain, does the version verification, permission control and automates the deployment of the extensions.

The WebAssembly Hub provides both a powerful CLI and GUI experience so that both developers and operators can collaborate in how they build and deploy their desired proxy customizations. The WebAssembly Hub is free to use, the community is invited to participate in the definition of a spec for distributing any type of Wasm module and feedback and requests are welcome in the community Slack.

The post Istio 1.5: What’s in it for Developers? appeared first on JAXenter.

Source : JAXenter