Whether you resonate with the words cloud-native or not, we all are going microservices. If you aren’t using it already, it’s probably on your roadmap. Once you’ve figured out how your microservices will communicate with each other, you’ll have to start working on controlling and monitoring it. You wouldn’t want rogue microservices bringing your entire platform down right?
I’m not kidding. The super flexibility microservices provides your teams can lead to new services popping up for every little feature in your application. And before you know it, they are out of control.
Changing the API of anyone services could break all its dependency. It’s tough to test such things. And what about the sensitive functionalities? You can’t expose sensitive user information to everyone, right?
To make matters worse, regulations like GDPR, make it increasingly important for you to know and control whats going on in your systems.
Why is this so scary?
I would be lying if I told you this isn’t scary. And let’s face it, security isn’t something we get up in the morning for. Figuring such things out is hard. And it’s even harder at scale.
Luckily, we have a whole new breed of tools which help us greatly simplify it. That’s where service meshes come in.
What’s a Service Mesh?
A service mesh manages network traffic between services.
Simple right?
It’s as straightforward as defining rules and policies on who can talk to whom and that’s it. The service mesh makes sure your rules get enforced.
The way any service mesh works is by intercepting traffic using sidecar proxies like Envoy. All network traffic flows through these proxies.
This gives a service mesh god-like capability to see all communications going on in your system. You could observe the error rates between service to service communications, track the HTTP status codes, measure bandwidth usage and a lot more.
Observability, as the big guys call it, helps you figure out when a new microservice release breaks something in your app or improves performance.
Since traffic is flowing through these sidecars, service meshes can even influence network traffic. It can inject HTTP headers, do automatic retries or even redirect a request based on certain conditions.
This awesome functionality helps you perform crazy things like canary deployments, a/b test easily.
In a nutshell, service meshes help you connect, monitor and secure your services. It’s always a wise decision to use a service mesh when adopting a microservice-based architecture.
Now that we know service meshes are amazing let’s dive into which service mesh should you use.
Which Service Mesh Should I Use?
That’s actually a good question. There are 3 big open-source service mesh players out there: Istio, Linkerd and Consul Connect.
Instead of getting into the technical details of these service meshes, we are going to discuss the use case for each one.
Istio
Istio is by far the most popular open-source service mesh out there. That’s no surprise since tech giants like Lyft, Google and IBM are backing it.
To Istio’s credit, it’s the most flexible and configurable service mesh. It gives you granular knobs to control all aspects of the data plane. But this granularity comes as a slightly steep learning curve.
As compared to the rest, Istio has a lot more concepts to learn before you can try it out. While you can follow its documentation to do most of the essential service mesh tasks there is, most of it won’t make much sense without understanding the various Istio constructs.
Don’t let Istio’s complexity intimidate you. It can be overwhelming at first. But once you’ve spent some time with Istio, it is a powerful asset in your microservice toolbox. There is nothing you can’t do with Istio.
Also, Istio uses Envoy as its sidecar proxy. Envoy is popular and well documented. This is super helpful when you want to dig down on specific metrics which Istio may not provide out of the box.
It’s routing rules are pretty powerful as well. Setting up multi-cluster deployments isn’t that hard with Istio.
When should I use it?
Use Istio when you:
- Want fine-grained service to service authentication and authorization
- Want complete control on traffic routing
- Want a rich metric collection
- Want multi-cloud extensibility
- Used to the Kubernetes way of configuring resources
Linkerd
Linkerd is arguably the second most popular service mesh. If you think Istio has super fancy people backing it, wait till you hear about Linkerd. Linkerd is a Cloud Native Computing Foundation (CNCF) project. CNCF is the same organization which once incubated the Kubernetes project.
With Linkerd 2, it’s experience, and architecture has dramatically improved. Linkerd aims to be a transparent service mesh. It gives you a bunch of benefits of using a service mesh (like authentication, encryption, etc.) out of the box.
You simply need to install it in your Kubernetes cluster. No configurations needed whatsoever. Istio, on the other hand, requires quite a bit of configuration to start seeing similar benefits.
Another cool thing about Linkerd is its ease of use. Just have a look at Linkerd’s tasks documentation. It’s completely straight forward. You don’t need to know any major service mesh concepts to understand what’s going on there.
However, this great experience comes at a cost. You lose out on a lot of configurability which you had with Istio. This shouldn’t be a major problem for smaller clusters. However, for larger multi-tenant clusters, this could be a deal-breaker.
Another engineering decision taken in Linkerd was developing a custom proxy in rust. This rationale behind this was heavily ** customizing the proxy for Linkerd specifically to extract every bit of performance**. However, this also means the Linkerd proxy is more of an internal tool while little to no documentation. This makes it difficult to explore what all metrics can be collected from the service mesh.
When should I use it?
Use Linkerd when you:
- Want to get started with a service mesh in no time and don’t really care about it’s working
- Are working on a single tenant Kubernetes cluster
- Don’t need complex routing rules
- Want a service mesh which doesn’t scare away your team
Consul Connect
Consul Connect is a DIY kind of a service mesh. It’s a part of the popular Hashicorp suite of tools.
An important distinction from Linkerd and Istio is that Consul is first a service discovery and configuration tool. The service mesh was added as an afterthought. Another distinction is that Consul is platform agnostic. You don’t need to run Kubernetes or Nomad to reap the benefits of Consul Connect.
The fact that Consul is also a service discovery tool along with a service mesh means that you have way more control over the environment. You can selectively enable services to be a part of the service mesh. Every configuration option is explicit. If you love to get your hands dirty like me, Consul Connect is a great fit.
But all this explicitness (if that’s a word) means that Consul Connect has the steepest learning curve. It can be really difficult to get started with Consul Connect if you are not sure what you exactly want.
Since Consul Connect is meant to be a platform-agnostic service mesh, your application needs to be actively aware of some networking aspects. For example, each upstream service maps to a local port. To connect to upstream services, you basically connect to localhost on a particular port.
Consul’s integration with Nomad does make running Consul Connect a lot easier. It isn’t a seamless experience as Istio or Linkerd, but it does the job well. Fortunately, Consul Connect uses Envoy as its proxy. So all the benefits that come along with using Envoy apply to Consul as well.
When should I use it?
Use Consul Connect when you:
- Already have a Nomad / Consul cluster running
- Cannot use Kubernetes due to any reason
- Want multi-cloud extensibility
- Love controlling how things work
- Want to learn how service meshed work under the hood
Wrapping up
Services meshes have definitely shown their worth. The industry is seeing a growing adoption of these technologies due to the degree of security and observability they provide.
At SpaceUpTech, we have heavily invested in Istio. I wouldn’t be wrong if I said that our entire stack (apart from the database) is deployed on Kubernetes and Istio.
I understand that this side of the world can be a bit too overwhelming. For this very reason, you can always stop by our Discord Server if you’ve got any questions or want help to get started with service meshes.
