What is a service mesh?

How a service mesh works

A service mesh enhances the manageability, observability and security of microservices-based applications. It uses proxy-based communication where the proxies are built into an application. These proxies act as intermediaries between microservices and an organization's network and route all traffic to and from the service via its proxy server. This maximizes the efficiency of all interconnected elements.

Typically, a service mesh architecture consists of a data plane and a control plane.

Data plane

The data plane handles the data part of a service mesh. It's composed of various services running alongside individual proxy instances known as sidecars or sidecar proxies. Sidecars can handle tasks abstracted from the service itself, such as monitoring and security. In a microservices application, a sidecar attaches to each service. In a container, the sidecar attaches to each application container, virtual machine (VM) or container orchestration unit, such as a Kubernetes pod. Service instances, sidecars and their interactions make up the data plane in a service mesh.

To prevent service degradation, sidecar proxies integrate resiliency features, such as circuit breaking -- a design pattern for microservices -- and request retries to enable direct service-to-service communication.

Control plane

The control plane manages tasks such as creating instances and monitoring and executing policies for network management and security. It defines routing rules and policies for traffic management, such as load balancing and security policies, including access control and encryption settings.

Control planes can connect to a command-line interface or a graphical user interface for application management.

Why adopt a service mesh?

An application structured in a microservices architecture might comprise dozens or hundreds of services, all with their own instances that operate in a live environment. It's challenging for developers to keep track of which components must interact, monitor their health and performance, and make changes to a service or component if something goes wrong.

A service mesh enables developers to separate and manage service-to-service communication in a dedicated infrastructure layer. As the number of microservices involved with an application increases, so do the benefits of using a service mesh to manage and monitor them.

Key features of a service mesh

A service mesh framework typically provides many use cases that make containerized and microservices communications more reliable, secure and observable. Service mesh features include the following:

• Reliability. Managing communications through sidecar proxies and the control plane improves efficiency and reliability of service requests, policies and configurations. Specific capabilities include load balancing and fault injection.
• Observability. Service mesh frameworks can provide insights into the behavior and health of services. The control plane can collect and aggregate telemetry data from component interactions to determine service health, such as traffic and latency, performance metrics, distributed tracing and access logs.
• Security. A service mesh can automatically encrypt communications and distribute security policies, including authentication and authorization, from the network to the application and individual microservices. Centrally managing security policies through the control plane and sidecar proxies helps keep up with increasingly complex connections within and between distributed applications.
• Decoupled communication. A service mesh separates the network logic from the application or business logic of individual microservices, ensuring uniform execution and management throughout the entire system.

Service mesh benefits and drawbacks

A service mesh addresses some but not all issues with managing service-to-service communication. It also offers various benefits when used with microservices.

A service mesh offers the following advantages:

• Simplifies communication between services in both microservices and containers.
• Makes it easier to diagnose communication errors because they occur on their own infrastructure layer.
• Supports security features, such as encryption, authentication and authorization.
• Enables faster development, testing and deployment of an application.
• Manages network services effectively by placing sidecars next to a container cluster.
• Enables flexible testing and rollout of new features or services by offering complete service observability across a variety of infrastructure clusters.
• Distributes traffic among several service instances using algorithms such as round robin, least connections or weighted load balancing -- this improves performance and reduces network bottlenecks, while maximizing resource availability, utilization and scalability.
• Distributes services across multiple clusters, enabling DevOps, ITOps and other teams working with applications to gain visibility into the communication patterns and performance across diverse and often geographically dispersed clusters.

Downsides to service mesh include the following:

• Runtime instances increase through the use of a service mesh.
• Each service call must first run through the sidecar proxy, which adds a step.
• Service meshes don't address integration with other services or systems and routing type or transformation mapping.
• Network management complexity is abstracted and centralized but isn't eliminated -- someone must integrate the service mesh into workflows and manage its configuration.
• Deploying a service mesh entails a learning curve for development and operations teams, as they require expertise in understanding its complexities, configuring policies and troubleshooting issues.
• Certain platforms or technologies that are tightly coupled with specific service meshes can have issues with vendor lock-in. Organizations can reduce this risk by using an open source, vendor-neutral program.

Service mesh vs. API gateway

Although a service mesh and an API gateway have a lot in common, they differ in how they operate. Main differences between a service mesh and an API gateway include the following.

Service mesh

• A service mesh mainly handles internal requests sent by one microservice to another within an application. It's responsible for service-to-service communication, often referred to as east-west traffic.
• Common service mesh features include load balancing, service discovery, failure recovery and encryption. A service mesh acts as a centralized infrastructure layer for efficient microservices communication, simplifying tasks such as service discovery and load balancing.
• A service mesh is used alongside most services as a sidecar and operates independently of the business functionality of the services.
• A service mesh provides security capabilities, such as service-to-service authentication and encryption.

API gateway

• An API gateway manages externally initiated requests, such as application user requests to display specific pages. It's responsible for controlling access to internal services when external components and services initiate requests for an application.
• An API gateway provides reverse proxy, load balancing, authentication, authorization, IP listing and rate-limiting functionalities. It hosts all the API services, which have a clearly defined business functionality and are part of the business functionality of the system.
• An API gateway sits between the network edge and the application back end, which can include a service mesh.
• An API gateway offers strong security features and is a core tool for managing critical API functions, such as rate limiting, user authentication, analytics and API traffic control.

The service mesh market

There are numerous commercial and open source service mesh options available. Some are open source or are based in part on open source technology; others are tied to other service mesh platforms. Many are available as software as a service (SaaS) products. The major cloud providers and Kubernetes platform providers offer packaged and hosted service mesh products. The following is an alphabetical list of several providers of service mesh products and services:

• Amazon Web Services. AWS App Mesh is a fully managed service mesh that provides consistent visibility and network traffic controls for services built across multiple types of compute infrastructure.
• Buoyant. Buoyant Cloud is a managed version of Linkerd and is an enterprise-ready distribution of the Linkerd service mesh, which is designed to provide a strong, secure infrastructure for managing microservices in production environments.
• F5. Platform-agnostic Nginx Service Mesh offers flexible traffic management and emphasizes security by ensuring mutual Transport Layer Security-encrypted communication for containerized applications.
• Google. Cloud Service Mesh provides a Google-managed control plane and an optional data plane, handling reliability, upgrades, scaling and security for users.
• HashiCorp Inc. Consul offers service discovery and service mesh capabilities to handle network management in distributed environments. It works with AWS and Microsoft Azure and is also available as a SaaS product.
• Istio. The open source Istio service mesh provided by Google, IBM and Lyft is a universal control plane originally targeted for Kubernetes deployments, but architects can use it on multiple platforms. Its data plane relies on proxies called Envoy sidecars.
• Kong. Enterprise-ready Kong Mesh runs on both Kubernetes and VMs on any cloud.
• Kuma. Kuma, which is an open source project supported and maintained by Kong, is a modern control plane for microservices and service mesh, designed to support both Kubernetes and VMs, while providing an easier path to migrating between the two.
• Linkerd. This open source, multiplatform service mesh developed by Buoyant is built on Twitter's Finagle library. This service mesh supports platforms such as Amazon Elastic Container Service, Docker and Kubernetes.
• Red Hat. Red Hat OpenShift Service Mesh helps developers manage, connect, secure and monitor microservices within an OpenShift Container Platform environment, offering operational control, as well as insights.
• Solo.io. Gloo Mesh, which is built on the Istio platform, is designed to simplify the Istio service mesh for Kubernetes clusters and offers features such as dashboards for health checks, operational insights for troubleshooting, advanced traffic management and security.
• Tetrate. Also based on the Istio platform, Tetrate provides an enterprise-ready, fully upstream distribution called Tetrate Istio Subscription. Additionally, Tetrate's advanced API gateway option efficiently manages, secures and monitors APIs, utilizing Istio service mesh capabilities for improved traffic management and secure communication.
• Traefik Labs. The Traefik Mesh open source service mesh simplifies configuration and offers visibility and management of traffic flows within Kubernetes clusters. It's designed to be nonintrusive and user-friendly, enabling users to identify underutilized resources and overloaded services for optimal resource allocation.
• VMware. Tanzu Service Mesh provides enterprise-grade control and security for microservices, users and data across different clusters and clouds. It supports multiple platforms, public clouds and runtime environments, including Kubernetes.

A service mesh provides significant advantages for large-scale microservices architectures, but it isn't always ideal for simpler systems due to its complexity and steep learning curve. Consider the reasons why a service mesh might not be the best fit for certain scenarios.