Software Development

Service Meshes

Oreon Lothamer
Wednesday, August 31, 2022

For our Eagle Platform, we wanted to incorporate a service mesh to enable service-to-service communication. We evaluated our choices before making a decision based on each service mesh's features and complexity.

We evaluated several service meshes to find one that worked the best for our Eagle Platform.

When designing modern microservice architectures, service-to-service communication is integral. Kubernetes provides basic load-balanced routing through Services, and basic network security through Network Policies (if the Container Network Interface supports them!), but oftentimes this just isn't enough, not to mention it can be challenging to monitor and troubleshoot communication. This is where service meshes come in.

A service mesh was one of the first pieces we wanted to incorporate in our Eagle Platform. The key features we were looking at were:

  • Traffic control
  • Secure communication
  • Metrics, logs, and traces
  • Policy enforcement
  • Ability to extend the service mesh

When looking into service meshes the three names that come up over and over again are Istio, Linkerd, and Consul. There are many sites and blogs out there comparing these service meshes, but the best one I've found is servicemesh.es. All three of these service meshes are very feature rich and have their pros and cons.

Choices, choices, choices...

We like how simple and light weight Linkerd is. Pound for pound it is definitely a strong contender. For us, the limiting factors were not being able to extend the service mesh beyond Kubernetes and the somewhat lesser routing options.

Consul Connect is more complex, but gives us the ability to extend the service mesh to include virtual machines (VMs) and containers outside Kubernetes. When we were first starting Eagle, Consul didn't have an ingress solution, but they have since added an api-gateway. Consul isn't quite as Kubernetes-native, having separate Application Programming Interfaces (APIs) instead of using custom resource definitions (CRDs). It also requires a client running on each node in the cluster.

Istio is the most popular service mesh, and with good reason. It is the most feature rich, including things like rate limiting, fault injection, and delay injection that the others don't. With this, of course, comes added complexity.

Picking one

In the end, it came down to the features Istio provides and the ecosystem around it. We loved all the capabilities it provided but didn't want to lock into the complexity for all projects. We support projects that might have only a handful of services running and don't necessarily need a ServiceMesh.

For Eagle we wanted the capability to leverage all the features of Istio for projects that need them, but didn't want to add complexity and overhead to simple projects that only need the Kubernetes native Service handling. So, we designed the platform around the ability to selectively enable Istio with a single flag. That way we can have the best of both worlds.

Oreon Lothamer
Wednesday, August 31, 2022
Share this story
Follow on Face Book IconFollow on Twitter IconFollow on Linked In Icon
BLOG

Related Stories from our blog

Software Development

We Need to Be Agile

Jim Garner
Wednesday, November 2, 2022
Software Development

Using Tekton for CI/CD

Chris Gibson
Friday, October 7, 2022
Software Development

CI Workflows as Kubernetes First Class Citizens

Oreon Lothamer
Monday, November 22, 2021
View More