Hi,
If we containerize the zeebe broker along with application microservices and deploy to kubernetes. Lets say I also want to implement the Istio service mesh on kubernetes.
Istio service mesh provides set of capabilities like authentication, fault tolerance, etc…
Can Zeebe and Istio work together with mix of capabilities?
Hi @shashi, Istio is a suite of capabilities primarily aimed at an HTTP microservices architecture. In your overall system design you may expose an HTTP front-end for initiating actions and consuming responses by external users/consumers of your system. In this case, you could use Istio for this layer.
You could Istio to provide capabilities to your workers - for example “Controlling Egress Traffic” could be used to secure/limit the communication your Zeebe task workers can do with external HTTP services.
Some things are not a good match / have a different application in a Zeebe system. If you look at the examples in the Istio docs (for example: “Traffic Management”), you can see that they show peer-to-peer choreography of services over HTTP.
“Mirroring” is used to send a copy of data to a shadow version of a microservice (like a canary version). This is predicated on requests to your microservices being initiated by an HTTP call in from an initiator. However, in Zeebe, microservices are activated by a gRPC call out from the worker to the broker.
With Istio/HTTP choreography, a microservice (or consumer) calls another service and says: “Do this.”
With Zeebe, the microservice contacts the broker and says: “Got anything for me to do?”
You could use Mirroring on the front-end of your system, and send requests to both version 1 and version 2 of a workflow, triggering both. However, there is at the moment no way to automatically version workers against different versions of a workflow. Workers polling for tasks poll only on task type, not workflow version. And the broker sends tasks to any worker. So you’d have to run two Zeebe brokers / clusters.
Any solution to a problem introduces its own problems, and sometimes you end up spending more energy / time configuring a solution than you would if you had tackled it another way.
It’s a broad space, designed to solve classes of problems. I recommend making a table of scenarios, then solving each scenario using the minimal implementation with Zeebe, then seeing how Istio would work with it.
The best way to get your head around it is to write minimal POCs for each piece, and incrementally build up an appreciation of how to solve problems with Zeebe.
When we evaluated Zeebe, Camunda, and Conductor, we spent a couple of sprints (six weeks), building actual running systems with each. Otherwise the evaluation is purely conceptual - and often has unexamined misconceptions - and the problems that you run into during development are often the devil in the details of implementation…
Or said more succinctly: “Yes, you can. But a better question to ask is: should you do that? (given the problems you need to solve, what your resources are, and how much time/effort it will take)” 