5

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.

Ehsan
  • 265
  • 3
  • 8
Pramod Sharma
  • 376
  • 5
  • 14

3 Answers3

10

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 event driven or not - service mesh will not interfere with that.

senseiwu
  • 5,001
  • 5
  • 26
  • 47
  • Thanks senseiwu but it is all about service to service communication whether it is istio or when Kafka is involved. It is definitely not apple vs oranges comparison, I can see clearly some overlap. Please help me answer one question which is part of this overlap- how will istio know about an event which is placed in Kafka, based on which a service is to be invoked? – Pramod Sharma Apr 05 '19 at 16:52
  • 1
    They are all indeed - but for entirely different purposes, right? Your services interact with Kafka brokers when it has to exchange *domain data* among each other whereas istio only enable you to manage traffic between services. Does this make sense? – senseiwu Apr 05 '19 at 19:09
  • Istio will have no knowledge of the kafka events. – Jocke Apr 05 '19 at 20:10
  • Senseiwu: yes it is domain data when it is Kafka but think one step further.. Service invocation also happens based on the state present in Kafka.. For example, to achieve SAGA pattern, service needs to be invoked for compensating transaction... Don't you think it comes under routing? – Pramod Sharma Apr 06 '19 at 05:22
  • @senseiwu: waiting for your reply on above comment. Your answer may clear my doubt. – Pramod Sharma Apr 08 '19 at 11:10
  • Only your application knows why a transaction has to be rolled back and what logics need to apply etc, istio is agnostic about the causes and effects – senseiwu Apr 08 '19 at 12:07
  • @PramodSharma if my answer helped, feel free to mark it as the right answer, thx. – senseiwu Jul 20 '19 at 21:37
6

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

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
Kai Wähner
  • 5,248
  • 4
  • 35
  • 33
-1

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
  • 24
  • 2