Camunda BPM and Zeebe

Hi,

We have a new project with high performance requirements and many microservices to orchestrate. We are looking at Camunda BPM and Zeebe now. Zeebe seems to be better for our task, but we are not sure and have some questions.

  1. Why did you decide to make a new product instead of adding new features to Camunda BPM?
  2. Camunda modeler and Zeebe modeler look the same, but the resulting diagrams are different. Why don’t you use one modeler for both products (adding diagram types for example)?
  3. How do you decide when to use Zeebe instead of Camunda BPM?
  4. Can we look at performance tests of Zeebe and Camunda projects?
  5. We stop ALL Zeebe nodes with a scenario in progress. Will it continue to execute after Zeebe nodes start again?

Regards,
Boris

@bi-bobylev hi there… good questions … here are some answers:

1. Why did you decide to make a new product instead of adding new features to Camunda BPM?
They target different tech stacks and different use cases. Zeebe for high frequency / low latency. Completely different architecture, so it was not just adding features to Camunda BPM.

2. Camunda modeler and Zeebe modeler look the same, but the resulting diagrams are different. Why don’t you use one modeler for both products (adding diagram types for example)?
Not all the BPMN elements are supported in the Zeebe Modeler, also some other properties are required in Zeebe.

3. How do you decide when to use Zeebe instead of Camunda BPM?
Depends on the use case, IMO if it is Microservices orchestration in a cloud native platform you should try Zeebe.
4. Can we look at performance tests of Zeebe and Camunda projects?
We are working on that… there are some benchmarks for Zeebe
5. We stop ALL Zeebe nodes with a scenario in progress. Will it continue to execute after Zeebe nodes start again?
Yes totally

2 Likes

For 1, watch this: https://www.youtube.com/watch?v=JbXKgQQmukE

1 Like

Thank you for your answers and links.

It is not clear from the video if Camunda BPM will be replaced by Zeebe in future.
Can you please share your plans on this matter?

Regards,
Boris

There is no plan to do that. Camunda works well in a large number of use-cases. It is mature, embeddable, and has a ton of features.

Zeebe is cloud-native, scalable to degree that Camunda is not, and supports any language that can do gRPC.

2 Likes

@salaboy @jwulf

  1. There is no information about low latency and performance in the video. What did you do to make Zeebe faster?

  2. Camunda BPM does diagram interpretation. And it is much slower than running a precompiled code. How does Zeebe handle with this task?

Native code with no orchestration and no network boundaries will always be faster than code that is orchestrated or that has to invoke other services over the network**.

The trade-off is that you have to put the complexity of the system orchestration somewhere.

In terms of the fastest way to do orchestration, depending on your load you may be better off putting your implementation code in the same JVM as the engine and using Camunda.

But if you have massive streams of data, then you will run into vertical scale problems, and you can’t horizontally scale the JVM or a database for a BPMN engine.

Zeebe uses gRPC for the network protocol. It’s a highly efficient binary protocol over a persistent HTTP2 connection, so there is no connection setup time per request like there is with REST.

You will probably find native code faster and more efficient at low system complexity, and embedded JVM / Database faster at low scale (no network).

It’s when you go to massive scale that database locks and vertical scale limits kick in, and Zeebe is faster. It will never be as fast as hardwired code would be, but BPMN’s value prop is around business agility - the speed at which you can understand and modify your system’s behaviour - not raw execution speed.

Having said that, it could be fast to run the Zeebe broker and the workers on the same machine at a low scale. But it really is designed to scale performance linearly across scale boundaries that Camunda can’t reach, while maintaining visibility at both design and operation time via BPMN.

So Zeebe is faster (and continues to operate) at higher loads than Camunda can because it uses a sharded in-memory database and a replicated append-only event log rather than a traditional RDBMS for its state store, and it’s faster to comprehend and modify your system than hardwired code because of BPMN***.

** Assuming optimal design/configuration.

*** Caveat: Like any tech, you can still make it run slow, or be incomprehensible if you don’t configure/design your system appropriately.

4 Likes

@jwulf @salaboy
Thank you for your answers!

1 Like