Image for post
Image for post

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.

Image for post
Image for post

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.

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!

Frank Munz: Will a Service Mesh Become the New Service Bus (AWS EKS, Istio & Envoy)

Here are the slides of my presentation:

Istio with Envoy: Will a Service Mesh become the new Service Bus?

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.


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

Workshop (K8s, Helm, CI/CD, Grafana, Kabana)

AWS EKS Documentation

Istio in Action book

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.

Written by

Technical Evangelist @AWS, twitter @frankmunz. My personal opinions here :-)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store