K
Q

Service Mesh( like Istio) vs Even Driven Architecture of microservices

4/5/2019

Hi Microservices Gurus,

I had a question on service to service communication architecture of Microservices. Istio or any service mesh can make the routing, discovery and resilience of Microservices' communication easy to manage. However, it does not cover important aspects of transactions spanning over more than one Microservice( Kind of distributed transactions) , which is included well in the event based architectures of Microservices. However, apparently, event driven architecture misses the aspects which service mesh covers well. So , was wondering, which is the better approach or there can be a way to mix both -service mesh with event driven architecture to leverage advantages of both patterns. But if that mix is possible, then would the event driven bus (like Kafka) not interfere with internal working patterns of side car proxies/control plane which Istio uses.

-- Pramod Sharma
containers
docker
istio
kubernetes
microservices

Similar Questions

Assign json file to a variable inside loop jinja2 ansible
How to initialize a config file without overwriting mountPath
Rewriting issue with ingress nginx
Configure apiserver to use encryption config using minikube
can not execute linux commands in the image

3 Answers

4/15/2019

your questions is service mesh does not cover important aspects of transactions spanning over more than one Microservice( Kind of distributed transactions) , which is included well in the event based architectures of Microservices, well that is not true. Service Mesh handles well in aspect of distributed microservice communication but service mesh works well to support synchronous RESTful and general request-reply interactions, it doesn’t support asynchronous, event-driven interactions, nor is it well suited for connecting cloud-native microservices with legacy applications. For event driven architecture you have to look system like Event Mesh instead of Service Mesh. Check out the link...

https://solace.com/use-cases/event-mesh/

-- pandasurajify
Source: StackOverflow
4/5/2019

You are mixing up several things.

  • Istio, linkerd etc. addresses some of the fundamental design/architecture issues which come up with cloud native, containerised microservices. e.g. service discovery, circuit breakers etc. Those concerns used to be addressed using libraries which are embedded within application like Spring cloud, hystrix, ribbon etc. Service meshes solve this problem within the paradigm of container world.

But Service meshes do not solve any other inter service data exchange problems which are solved using Kafka or any other message broker. Your microservices can be even driven or not - service mesh will not interfere with that.

-- senseiwu
Source: StackOverflow
9/26/2019

Service Mesh and Event-Driven Architectures like Apache Kafka are complementary and orthogonal:

  • Apache Kafka decouples services, including event streams and request-response
  • Kubernetes provides a cloud-native infrastructure for the Kafka ecosystem
  • Service Mesh helps with security and observability at ecosystem / organization scale
  • Service Mesh frameworks like Envoy and Istio sit in the layer above Kafka and are orthogonal to the goals Kafka addresses

Check out the following material I wrote (blog post, slide deck, video recording) which covers these concepts and the combination of them in much more detail:

Blog Post: Service Mesh and Cloud-Native Microservices with Apache Kafka, Kubernetes and Envoy, Istio, Linkerd

Slide Deck: Kafka, Kubernetes, Envoy and Istio

Video Recording: Service Mesh and Event Driven Architectures like Apache Kafka

-- Kai Wähner
Source: StackOverflow