my understanding is that Zeebe and Operate are complementary from a CQRS perspective.
Zeebe (based on event sourcing) manages/controls the state of the workflow (using append-only log structures), i.e. the write model. Operate on the other hand computes the snapshot by consuming the events emitted by Zeebe (via Elastic).
Now, there might be use cases where processes are implemented as decentralised choreography across multiple services (no central coordinator), and we can’t/don’t want to change that to an orchestrated model by dropping in Zeebe.
But visibility/process monitoring is still important to us. Theoretically, as long as the individual services generate the proper events which are being streamed to Operate, it should be able to provide the overarching perspective.
Essentially, I am referring to slide 22 and 24 of this presentation which indicates that Zeebe can also be used merely for tracking processes even if all processes are using choreography.
My two questions:
- What is the split between Zeebe and Operate (my understanding; Zeebe to manage workflows, Operate to track workflows) ?
- Can I use Zeebe/Operate in a “tracking only” scenario to provide “logical flow visibility” where the micro services are actively listening to events and decentrally executing actions ? All events are available on Kafka.