Pretty new to Camunda products, looking for some direction, hope my question is not a complete duplicate:-/
- We are running a green field microservices environment. All microservices are allocated to bounded contexts and we paid attention to “loose/low coupling and high cohesion”, I.e. making BC’s highly independent & autonomous. Every bounded context controls which API’s to publicly expose outside the BC via a dedicated API gateway
- All microservices expose REST API’s, offering both sync and async execution (in case of async, command messages are dropped onto Kafka and the sync REST response is just a receipt acknowledgement).
- All microservices emit events to Kafka after successful processing. A bounded context contains both atomic capability services (=aggregate centric state machines) and micro orchestrations (which are ideally encapsulated in the BC,I.e. no/limited outbound calls)
- Microservices are idempotent and support distributed sagas by exposing cancellation/compensation interfaces.
Having said that, beyond the “vertical” BC’s, we do have end-to-end business processes which cut across bounded contexts. In order to have visibility as well as clearly separating the capabilities vs the process (for flexibility reasons), we want to introduce cross-cutting orchestrators rather than relying on peer-to-peer choreography.
The target is for these orchestrators to “own” the overarching business process, but to merely submit work items/commands via the async REST interface of the individual services (I.e. no blocking). The orchestrator would then monitor Kafka to detect the events and to trigger the next activity. So in this case, we would need just two layers…the orchestrator and the individual services.
Zeebe looks great and I understand the scalability benefits through logs and event sourcing, but it seems that it requires an additional facade layer between the orchestrator/broker and the individual services. I.e. we would need to implement a job handler for every microservice which would poll the broker and forward “work items” to the service(s). So the trade off seems to be complexity vs scalability. In this case, I would rather compromise on scalability for now, but I am probably missing other aspects.
So in a nutshell, what are the trade offs of Camunda BPM vs Zeebe in an existing microservices environment where the services are decentrally owned/managed by different squads?