Laptop Displaying the GigaOm Research Portal

Get your Free GigaOm account today.

Access complimentary GigaOm content by signing up for a FREE GigaOm account today — or upgrade to premium for full access to the GigaOm research catalog. Join now and uncover what you’ve been missing!

GigaOm Radar for Service Meshv2.0

Interconnecting the Enterprise

Table of Contents

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

1. Summary

The service mesh plays an essential role in cloud-native development, enabling fast, secure communication across microservices-based applications. Typically implemented alongside the workload as a sidecar proxy, a service mesh eliminates the complexity, fragmentation, and security vulnerabilities of repeatedly coding service-to-service communications by outsourcing the management of requests to an out-of-process application. Moreover, implementing a service mesh affects operational procedures and requires DevOps personnel to become familiar with new concepts and technologies.

As service mesh is an emerging technology undergoing rapid innovation, decision makers must take the time to carefully evaluate the landscape, considering the additional complexity, latency, and resource consumption involved. With a variety of open-source and commercial vendors targeting a broad range of application environments and deployment options, this GigaOm radar 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 service mesh sidecar provides third-party functionality alongside the actual workload within the container. For example, 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—including monitoring, control, and security—are implemented without changing a single line of application code. However, it should be noted that innovation is taking place around optimized low-resource, low-latency sidecar-less architectures—including the extended Berkeley Packet Filter (eBPF), Istio Ambient Mesh—offering full interoperability with Envoy sidecars.
  • Control plane configuration: Comprising a set of APIs and tools controlling proxy behavior across the mesh, the control plane automatically configures data plane service proxies. The control plane transforms a collection of isolated, stateless sidecar proxies into a distributed system and implements policies across all data planes within the mesh.
  • Control plane telemetry: Besides 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 provide observability into service behavior for troubleshooting, maintenance, and service optimization.

With different service mesh options and a rapidly evolving landscape, choosing the best service mesh for your organization depends on your use cases, existing software stack, architectural choices, and in-house capabilities. In addition, your internal resources and skill sets will influence your decision on whether you adopt a lightweight, developer-friendly service mesh or a full-featured solution requiring professional services. Figure 1 provides a list of service meshes included in this report and their acquisition options.

Note: Providing governance for open-source, vendor-neutral cloud-native projects, the Cloud Native Computing Foundation (CNCF) hosts several community-driven open-source projects with varying maturity levels: sandbox (early stage), incubating (stable), or graduated (widely deployed in production environments).

Figure 1. Service Mesh Projects and Vendors

This GigaOm Radar report provides an overview of notable service mesh projects and vendors and their available offerings. The corresponding GigaOm report “Key Criteria for Evaluating Service Mesh Solutions” outlines critical criteria and evaluation metrics for selecting a service mesh. Together, these reports offer essential insights for cloud-native application development initiatives, helping decision makers evaluate solutions before deciding where to invest.

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.