What exactly is service mesh, and how do you manage multiple meshes?

Service mesh is a design pattern that provides a common networking framework, helping solve one pain of introducing a microservice architecture. With the rising interest in microservices, service mesh gained much momentum in recent years — with many service mesh projects now on the market.

In a recent LiveCast, we explored service mesh. Experts Lin Sun, IBM, and Idit Levine, Solo.io, shared service mesh benefits and demonstrated how you might go about implementing and managing an Istio service mesh architecture within your own stack. Below, we share their takeaways and also consider where the service mesh ecosystem is heading at large.

Microservices Issues

To understand service mesh, one must first understand microservices. Microservices are a useful software architectural style for new development, and as we recently covered, legacy modernization too. But as a microservice ecosystem expands, you quickly run into issues around deployment and scalability.

Microservices solve one problem but introduce others. Namely, they bring a significant organizational shift, says Idit Levine. Now that applications are distributed, with each team working on their own business logic, more and more is happening over the network. Thus, the network becomes core to how infrastructure is designed. This introduces new challenges to routing, security, and observability.

Enter Service Mesh

Containers and container orchestrators such as Kubernetes solved some of these issues by packaging services with their own runtimes, executing containers, and mapping them to machines. However, there was still a gap in a critical operational logic —— managing inter-service communication.

This is what service mesh aims to do really well. Service mesh is a design pattern that abstracts the network, adding standard sidecars beside your services to handle networking, security, and observability. Many service meshes use Envoy proxy, which acts as a gateway for each service.

By uniting microservices with a standard networking framework, you reap operational improvements — service developers don’t have to spend as much time on connecting and networking, retries, and configuring timeouts, says Lin. You’ve now got a sidecar proxy to do that work.

Istio Fundamentals

Istio is one of the most adopted meshes out there, targeted for enterprise adoption. Istio is fundamentally a control plane and data plane, with sidecar Envoy-based proxies to handle traffic and apply actions on individual services.

Here is a broad summary of some key Istio service mesh components:

• Control Plane: For setting up and issuing configurations.
• Data Plane: Where sidecar proxies live. Receives input from Control Plane.
• Istio API: Can help programmatically configure sidecar proxies.
• Gateway: An ingress and egress gateway to control inbound and outbound traffic at the application layer.

Some Istio Techniques & Commands

So how do we get started with Istio? As part of the Istio steering committee and technical oversight committee, Lin Sun has many tips to share. She highlighted many helpful CLI commands and methods to get started with Istio.

The simplest way to install Istio is by using Istioctl from a command line. This will install with basic default Istio configurations, optimized for smaller production environments.

$ istioctl install

You can also modify installation parameters or pass configuration files written in YAML to install with custom settings.

To upgrade Istio, you can also do so from the CLI. Lin reminds us to watch out for warning messages for incompatibility issues when moving from version to version.

(* |istio-book/bkvqth2w0h62fcapeg0g:default)
istio # istioctl upgrade

In her presentation, Lin considers a sample stock trader application deployed using Kubernetes that is accessible through K8s ingress or a load balancer. For such a setup, Lin describes using Ingres Gateway to control inbound traffic, and explains how to secure gateway configuration and inbound traffic.

Adding a service to the mesh can be accomplished using the CLI with the add-to-mesh command. You can also enable automatic sidecar injection on a namespace. Then, restarting a pod would inject an Envoy sidecar into each service.

To observe communication between services, Lin recommends using the Kiali dashboard, an open-source Istio dashboard, to visualize interactions among services. Kiali exposes topology information, traffic flow through ingress gateway, along with error codes.

Once a sidecar is added, users typically want to secure communication among services with service mesh. It’s good to note that Istio uses permissive mTLS — helpful for onboarding, but this default should be turned off eventually for stricter mTLS enforcement.

Lin goes on to describe how to use Istio to control traffic, selectively route requests, perform chaos testing, control outbound traffic, analyze resources for debugging, and inspect pods and services for troubleshooting for debugging. For specific details, we recommend checking out the Istio documentation or downloading Istio Explained: Getting Started with Service Mesh, the volume co-authored by Lin Sun and Daniel Berg that walks through these and other techniques.

Service Mesh Ecosystem

When it comes to service mesh options, we are “spoiled for choice,” says Idit Levine. Over nine major service meshes are on the market, most open-source — Linkerd, NGINX, Consul, Istio, Kuma, Open Service Mesh, AWS App Mesh, Mesh, and others.

Throughout these services mesh options, there are different architectures, unique onboarding processes, and custom APIs. Not to mention the threat of vendor-lock-in. All this variability can make choosing the right one for your job a bit difficult. Plus, will one service mesh project rise as an ecosystem standard? Idit likens the ongoing fervor to the container orchestration history — Kubernetes arguably won, and those who invested in Mesos regretted it.

Contrarily, a multicloud market may continue to support various meshes. “There is a reason why you may want to use more than one service mesh,” says Idit. For example, if you’re utilizing Lambda functions, utilizing AWS’s App Mesh may be your most powerful option.

Service Mesh Rarely Comes Alone

Wrangling a distributed, multi-mesh ecosystem could become quite cumbersome. Competing service meshes was the driving onus behind creating the CNCF sandbox project SMI, a standard interface for service meshes on Kubernetes.

However, a standard interface would only solve one half of the problem. In her talk, Service Mesh Past, Present, and Future, Idit argues that enterprise DevOps requires an abstraction layer to act as a single control pane for all mesh instances, even if they are all using Istio.

“The problem is more complex than this,” said Idit. “You will usually have more than one instance of service mesh; the reason is because you will have more than one cluster.” If a company has 50–1000 clusters in production, managing each instance could become a real pain.

To configure and manage multiple service meshes across various clusters, Idit recommends utilizing something like GlooMesh, an open-source project that abstracts differences between disparate APIs. With this agnostic “control plane of control planes,” users could manage multiple meshes from the same source and configure them through an API, CLI, or UI.

The Future of Service Mesh

Microservices introduce new issues around connectivity, security, and observability. However, “managing microservices does not need to be complicated,” said Lin. Service mesh is a programmable framework to alleviate these concerns.

As we’ve seen, Istio provides a ton of power to the user. The API is very low-level, offering many capabilities. Plus, the Envoy filter chain is extensible, meaning users can extend what Envoy and Istio can provide.

The future could see a greater emphasis on extending the Envoy filter chain with custom filters for transformation, metrics, logging. Projects to make this more accessible are underway using WebAssembly. Potential downsides here are increased latency and a lack of WASM maturity with production use cases.

Utilizing an agnostic control plane could alleviate repetitive actions when applying policies across multiple service meshes. While further abstraction is certainly not necessary for all use cases, this could find its use in sizeable enterprise environments.

In this article, we introduced a basic framework to help understand Istio and provided a sense of where the service mesh landscape is heading. To learn more about Istio, consider picking up the Istio Explained: Getting Started with Service Mesh or attend IstioCon.