Service mesh is a trending technology, but that alone does not mean every organization needs it. As always, adopting a technology should be driven by the goals it helps you attain or, put another way, the problems it helps you solve.
It’s certainly worth understanding what a service mesh does – in part so you can explain it to other people. Whether or not you actually need one really depends upon your applications and environments.
[ Also read: How to explain service mesh in plain English. ]
Brian “Redbeard” Harrington, principal product manager at Red Hat, describes service mesh as a mash-up of several better-known technologies: “A service mesh is a set of software components which act as the ‘glue’ for a set of independent applications. The goal of the mesh is to guarantee secure communications between each application and be able to redirect traffic in the event of failures. Often the features of a service mesh look like a mash-up between a load balancer, a web application firewall, and an API gateway.”
“A service mesh may not be a good fit if your organization’s technology stack is mostly homogenous, and if you need very fine control over how your services communicate,” says Chris Garvey, EVP at 2nd Watch. “In addition, the service mesh itself will itself need to be managed and configured, so organizations must weigh the costs of this responsibility and decide whether it makes sense.”
So if you’re running monolithic applications in a traditional data center, you probably don’t need a service mesh. Ditto if you’ve got an overtaxed team or simply lack of internal technical expertise.
Where service mesh delivers benefits
For a growing number of companies, though, service mesh can be a real problem-solver. The common characteristic of these organizations: They’re running applications in a microservices architecture. As the use of microservices has grown in recent years and will continue to do so going forward, so has the number of teams wrangling with the operational effort required to run them in production – especially as you scale.
“There can be many benefits to [microservices], including easier deployments and testing, and the ability to not be tied to a specific set of technologies, as is normally seen in a larger monolithic application,” Garvey says. “However, this can sometimes lead to additional complexity when microservice authors find themselves solving the same foundational questions regarding how to find and securely communicate with other services, and how to monitor the health and performance of these services.”
“Foundational” is the perfect word choice on Garvey’s part, and this is where service meshes come into play: If you don’t get the answers to those questions right, you’ve got a potential problem (or multiple problems) on your hands. Now you’ve got a real use case, because a service mesh can be the solution.
How service mesh works with microservices
For teams running microservices applications in production, a service mesh can help answer some of those core operational questions in an automated, scalable fashion.
“A service mesh is designed to solve these infrastructure challenges consistently, without duplicating effort across the organization,” Garvey says.
How it does this is commonly referred to as a “sidecar” – a proxy that sits alongside an individual service (hence the motorcycle metaphor) rather than inside of the service.
“With a service mesh, all of your microservices are typically deployed with intelligent proxy servers known as sidecars,” Garvey says. “These sidecars handle all of the network communication between your microservices in a consistent way and can provide tools like service discovery, failure detection/recovery, encryption, logging, monitoring, and authentication.”
5 benefits of service meshes to make your case
As Garvey describes it, it almost sounds like service mesh solves a singular problem. But that’s a whole set of operational needs. If we think in terms of benefits – what you gain by solving or preventing potential problems, for example – they are myriad. This can also help you weigh whether a service mesh is necessary and make the case for the technology. Let’s break down five benefits that a service mesh can deliver.
1. You can take the training wheels off your microservices architecture
For an application with a relatively small number of services, or one that will never grow past a certain point, a service mesh might be extraneous. But to unlock the virtually limitless scale of microservices, it can be a boon – if not a necessity. It is a bridge between experimentation and realizing the potentially massive benefits of microservices that drew you to them in the first place.
“If you’re using microservices, or spending a lot of time writing infrastructure code to address resiliency, security, and observability, it’s worth looking into service mesh,” says Manish Chugtu, CTO of cloud infrastructure and microservices at Avi Networks. “I would go so far as to say that service mesh is a must if you’re running microservices at scale.”
2. Developers get to focus on what they do best
As Chugtu mentions above, it’s possible that you’ve got team members bogged down writing a lot of code to solve the problems that a service mesh could address in a more automated fashion. If that’s the case, a service mesh can be a productivity and efficiency boon. Devs get to focus on the actual application instead of the operational requirements of how its component services communicate.
“In the past, developers had to write infrastructure code to effectively deploy the application, and build libraries in each relevant language to manage service-to-service communication,” Chugtu says. “A service mesh solves many of these problems by providing the tools and functionality to support microservices, allowing developers to focus solely on the application logic.”
In effect, devs get back to what they do best.
“This allows your development teams to focus their time and effort on the services themselves, rather than the network or telemetry,” Garvey says.
What about speed? Let's take a look:
