Are you looking to evaluate enterprise technologies faster? Sign up to watch GigaOm's 4-part on-demand research methodology video series.

Watch the Videos

Part 2 of 2 in a Series

Evaluating Service Mesh

GigaOm Radar Report for Evaluating Service Mesh v 1.0

Table of Contents

  1. Summary
  2. Market Categories and Deployment Types
  3. Key Criteria Comparison
  4. GigaOm Radar
  5. Vendor Insights
  6. Analyst’s Take
  7. About Ivan McPhee
  8. About Chris Grundemann

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.

How to Read this Report

This GigaOm report is one of a series of documents that helps IT organizations assess competing solutions in the context of well-defined features and criteria. For a fuller understanding consider reviewing the following reports:

Key Criteria report: A detailed market sector analysis that assesses the impact that key product features and criteria have on top-line solution characteristics—such as scalability, performance, and TCO—that drive purchase decisions.

GigaOm Radar report: A forward-looking analysis that plots the relative value and progression of vendor solutions along multiple axes based on strategy and execution. The Radar report includes a breakdown of each vendor’s offering in the sector.

Solution Profile: An in-depth vendor analysis that builds on the framework developed in the Key Criteria and Radar reports to assess a company’s engagement within a technology sector. This analysis includes forward-looking guidance around both strategy and product.

Full report available to GigaOm Subscribers.

Subscribe Now