Service mesh is a dedicated, configurable, and low-latency infrastructure layer that is designed to facilitate and handle high volumes of network-based communications between the different parts or services of an app. It is an umbrella term describing products that solve the problems and challenges created by services architecture. These challenges include those related to security, application telemetry, and network traffic control.
A service mesh is made up of network proxies that are paired with each of the application services, as well as with certain task management processes. These proxies are collectively known as the data plane, whose job is to intercept calls between different services and to process these calls. Meanwhile, management processes are also called the control plane, which is referred to as the brain of the service mesh and which coordinates proxy behavior. The control plane also provides application programming interfaces or APIs, which operations and maintenance personnel manipulate and observe the entire network.
Unlike other systems that manage the communication and the sharing of data between different application services, a service mesh is built right into the app. It can document how app services interact, including how well or how poorly they do it, so it is easier to optimize this communication. And when communication is optimized, it becomes easier for an app to avoid downtime as it grows.
The common features that a service mesh provides include load balancing, service discovery, failure recovery, and encryption. It can make service-to-service communication secure, fast, and reliable.
How Does Service Mesh Work?
A service mesh does not introduce new functionality to the runtime environment of an application. After all, apps have always required rules to specify how a request gets from point A to B. Instead, a service mesh takes the logic that governs service-to-service communication out of every service and abstracts it to an infrastructure layer. As such, a service mesh is built into an application as a collection of network proxies.
In a service mesh, the requests are routed between services through proxies in their infrastructure layer. As such, individual proxies comprising a service mesh run alongside each service and not within them. That’s why they are called sidecars.
Also read: Putting Microservices to Work on the Network
Benefits of Service Mesh
A service mesh addresses issues associated with managing communication between services. More specifically:
- It simplifies service-to-service communication in both microservice and container development paradigms.
- It makes it easier to diagnose communication errors since these errors occur on their infrastructure layer.
- It allows for the faster development of applications, as well as faster resting and deployment.
- It supports security features like authentication, authorization, and encryption.
- Proxy instances, also known as sidecars, that are placed next to container clusters are effective in network services management.
Key features of a service mesh include:
- Security. A service mesh can encrypt communications automatically and distribute security policies, such as authorization and authentication, from the network to the app and to all microservices. Being able to handle these security policies centrally via control plane and sidecar proxies will help keep up with growing complex connections between and within distributed applications.
- Observability. A service mesh framework offers insights into each service’s health and behavior. The control plane collects and aggregates telemetry data from component interactions in order to gauge the health of a service, including latency and traffic, access logs, and distributed tracing.
- Reliability. Managing communications via sidecar proxies improves the efficiency and the reliability of certain policies, configurations, and requests. Fault injection and load balancing are also among its specific capabilities.
Service Mesh: Challenges and Drawbacks
A service mesh also has its own share of challenges and downsides. These include:
- Instances of runtime increase.
- It does not address integration with other systems, routing type, transformation mapping, and services.
- Every service call needs to first run through the proxy, which means another step.
- Network management complexity is centralized and abstracted, and somebody needs to integrate it into workflows.
Without a service mesh, developers will have to code every microservice of an app with logic to control and manage service-to-service communication. That means developers will be less focused on their business goals and on the bigger picture. It also means that communication failures and errors will be a lot harder to diagnose and fix because the logic that governs this service-to-service communication is hidden within each part of the app.