Building applications as distributed systems, especially with microservices architecture, is quickly becoming the new norm of software development. Microservices, when used in the right situation, can ensure that your application will be easy to scale, update, and fix. If you aim to create a cloud-native app, then microservices are typically your best choice.
However, when you start looking into distributed applications, one potential problem stands out, and that is the issue of communication between the multiple services in your application. All the advantages that using isolated lightweight services as modular components of your app provides can be overshadowed if the service-to-service communication is slow or faulty. One of the solutions for problems connected with inter-service communication is service mesh implementation. If you are curious about how exactly that works and what service mesh benefits and service mesh challenges are, this article is for you.
How a service mesh works
By definition, a service mesh is an extra layer of application infrastructure that allows you to manage the service-to-service communication. This layer provides multiple capabilities, including flexible load-balancing, resilience mechanisms, service discovery, services observability, and security features like authentication and authorization.
From a technical perspective, a service mesh architecture has two planes, a data plane and a control plane. On the data plane, services communicate via proxies. Typically, there is a proxy instance next to each microservice (a sidecar) deployed on the same host, or the same pod if you are using containers. Sidecar proxies control services communication and gather the telemetry data from that traffic. In this way, development teams can focus entirely on the actual business logic of the individual services they are responsible for. Aspects related to communication, security and observability are left to the service mesh system.
The service mesh control plane coordinates proxies’ configuration and management, while also consolidating the telemetry from the data plane. By interacting with the service mesh control plane, you can, for example, enforce access control or define the rules for traffic routing.
Read our previous article for further explanation of what a service mesh is, its components and features. You can also learn about the differences between the management plane, control plane, and data plane.
Service mesh pros
Choosing service meshes as a solution requires some serious consideration. Application teams dealing with distributed systems know that there are certain problems, typical for that kind of app, that occur from the very nature of an application with multiple different services working independently and communicating through service requests.
Service mesh benefits
The successful functioning of the whole distributed app depends on how efficiently you can solve challenges like service discovery, load-balancing, monitoring, etc. One of the distinct advantages of service meshes is offloading these challenging tasks to the platform layer and improving performance. There are several aspects that profit most from employing a service mesh for managing communications between services.
Reliability
Your application with distributed services can become more reliable thanks to a service mesh. When fault tolerance concerns get offloaded to the service mesh, it becomes easier for your services to concentrate on providing the required business logic.
A service mesh helps to implement protection from overloading like circuit breakers, enforce timeouts on service requests that run for too long, and handle retry requests. As a result, other services can successfully continue working and are not impacted.
The actual development, testing, and deployment processes of your application become more stable with service mesh capabilities. A service mesh allows you to easily set up blue/green and canary deployments, A/B testing, and staged rollouts.
Security
You can make the service mesh responsible for encrypting traffic, controlling access to the service, and authentication. Such techniques as mutual TLS authentication help your security teams protect the communication between services from unauthorized access, service impersonation, or packet sniffing.
DIfferent service meshes provide varying sets of security features, so you can take into account your company’s internal security guidelines or other criteria when you choose a specific service mesh.
Observability
When you make use of sidecar proxies on the service mesh’s data plane, you will get certain metrics from them by default, for example, error counts and request latency. Furthermore, services can forward traces automatically generated by sidecar proxies through the necessary headers, which enhances the visibility of service requests in the system. Also, a service mesh can offer verbose logging capabilities.
Service mesh challenges
A service mesh can make your microservices application more flexible, secure, and observable, but its adoption can also cause certain problems. The very same characteristics of the service mesh that make it attractive can negatively impact your app development and performance.
For instance, adding proxies on the data plane increases the total number of running instances. That means the amount of resources required to run the application, like memory or CPU, increases significantly. It can also make debugging more difficult, because the network traffic going through the proxies creates extra steps, which in some cases can mask the real cause of certain problems.
A service mesh adds an intermediary layer between services, making the app architecture even more complex. The complexity of the solution might lead to an inexperienced team working overtime or having to learn new skills to manage it successfully.
Moreover, a service mesh requires proper configuration. Otherwise, instead of providing additional security, it can become a security risk. And even just finding the optimal commercial or open-source service mesh to meet your business needs will require some research from your security teams, which means more time and effort, and even more financial expenditure.
Even the observability capabilities of a service mesh can prove to be another challenge. The telemetry from a service mesh can be acquired only for the services that the service mesh actually manages, which means that if any services outside your environment take part in the transactions, you won’t get end-to-end visibility.
When do you need a service mesh?
Since a service mesh has such distinct advantages and disadvantages, it is important to understand when exactly your application will benefit from using a service mesh. First of all, you need to analyze the app architecture.
If you have a monolith or only a couple of microservices, and just your own team of developers working on the app, it is likely you don’t need a service mesh. There are other factors that also reduce your need for a service mesh. For example, if you use certain protocols in your application that currently available service meshes don’t support.
If your microservices application continues to grow, the management overhead will become too much at some point. You might notice that your teams spend less time fixing a bug than trying to understand what exactly is happening. If on top of that you use third-party code or collaborate with external teams, it becomes more and more important to have some common ground on which you can build. If your team is practiced in managing service meshes, then it can become a solution you need in this situation. A service mesh can also potentially reduce the management overhead, since it can automatically handle monitoring, load-balancing, and service-to-service communication. For more tips and best practices for microservices, check out our previous article.
Another case when you might consider a service mesh is when your microservices are written in different programming languages, so the library approach won’t be an option. A service mesh provides a solution for that by decoupling the service-to-service communication from the code of your app.
Service meshes are not exclusively used in microservices apps, they can improve the communication between services in applications with other types of architecture too. But you need to keep in mind that in some cases service mesh adoption might not be an ideal solution for your services communication issues, and, moreover, the added complexity of service mesh management might not be worth all the trouble.
Service meshes you can choose from
According to your own company’s security policies and other preferences, you can choose from three types of service mesh products:
- Open-source: Open-source meshes typically don’t have any support service, which means more effort will be required from your team, but you can save some money thanks to the license being free. One of the most popular open-source service mesh products is probably Istio
. - Commercial: Typically, commercial service mesh products are based on open-source options but include support and often some additional tools suitable for enterprise-level solutions. An example of a commercial service mesh is Gloo Mesh , provided by Solo. This mesh is based on the open-source Istio solution.
- Managed: If you are not worried about vendor lock-in, then a managed service mesh might be the solution for you. Using, for example, App Mesh from AWS won’t require such a steep learning curve, but you will have to stick to a specific cloud service provider.
Click here, you get more insights about our network professional services.
Conclusion
Implementing a service mesh might at times seem just a lot of extra work to add another layer to the complexity of your application architecture. However, when the number of microservices in your app increases significantly, you won’t have time and resources to manually manage the communication between services and keep the app secure and reliable.
A service mesh can increase your app stability, help with establishing secure communication between services and load-balancing, and facilitate better testing and failure recovery opportunities. With the large number of existing commercial service mesh products and open-source service meshes available, your development team will always find a suitable solution that will benefit your application.
