Istio and Envoy: Will a Service Mesh become the new Service Bus?
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?
Key Learnings
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.
Conclusion
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.
References:
Introduction to modern network load balancing and proxying
InfoQ: Microservices in a Post-Kubernetes Era
Getting Started with Istio on Amazon EKS
Introduction to modern network load balancing and proxying
Getting Started with Istio on Amazon EKS
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.
