The Service Mesh Wars: Why Istio might not be favorite after all

By Gadi Naor, CTO and Co-Founder, Alcide

These days, more organizations are shifting to cloud-native applications, which are designed to run in the cloud and take advantage of the cloud’s dynamic, scalable and readily-available nature. Typically, cloud-native application architectures are made up of microservices housed in containers. With containers as the go-to cloud-native packaging format, and Kubernetes as the platform of choice for orchestrating containers and cloud-native applications, a new set of operational challenges is emerging related to the parallel and distributed nature of cloud-native application architectures.

At some point, debugging or tracing transactions that span multiple microservices becomes inefficient, and authorizing access between dynamic services becomes hard to manage and hard to sustain at the network level. This is where service mesh comes in.

Service mesh can be viewed as an application infrastructure layer that completely abstracts the complexity of the underlying network from applications. It enables powerful traffic management between microservices, application-transparent observability, and solid application security foundations to control service-to-service access, in addition to traffic encryption.

Service Mesh is still a relatively new concept. The 2019 Cloud Native Computing Foundation (CNCF) survey found that only 18% of respondents were using service mesh in production. But as applications grow in scope and complexity, service mesh will be increasingly important to manage this complexity and deliver the scalability and agility promised by Kubernetes.

As far as service mesh platforms go, Istio has been a long standing frontrunner, with backing from Google, IBM, Lyft, Red Hat, Vmware and Oracle. While Istio tries to solve every problem with a wealth of features and flexibility, this is often more than many teams actually need.

In contrast, newer options such as Kuma, the open-source control plane developed by API gateway platform Kong, focus on offering a streamlined user experience that enables teams to get their service mesh up and running quickly. Another recently announced contender is Microsoft’s Open Service Mesh, an SMI-compliant, lightweight service mesh run as an open source project. So far, it has the backing of service-mesh partners including HashiCorp, Solo.io, and Buoyant.

In any case, choosing the right service mesh should not be taken lightly. Once you’ve implemented a service mesh, you’re essentially locked in. With that in mind, here are some considerations for choosing the right service mesh for your needs:

Do you even need service mesh?

Depending on your needs, you may be able to solve the challenges associated with distributed cloud-native applications without adding the complexity and operational burden of implementing a service mesh. For example, a primary motivation for deploying a service mesh platform like Istio is to implement canary or blue-green deployments. However, almost every modern Kubernetes Ingress Controller, such as Contour, has such functionality built into it.

Another thing to consider is that If you have latency-sensitive workloads, know that service mesh implemented using side-car technology adds latency. This might make service mesh prohibitive for applications like multimedia streaming, high-speed financial trading systems, and multiplayer online gaming.

What resources do you have to manage your service mesh?

Service mesh platforms — particularly Istio — are incredibly feature rich and extensible, with capabilities for automated security, access control policies, observability, and service connectivity. But with that complexity comes a steep learning curve. For smaller teams or those without extensive experience with Istio already, it may be more trouble than it's worth.

Even Matt Klien, the creator of the Envoy dataplane that Istio is built on, acknowledges that Istio may be too complex. “Istio made some big mistakes early on, particularly from a technical perspective with things like Mixer. I think it’s on the right track now, but whether it can break through its complicated reputation of the past few years, that I’m less clear on.”

On the other hand, newer options solve many of the same problems as Istio with a much simpler workflow. Kuma, for example, was designed to have a gradual learning curve, according to Kong CTO Marco Palladino. That means a simpler control plane and plenty of automation that makes it easy to use out of the box — but with the option for more advanced configuration. Consul and Linkerd are similarly designed with the developer experience in mind.

What environments do you use?

Most service mesh platforms are designed to connect services running on any type of workload, including VMs, containers and serverless workloads. However, these platforms are far easier to drive and manage when run on Kubernetes. Istio was made specifically for Kubernetes, making the integration more seamless for the user. Conversely, some platforms like Linkerd only work with Kubernetes and are not made to address multi-cloud challenges.

Application environments are rarely limited to Kubernetes, however. As a platform-agnostic service mesh, Kuma can be deployed across Kubernetes, VMs, bare metal or other platforms with one step. This allows enterprises to gain the benefits of a service mesh before they transition their existing enterprise applications to Kubernetes. Consul can also be used to manage workloads on VMs.

The rest of your technology stack matters too. AWS App Mesh is easy to use for AWS users, as it comes integrated into the AWS landscape and is fully managed. Similarly, Istio is easily integrated with Google Cloud, Alibaba Cloud and IBM Cloud and can also be managed through various commercial solutions.

What are your security needs?

The majority of the service mesh options mentioned here have common application security features, including communication encryption in the form of mutual TLS (mTLS) to encrypt traffic between microservices, as well as access regulation between services. The more advanced service mesh platforms, such as Istio, provide the most granular API-level access controls. However, that also means it can be harder to manage all the access controls and security policies, which could lead to potential gaps.

One important point to keep in mind is that while service mesh security controls govern events and workflows within the service mesh, off-mesh security is still required. For example, Kubernetes security is much broader than the parameters of service mesh security. Secrets management, threat detection, access audit log monitoring and other security tools should also be in your Kubernetes security arsenal. In any case, you shouldn’t rely on your service mesh to take care of all your security needs.

The service mesh wars continue

Today, there is a clear plurality of service mesh platforms, and it’s unclear which platform will emerge as the winner of the service mesh wars. All platforms address a similar set of core challenges and differ in the way they are implemented. Istio may be the standard bearer of the service mesh movement, but that might not last forever, especially if its complexity is a turn-off for DevOps teams. While still in the early stage, Kuma, a CNCF sandbox project, shows promise by building on the lessons learned from previous service meshes, while the recent Open Service Mesh from Microsoft brings the standardization spirit which is an important accelerator for technology adoption.