Compare Flowable Vs Camunda

Flowable Engine
4

Hi,

Thanks for asking this question.
I think that I can say that it’s actually the other way around in regards to performance improvements and general engine improvement.

  1. Camunda was forked from Activiti when we were still doing most of the Activiti engine work and they stayed on the Activiti 5 Engine architecture, while with Flowable we moved on to a new and improved version of the Engine, that we call the v6 engine. It has a lot of advantages over the 5 Engine because every execution and scoped execution is predictable and consistent now with v6. In v5 there are a lot of cases where execution reuse, inconsistent usage of executions for multi instance and parallel and inclusive gateways etc lead to an execution model that is unpredictable and inconsistent. In v6 this has been all refactored to an Engine that creates and deletes executions in a consistent and stable way. Each scope (process instance root, embedded sub process scope, multi instance scope) has its own execution, so that scoped variables are tightly bound to their scope as you would expect. This is just a very brief summary, and there’s a lot more to tell about the v6 Engine improvements.

  2. All the items mentioned in the link you shared were already implemented by Activiti before the Camunda fork. So all these benefits are also present in the Flowable project and have improved there as well.

  3. The Flowable v6 Engine has focused a lot on adding additional performance improvements, like doing counts on an execution and task level for attached jobs, identity links, variables etc to improve the deletion logic of these entities. There’s very smart caching implemented while doing process execution, to make sure that we only execute the SQL statements that are needed. Also, bulk insert and update statements were implemented to improve the performance of inserting lots of variables or activity instances at once in the database. You can have a look here for more performance info https://blog.flowable.org/2018/03/05/flowable-6-3-0-performance-benchmark/

  4. Flowable has an async history manager option that executes the historic data calls asynchronously from the runtime data persistency. In this way you can store the historic data in ElasticSearch for example, but it also improves the performance of the runtime Engine. You can read more about it here https://blog.flowable.org/2018/03/13/async-history-performance-benchmark/

  5. The last point is a personal opinion and that is that in the Flowable project we are very focused on the v6 engine architecture. When we did the first stages of the MongoDB implementation for Flowable (https://github.com/flowable/flowable-engine/tree/mongodb), we used the pluggability on the persistence level of Flowable to implement the MongoDB specific persistence logic. Camunda has made the choice to go with a completely new architecture for the Zeebe project and have to divide their development work between two very different engines. For me this means that with Flowable you have the benefit that our focus is on one Engine implementation and architecture and that all improvements and bug fixes are targeted at this Engine.

Hopefully I’ve been able to express the major differences in the approaches of the two projects and made my opinion clear to you. Let me know if anything is unclear or needs more explanation.

Best regards,

Tijs

4 Likes