Why Istio is winning the open source service mesh race [Q&A]

In recent years the use of microservices has helped to streamline development processes. But there's still an issue with managing communication between services.

Service mesh is a technology that adds uniform networking capabilities right across the program stack but is decoupled from the application code itself.

There are a number of competing options available to implement service mesh. We spoke to Lin Sun, director of open source at Solo.io to find out why she believes the IBM/Google open source project, Istio is the clear winner.

BN: How has the rise of microservices helped drive the rise and importance of service mesh?

LS: Microservice is an architecture and development approach that breaks down business functions into individually deployable and managed services. Microservices are essentially loosely coupled components of an application that communicate with each other using well-defined APIs. Having many loosely coupled services that are independently and frequently changing does promote agility, but it also presents several management challenges:

• How do you secure communication among microservices?

• How do you observe interactions between microservices when you have many distributed, loosely coupled components?

• How do you manage traffic at each service endpoint to perform A/B testing or canary deployments without impacting clients within the system?

• How do you manage timeout and communication failures between the microservices?

Suppose service owners have only used one programming language to build all of the microservices. In that case, you could solve the above problems using language-specific libraries by asking each service owner to adjust the application logic to use the types and methods provided by the libraries. However, this will become unmanageable when your services have multiple programming languages.

Service mesh is designed to solve these challenges in a language-agnostic way. A service mesh is a programmable framework that allows you to observe, secure, and connect microservices. It doesn't establish connectivity between microservices but instead allows you to apply policies and controls on top of existing networks to govern how microservices interact. This means you can declare your intentions, and your service mesh will ensure that your declared intentions are applied to the services and network. A service mesh ultimately shifts the implementation responsibilities out of the application and moves them into the network.

BN: What role have open source projects played in fueling service mesh momentum?

LS: The service mesh ecosystem is vibrant; there are many open-source projects and vendor-specific projects that provide an implementation of a service mesh. The fact that there are many service mesh options validates the interest in service mesh. Many projects are listed at CNCF Service Mesh landscape, including but not limited to Istio, Linkerd, Consul Connect, AWS App Mesh, Gloo Mesh, Kuma, Open Service Mesh, etc. While the industry has not finalized which service mesh project is the de facto standard, Istio is the most popular service mesh from a recent survey by CNCF in late 2020. I believe Istio is becoming the Kubernetes for service mesh.

BN: What makes Istio different from other open-source projects?

LS: As someone who has been contributing to Istio from the beginning of the project, I think many aspects make Istio different. A few of my favorites include:

• Istio has 350+ contributing companies and 1900+ individual contributors for the past year.

• Istio is the dominant service mesh in production today.

• Istio is stable for service owners to consume its core functions, and the project is committed to focusing on day-to-day operations for Istio users. The project also strives to provide a transparent experience for users to move their service to Istio with zero or minimal code change, including debugging tools (such as istioctl analyze) to help users quickly troubleshoot when things are wrong.

• Istio is the most feature-rich service mesh. It enables users to connect services across multi clusters securely, quickly onboard services running on VMs, plugging external authorization systems, and extending the Istio data plane using Envoy filter or WebAssembly (Wasm).

• Istio itself builds upon many open-source projects such as Kubernetes and Envoy. Istio is moving closer to Kubernetes by supporting the Kubernetes Gateway API and MultiCluster service API.

BN: How active are early OSS participants such as IBM, Lyft and Google in Istio?

LS: They are all very active. Google continues to be the most significant contributor to Istio, while IBM remains the second-largest contributor. Lyft is the second largest contributor to Envoy proxy, the default proxy used in Istio. It is fascinating to see many other Istio contributing companies and individual contributors joining these co-founders.

BN: How are service mesh users tackling real-world integration challenges?

LS: Joe Searcy from T-Mobile shared their Istio service mesh adoption story at IstioCon and SoloCon. He highlighted that adopting Istio allows them to immediately gain observability instrumentation and security out of the box, hence simplified their applications. Adopting Istio enabled them to focus on business logic rather than language-specific security, observability, and resiliency, resulting in a 50 percent reduction in MTTR and savings above 100k engineering hours.

And shared by Weibo He, Staff Software Engineer at Airbnb, at IstioCon, was that Airbnb started with the library approach to solve inter-service communication challenges but found out that approach does not scale and requires one or two re-engineers a year to build the libraries for one language. As the team started to support more programming languages, the library approach became unscalable, and they chose Istio service mesh to solve the challenge.

BN: How can service mesh work for Kubernetes environments?

LS: Kubernetes has become the de facto container orchestration platform and the new application platform. While I love Kubernetes, there are inter-service communication challenges that Kubernetes doesn't solve, such as how to handle unreliable network connectivities, how to secure the microservice communication, and how to control traffic shift beyond based on the number of replicas.

Service mesh projects like Istio provide their APIs as Kubernetes Custom Resource Definitions (CRDs) so that users can declare their intention as policies using these service mesh custom resources. These user-provided resources instruct the service mesh control plane to program the sidecar proxies to solve these inter-service communication challenges based on users' intentions. While many service mesh projects support services running in Kubernetes, service mesh is not just for Kubernetes. Many users are still running their services on virtual machines or bare metal, and it will take time for them to transition many of these to run on containers. It is critical for service mesh projects to provide a smooth experience to assist users in this transition, such as securely bootstrap the service identity running on VMs, observe and configure a unified service that partially runs VM and partially in K8s.

Photo credit: Panchenko Vladimir/ Shutterstock