A service mesh is a technology pattern for managing communication between individual services within a system. When a service mesh is applied, all inter-service communication is routed through proxies, which can be used to implement networking features such as encryption and load balancing.
Service Mesh vs. Microservices: How Do They Compare?
In a microservice architecture, an application is broken up into multiple loosely coupled services that communicate over a network. Each microservice is responsible for a discrete element of business logic. For example, an online shopping system might include individual services to handle stock control, shopping cart management and payments.
Microservices provide several advantages over a traditional, monolithic design. As each service is developed and deployed independently, teams can embrace the benefits of agile practices and roll out updates more frequently. Individual services can be scaled independently, and if one service fails, it does not take the rest of the system down with it.
Service mesh was introduced as a way of managing the communication between the services in a microservice-based system. As the individual services are often written in different languages, implementing network logic as part of each service can duplicate effort. Even if the same code is reused by different microservices, there is a risk of inconsistencies as changes must be prioritized and implemented by each team alongside enhancements to the microservice’s core functionality.
Just as a microservice architecture enables multiple teams to work concurrently on different services and deploy them separately, using a service mesh enables those teams to focus on delivering business logic and not concern themselves with the implementation of networking functionality. With a service mesh, network communication between services within a microservice-based system is implemented and managed consistently.
A service mesh only handles communication between services that make up a system. This is different to an API gateway, which decouples the underlying system from the API that is exposed to clients (which can be other systems within the organization or external clients). The difference between API gateway and service mesh is sometimes characterized as north-south (API gateway) versus east-west (service mesh) communication, but that’s not strictly accurate.
While the service mesh pattern was designed to handle network connectivity between microservices, it can also be applied to other architectures (monolithic, mini-services, serverless) wherever there are multiple services communicating across a network.
How Does a Service Mesh Work?
A service mesh consists of a control plane and a data plane. The data plane is a network proxy replicated alongside each microservice (known as a “sidecar”), which manages all inbound and outbound network traffic on behalf of the microservice. As part of this, it may perform service discovery, load balancing, security and reliability functions. The service and sidecar should be deployed on the same host and – if your deployment is containerized – in the same pod.
The control plane provides an interface to allow you to configure the behavior of the data plane and for the proxies to coordinate their actions. To learn more about how a service mesh works, have a look at Understanding a Service Mesh Architecture.
Setting Up a Service Mesh
Implementing a service mesh involves deploying the proxies that make up the data plane to each instance of a service and deploying a control plane that will provide an interface for configuring the service mesh and allow coordination between the proxies.
The service mesh pattern is not limited to a particular environment or cluster architecture (although some implementations of the pattern are). You can create a service mesh on a single cluster or span a mesh across multiple clusters, regardless of whether services are deployed using containers, virtual machines or bare metal and hosted in the cloud, on premise or a combination of the two. To find out more, see Implementing a Service Mesh.
Using a service mesh to manage communication between the services in your microservice-based application enables development teams to focus on delivering business value while networking concerns – including security, load balancing and logging – are handled consistently across the entire system.
The service mesh pattern evolved in response to the need to manage communications between services across a network. With the rise in popularity and feasibility of cloud native deployments (thanks to container orchestration platforms like Kubernetes), we’re likely to see more and more organizations leveraging the benefits of microservice architectures. As these applications become larger and more complex, decoupling inter-service communication from business logic allows systems to expand faster.
What is a service mesh?
A service mesh is a mechanism for managing communications between the individual services in a microservice-based system. The service mesh decouples the network logic from the application or business logic of each microservice so that it can be implemented and managed consistently across the whole system.
What’s the difference between service mesh and microservices?
Microservices refer to an application that is made up of multiple individual, loosely coupled services rather than a single monolithic system. Each service can be deployed and scaled independently, making for more efficient use of infrastructure. A microservice architecture is ideal for deploying to the cloud using containers. The individual services within the system communicate with each other across a network and may be exposed to the outside world via an API gateway.
A service mesh is a technology pattern that can be applied to a microservice-based system to manage networked communication between services. With a service mesh, the networking functionality is decoupled from the service’s application logic, which means it can be managed independently.
How does a service mesh work?
A service mesh consists of multiple network proxies deployed alongside each instance of a service (the data plane) and a control plane to configure and manage those proxies. To find out more, see Understanding Service Mesh Architecture.
How do you set up a service mesh?
Setting up a service mesh requires a suitable proxy to be deployed to each instance of the services that need to communicate across the network and a separate control plane element to be installed to configure and manage those proxies. To learn more, see Implementing a Service Mesh.