TL;DR: If you are containerizing your applications, you need to be aware of this “service mesh” architectural pattern to help manage your services.
Gluecon turned out to be all about a microservice concept called a “service mesh” which was being promoted by Buoyant with Linkerd and IBM/Google/Lyft with Istio. This class of services is a natural evolution of the rush to microservices and something that I’ve written microservice technical architecture on TheNewStack about in the past.
A service mesh is the result of having a dependency grid of microservices. Since we’ve decoupled the application internally, we’ve created coupling between the services. Hard coding those relationships causes serious failure risks so we need to have a service that intermediates the services. This pattern has been widely socialized with this zipkin graphic (Srdan Srepfler’s microservice anatomy presentation)
IMHO, it’s healthy to find service mesh architecturally scary.
One of the hardest things about scaling software is managing the dependency graph. This challenge is unavoidable from early days of Windows “DLL Hell” to the mixed joy/terror of working with Ruby Gem, Python Pip and Node.js NPM. We get tremendous acceleration from using external modules and services, but we also pay a price to manage those dependencies.
For microservice and Cloud Native designs, the service mesh is that dependency management price tag.
A service mesh is not just a service injected between services. It’s simplest function is to provide a reverse proxy so that multiple services can be consolidated under a single end-point. That quickly leads to needing load balancers, discovery and encrypted back-end communication. From there, we start thinking about circuit breaker patterns, advanced logging and A/B migrations. Another important consideration is that service meshes are for internal services and not end-user facing, that means layers of load balancers.
It’s easy to see how a service mesh becomes a very critical infrastructure component.
If you are working your way through containerization then these may seem like very advanced concepts that you can postpone learning. That blissful state will not last for long and I highly suggest being aware of the pattern before your development teams start writing their own versions of this complex abstraction layer. Don’t assume this is a development concern: the service mesh is deeply tied to infrastructure and operations.
The service mesh is one of those tricky dev/ops intersections and should be discussed jointly.
Has your team been working with a service mesh? We’d love to hear your stories about it!
Related Reading:
Rob Hirschfeld 