GigaOm Radar Report for Evaluating Service Meshv 1.0

1. Summary

Historically, developers independently implemented error handling, observability, and security within each application or microservice to ensure the success of inbound and outbound communication requests. However, as different teams repeated the process and coded similar functionality into each application (often using different programming languages), complexity, fragmentation, and security vulnerabilities were introduced into the environment.

A service mesh addresses this problem by “outsourcing” the management of service-to-service communication requests to an out-of-process application. Typically implemented alongside the workload as a “sidecar” proxy, a service mesh simplifies and streamlines runtime operations. Comprising a “data plane” of interconnected network proxies and a “control plane” for configuring the proxies and collecting metrics, it provides a shared infrastructure layer to manage intra-service runtime communications within a distributed, microservice-based software architecture.

Application agnostic and fully portable, the service mesh can be adopted by an organization to support any service written in any language or framework. Adding uniform capabilities across the environment, a service mesh provides authentication, authorization, discovery, encryption, load balancing, logging, observability, routing, and tracing.

While implementing a service mesh has zero impact on application code (other than “desired changes” such as the removal of redundant functionality handled by the mesh, propagating mesh headers to enable tracing, or other changes to maximize the benefits of the mesh), it does affect operational procedures and requires the familiarization of DevOps personnel with new concepts and technologies. Additionally, as an emerging technology, taking the time to choose the right service mesh for your organization is essential due to the additional complexity, latency, and resource consumption involved.

Although service mesh patterns can be applied to both monolithic and microservice-based applications, this study focuses on the latter running on various platforms, including containers/Kubernetes and virtual machines (VMs). Also known as K8s, Kubernetes is an open source orchestration platform automating the deployment, management, and scaling of containers.

This report provides an overview of the service mesh landscape based on the following table stakes, which are mature, stable solution features common across all service meshes:

• Dedicated Infrastructure Layer: Delivering fast, reliable, and secure service-to-service communications, a service mesh is a dedicated infrastructure layer fully integrated within the distributed application to control the delivery of service requests. The infrastructure layer provides several functions, including service discovery, authentication and authorization, health checks, failure recovery, load balancing, and observability via the “data plane.”
• Sidecar Implementation: Like a sidecar attached to a motorcycle, a sidecar implementation provides third-party functionality alongside the actual workload within the container. A service proxy—such as Envoy—is attached to a workload during deployment to manage service-to-service communications within a service mesh. All management capabilities required by the workload (monitoring, control, and security) are implemented without changing a single line of application code.
• Control Plane Configuration: Comprising a set of APIs and tools used to control proxy behavior across the mesh, the control plane automatically configures data plane service proxies. Transforming a collection of isolated, stateless sidecar proxies into a distributed system, the control plane implements policies across all data planes running within the mesh.
• Control Plane Telemetry: In addition to configuring and managing proxies used to route traffic and enforce policies, the control plane collects telemetry data for each request. The detailed statistics, logging, and distributed tracing data collected provide observability into service behavior for troubleshooting, maintenance, and service optimization.

With many different service meshes and options available—and the landscape evolving—choosing the best service mesh for your organization depends on your use cases, existing software stack, architectural choices, and in-house capabilities. Your internal resources and skillsets most likely will influence your decision as to whether you adopt a lightweight, developer-friendly service mesh such as Linkerd or NGINX, or an Istio-based solution.

We recommend using this report to explore the different service meshes and delivery models available on the market, while identifying those matching your business requirements, use cases, and capabilities. Then, contact the relevant open source community or commercial vendor for additional information on features, deployment models, and cost.

For additional information about how to evaluate a service mesh, please read the report, Key Criteria for Evaluating Service Mesh: An Evaluation Guide for Technology Decision Makers, published by GigaOm.