About a year ago I started looking into service meshes, in particular Istio in combination with Envoy proxy. Having spent a decade on and off in service bus projects I wondered how a service mesh could replace the classical service bus that we have been using for more than 10 years now. I have summarised my talk from CODE One 2018 conference in San Francisco in this article, added the presentation (video and slides) as well as further references.
A service bus intercepts your communications and deals with cross cutting concerns such as monitoring, security, versioning, and load balancing of services. Same as a service mesh for microservices.
Coming from monolithic service implementations to the world of microservices, you may wonder if there is any reason left for a monolithic and clustered service bus?
Let me summarise a number of ideas from my presentation:
- A service bus needs to be configured for every service interaction. In contrast, a service mesh, e.g. running on top of Kubernetes allows service invocations without prior configuration. Kubernetes lets you access services directly via their DNS names. This can be restricted with a service mesh, but you do not need to explicitly enable service to service communication with a service mesh.
- A service mesh such as Istio brings some out of the box features which enlighten the fans of chaos engineering. An example is failure injection or added delays for a certain percentage of the invocations.
- The solution of using client libraries to solve cross cutting concerns in service to service communication (such as OSS Hystrix) is limited to a specific programming language and requires changes in your application code. Where as a service bus is language independent and does not require changes in your application code.
- A service mesh has the benefits of both above approaches. It is language agnostic and does not require code changes.
- A service mesh intercepts service to service communication, also so called east-west communication. You still need to carefully architect for north-south communication. I.e. not only place an API-Gateway in front of your mesh, but also carefully plan for the API-management of your customer facing APIs.
The classical VETO pattern (validate, enrich, transform, operate), especially the “T” for transformation that I often see in service bus implementations is not the idea of a service mesh such as Istio and Envoy.
This is mostly due to the fact that microservices don’t replace enterprise-wide integration projects. Sometimes microservices based architectures are described as “dump pipes, intelligent endpoints”, i.e. there is no transformation happening on the on the way to a service invocation.
I don’t claim that a service mesh will be a drop-in replacement for a service bus. If you listen to my presentation, you will learn that I care more about the evolution of software architectures and the reasons behind it.
Please also note the reference section. Since I submitted my presentation, others have published about related topics.
The team at CODE One conference provided a good recording of the event. Thanks!
Here are the slides of my presentation:
My examples shown in the last part of my presentation use open-source Istio with Envoy proxy running on top of AWS EKS. As you might know, AWS supports auto side-car injection and is unforked, upstream Kubernetes with add-on such as the Heptio-Authenticator for mapping IAM roles and the CNI-plugin for using VPC addresses with pods.
Please clap for this article if you enjoyed reading it as much as I enjoyed writing it. I spend way too much time on Twitter, so feel free to connect: @frankmunz.