---
layout: docs
page_title: Service mesh
description: >-
  Consul's service mesh provides zero trust networking based on service identities to authorize, authenticate, and encrypt network services. Consul's service mesh can also provide advanced traffic management capabilities. Although there are many similar capabilities between Consul and other providers like Istio, Solo, Linkerd, Kong, Tetrate, and AWS App Mesh, we highlight the main differentiating factors for help customers compare.
---

# Service mesh

A _service mesh_ is a dedicated network layer that provides secure service-to-service communication within and across infrastructure, including on-premises and cloud environments.
Service meshes are often used with a microservice architectural pattern, but can provide value in any scenario where complex networking is involved.

## Benefits of a service mesh

A service mesh provides benefits for all organizations, ranging from security to improved application resiliency.

Review the video below to learn more about Consul service mesh from HashiCorp's co-founder Armon.

<VideoEmbed url="https://www.youtube.com/embed/8T8t4-hQY74"/>

Some of the benefits of a service mesh include:

- service discovery
- application health monitoring
- load balancing
- automatic failover
- traffic management
- encryption
- observability and traceability
- authentication and authorization
- network automation

A common use case for leveraging a service mesh is to achieve a [_zero trust security_ model](https://developer.hashicorp.com/use-cases/zero-trust-networking).
In a zero trust model, applications require identity-based access to ensure all communication within the service mesh is authenticated with TLS certificates and encrypted in transit.

In traditional security strategies, protection is primarily focused at the perimeter of a network.
In cloud environments, the surface area for network access is much wider than the traditional on-premises networks.
In addition, traditional security practices overlook the fact that many bad actors can originate from within the network walls.
A zero trust model addresses these concerns while allowing organizations to scale as needed.

## How does it work?

A service mesh typically consist of a control plane and a data plane. The control plane maintains a central registry that keeps track of all services and their respective IP addresses. This activity is called [service discovery](https://www.hashicorp.com/products/consul/service-discovery-and-health-checking).
As long as the application is registered with the control plane, the control plane will be able to share with other members of the mesh how to communicate with the application and enforce rules for who can communicate with each other.

The control plane is responsible for securing the mesh, facilitating service discovery, health checking, policy enforcement, and other similar operational concerns.

The data plane handles communication between services.
Many service mesh solutions employ a sidecar proxy to handle data plane communications, and thus limit the level of awareness the services need to have about the network environment.

![Overview of a service mesh](/img/what_is_service_mesh\_1.png)

## API gateway vs service mesh

An API gateway is a centralized access point for handling incoming client requests and delivering them to services.
The API gateway acts as a control plane that allows operators and developers to manage incoming client requests and apply different handling logic depending on the request.
The API gateway will route the incoming requests to the respective service. The primary function of an API gateway is to handle requests and return the reply from the service back to the client.

A service mesh specializes in the network management of services and the communication between services.
The mesh is responsible for keeping track of services and their health status, IP address, and traffic routing and ensuring all traffic between services is authenticated and encrypted.
Unlike some API gateways, a service mesh will track all registered services' lifecycle and ensure requests are routed to healthy instances of the service.
API gateways are frequently deployed alongside a load balancer to ensure traffic is directed to healthy and available instances of the service.
The mesh reduces the load balancer footprint as routing responsibilities are handled in a decentralized manner.

API gateways can be used with a service mesh to bridge external networks (non-mesh) with a service mesh.

-> **API gateways and traffic direction:** API gateways are often used to accept north-south traffic. North-south traffic is networking traffic that either enters or exits a datacenter or a virtual private network (VPC). You can connect API gateways to a service mesh and provide access to it from outside the mesh.
A service mesh is primarily used for handling east-west traffic. East-west traffic traditionally remains inside a data center or a VPC.
A service mesh can be connected to another service mesh in another data center or VPC to form a federated mesh.

## What problems does it solve?

Modern infrastructure is transitioning from being primarily static to dynamic in nature (ephemeral).
This dynamic infrastructure has a short life cycle, meaning virtual machines (VM) and containers are frequently recycled.
It's difficult for an organization to manage and keep track of application services that live on short-lived resources. A service mesh solves this problem by acting as a central registry of all registered services.
As instances of a service (e.g., VM, container, serverless functions) come up and down, the mesh is aware of their state and availability. The ability to conduct _service discovery_ is the foundation to the other problems a service mesh solves.

As a service mesh is aware of the state of a service and its instances, the mesh can implement more intelligent and dynamic network routing.
Many service meshes offer L7 traffic management capabilities. As a result, operators and developers can create powerful rules to direct network traffic as needed, such as load balancing, traffic splitting, dynamic failover, and custom resolvers.
A service mesh's dynamic network behavior allows application owners to improve application resiliency and availability with no application changes.

Implementing dynamic network behavior is critical as more and more applications are deployed across different cloud providers (multi-cloud) and private data centers.
Organizations may need to route network traffic to other infrastructure environments. Ensuring this traffic is secure is on top of mind for all organizations.
Service meshes offer the ability to enforce network traffic encryption (mTLS) and authentication between all services. The service mesh can automatically generate an SSL certificate for each service and its instances.
The certificate authenticates with other services inside the mesh and encrypts the TCP/UDP/gRPC connection with SSL.

Fine-grained policies that dictate what services are allowed to communicate with each other is another benefit of a service mesh.
Traditionally, services are permitted to communicate with other services through firewall rules.
The traditional firewall (IP-based) model is difficult to enforce with dynamic infrastructure resources with a short lifecycle and frequently recycling IP addresses.
As a result, network administrators have to open up network ranges to permit network traffic between services without differentiating the services generating the network traffic. However, a service mesh allows operators and developers to shift away from an IP-based model and focus more on service to service permissions.
An operator defines a policy that only allows _service A_ to communicate with _service B_. Otherwise, the default action is to deny the traffic.
This shift from an IP address-based security model to a service-focused model reduces the overhead of securing network traffic and allows an organization to take advantage of multi-cloud environments without sacrificing security due to complexity.

## How do you implement a service mesh?

Service meshes are commonly installed in Kubernetes clusters. There are also platform-agnostic service meshes available for non-Kubernetes-based workloads.
For Kubernetes, most service meshes can be installed by operators through a [Helm chart](https://helm.sh/). Additionally, the service mesh may offer a CLI tool that supports the installation and maintenance of the service mesh.
Non-Kubernetes based service meshes can be installed through infrastructure as code (IaC) products such as [Terraform](https://www.terraform.io/), CloudFormation, ARM Templates, Puppet, Chef, etc.

## What is a multi platform service mesh?

A multi-platform service mesh is capable of supporting various infrastructure environments.
This can range from having the service mesh support Kubernetes and non-Kubernetes workloads, to having a service mesh span across various cloud environments (multi-cloud and hybrid cloud).

## Consul compared to other service mesh software

**Examples**: Istio, Solo Gloo Mesh, Linkerd, Kong/Kuma, AWS App Mesh

Consul is a multi-networking tool that offers a fully-featured service mesh solution that solves the networking and security challenges of operating microservices and cloud infrastructure (multi-cloud and hybrid cloud).
Consul offers a software-driven approach to routing and segmentation. It also brings additional benefits such as failure handling, retries, and network observability.
Each of these features can be used individually as needed or they can be used together to build a full service mesh and achieve [zero trust security](https://www.hashicorp.com/solutions/zero-trust-security).

Consul’s service mesh allows organizations to securely connect and manage their network services across multiple different environments. Using Envoy as the sidecar proxy attached to every service, Consul ensures that all service-to-service communication is authorized, authenticated, and encrypted. Consul includes traffic management capabilities like load balancing and traffic splitting, which help developers perform canary testing, A/B tests, and blue/green deployments. Consul also includes health check and observability features.

Consul is platform agnostic — it supports any runtime (Kubernetes, EKS, AKS, GKE, VMs, ECS, Lambda, Nomad) and any cloud provider (AWS, Microsoft Azure, GCP, private clouds). This makes it one of the most flexible service discovery and service mesh platforms. While other service mesh software provides support for multiple runtimes for the data plane, they require you to run the control plane solely on Kubernetes. With Consul, you can run both the control plane and data plane in different runtimes.

Consul also has several unique integrations with Vault, an industry standard for secrets management. Operators have the option to use Consul’s built-in certificate authority, or leverage Vault’s PKI engine to generate and store TLS certificates for both the data plane and control plane. In addition, Consul can automatically rotate the TLS certificates on both the data plane and control plane without requiring any type of restarts. This lets you rotate the certificates more frequently without incurring additional management burden on operators.
When deploying Consul on Kubernetes, you can store sensitive data including licenses, ACL tokens, and TLS certificates centrally in Vault instead of Kubernetes secrets. Vault is much more secure than Kubernetes secrets because it automatically encrypts all data, provides advanced access controls to secrets, and provides centralized governance for all secrets.