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

1 Like

@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.

7 Likes

@jwulf @salaboy
Thank you for your answers!

1 Like

I am in the same situation and we were evaluating Zeebe and Camunda, among others, in my team.
What draws me to Zeebe, besides the modern architecture that would blend in well with our Microservices approach, is:

  • cleaner, more modern API in comparison to Camunda (declarative instead of Java boilerplate code)
  • Spring Boot support with annotations, e.g. for deployment and workers
  • native testing support (through custom rules, even if sadly bound to JUnit 4 still)
  • very fast and lean broker / engine runtime
  • open source core, which makes development and debugging so much easier and more fun
  • even the free monitoring with Simple Monitor and Prometheus/Grafana support is very nice

These advantages alone would make me strongly prefer Zeebe for new projects, even if throughput would not be a priority (we don’t have these scalability requirements, but architecture wise, it’d be a good match).

So it really boils down to the question on how mature Zeebe (API and runtime) already is and if we can rely on it for building our new project.
If full BPMN 2.0 support (on par with Camunda) is achieved, then for me, it does not make much sense to use Camunda anymore, apart from existing projects, even in modest use cases/environments that don’t need the scalability of Zeebe.

I can imagine Camunda phasing out the old workflow engine, providing support and patch releases for existing projects, but pushing the new product that is Zeebe into new projects and focus on the future.

2 Likes

Also this project could be interesting for you if you use Javascript/Typescript

3 Likes

This is a great option for mitigating your risk. If you find when it is time to go live that something is not there in Zeebe yet that you really need, you can deploy on Camunda and still have the option to switch to Zeebe when your dependency is resolved.

1 Like