In April 2022, Camunda introduced Camunda 8, a new process automation product. This was accompanied by an announcement. to focus on this product in future.I In the meantime, Camunda 7, which most companies are already using, would continue to be developed for a few more years. We take a look at what Camunda Platform 8 is actually about, how it differs from the previous Camunda Platform 7, and how existing process applications can possibly be migrated.
A German version of this blog post can be found here.
BLOG POST CONTENT: |
WHAT HAPPENED?
After nine years of Camunda 7, the first new major version was announced in April 2022: Camunda Platform 8. Contrary to what might be intuitively expected, this is not a seamless further development of Camunda 7. Instead, it is the latest version of the product previously known as Camunda Cloud, which until then was still available in version 1.4.
(Graphic adapted from https://camunda.com/blog/2022/04/camunda-platform-8-for-camunda-platform-7-users-what-you-need-to-know/)
For companies that wanted to continue operating their current Camunda process automation landscape for many years to come, the announcement that further development for Camunda 7 will only be guaranteed for at least another five years has caused uncertainty. Support beyond that has not been determined yet. The simultaneous renaming of the product range has caused additional confusion along the way.
First, let's distinguish the product names and put them into context:
- The previous product "Camunda Platform" (or "Camunda 7", often simply referred to as "Camunda") is now called Camunda Platform 7.
- Camunda Platform 8 is a further development of the product "Camunda Cloud", which is based on the self-developed Zeebe process engine.
- Camunda Platform 7 and Camunda Platform 8 each contain a process engine at their core and can be used to automate BPMN processes.
- Both products are very flexible, "developer-friendly" solutions, where software developers are involved in the process development (as opposed to so-called low-code suites).
THE MAIN DIFFERENCES BETWEEN CAMUNDA PLATFORM 7 & CAMUNDA PLATFORM 8
ENGINE
At their core, both Camunda 7 and Camunda 8 include process engines for automating business processes modeled in the BPMN 2.0 standard. However, their underlying engines are different. Camunda 7 is based on the previous Camunda versions and thus on the Activiti engine (Camunda was originally a fork of the Activiti project, see https://camunda.com/blog/2022/04/camunda-platform-8-for-camunda-platform-7-users-what-you-need-to-know/). Camunda 8, however, uses the Zeebe engine, a process engine that has been developed over the last five years and is therefore still quite new. In contrast to the Camunda 7 engine, it is scalable both horizontally and linearly. Therefore, it is particularly suitable for operation in the cloud and for the automation processes with a huge number of process instances. Unlike Camunda 7, Zeebe does not rely on a relational database, which was the major bottleneck for scaling the engine.
ARCHITECTURE AND TASK PROCESSING
Whereas with Camunda Platform 7 different forms of deployment can be selected architecturally - depending on the scenario - (shared engine, embedded engine, remote engine), with Camunda 8 this is reduced to just one option, which essentially corresponds to the Remote Engine. In this deployment form, the processing of tasks is completely detached from the process engine. The latter only ensures that tasks are processed in the correct order. While in an embedded engine the code for task execution runs very close to the engine, e.g., as a JavaDelegate, in the remote engine pattern the engine is further away from task execution. It only ensures that tasks are executed in the right order, but not how. You may already know this pattern from Camunda 7, where it is known as the External Task Worker pattern. In fact, process automation in Camunda 8 is initially very similar to the implementation in Camunda 7 with External –Task Workers (We explained this pattern in more detail in a previous blog post on external task workers). In particular, this also means that task processing in Camunda 8 is always asynchronous, while in Camunda 7 it may well be synchronous, depending on the use case. Camunda co-founder Bernd Rücker describes one possible way of dealing with this fact in "Achieving consistency without transaction managers".
COMMUNICATION
A core aspect of application development with Camunda is the communication of custom application code with the process engine. In Camunda 7, this is done either via a REST API or, for example in the case of an embedded engine, directly via the corresponding Java API. With Camunda 8 this is clearly different: Communication no longer takes place directly with the engine, but via the so-called Zeebe gateway. This gateway has a gRPC API that can be used to start process instances or to fetch and complete tasks for execution. Considering that most developers have less experience with gRPC than with REST, clients for e.g. Java and node-js are already available to communicate with this API.
In addition, the APIs in Camunda 8 are more distributed across the components than in Camunda 7. For example, there is a separate API (based on GraphQL) for the task list as well as a REST-based API for Operate, the Camunda 8 variant of the Cockpit, which is used to view running process instances.
CAMUNDA PLATFORM 8: WHAT IS NEW?
OPERATING OPTIONS
Camunda 8 is a rather complex product composed of several components (explained in the component overview below or in the Docker compose file for local development) and designed to run on a Kubernetes cluster. You can definitely run Camunda 8 on your own cluster, even if this option is currently still subject to some restrictions. Alternatively, Camunda 8 can be used as a SaaS solution, where Camunda takes over the hosting of all components. Own applications can then connect to these, e.g., to execute tasks as mentioned above. The latter option does not exist as such for Camunda 7.
(Graphic adapted from https://docs.camunda.io/docs/components/)
CONNECTORS
Camunda also especially wants to become more user-friendly with Camunda 8, and is working towards requiring less technical know-how to automate processes, at least in some areas. One feature of the new product involves are so-called "connectors". These can be used to call frequently used interfaces in a predefined way. To do so, a corresponding type is assigned to a task in the Modeler, and the necessary configuration is made in the attributes panel. Use cases include generic REST calls, as well as Slack or AWS Lambda functions for which ready-made connectors also already exist. With version 8.1 released in October 2022, there is now also basic support for developing and operating your own connectors. (cf. → https://camunda.com/blog/2022/10/camunda-platform-8-1-released-whats-new/)
WHAT IS (STILL) MISSING COMPARED TO CAMUNDA 7?
Camunda 8 is an exciting solution based on modern cloud technologies, but Camunda 7 is by no means outdated, thanks to about a decade of continuous improvements. It can do some things that are (still) missing in Camunda 8.
In Camunda 7, for example, the technical details of a process are often implemented in so-called execution listeners. This means that rather technical operations do not have to be modeled out as service tasks, and the process model is not overly bloated with technical details in the interest of business-IT alignment. In Camunda 8, these listeners are nowhere to be found.
Also, the extent to which the BPMN 2.0 standard is implemented is still significantly smaller in Camunda 8 than in Camunda 7. For example, compensation events are not usable at the moment, nor are conditional or signal events. The transaction behavior is also significantly restricted compared to Camunda 7, where it could still be exploited in listener constructs.
Not only is the functional scope in process automation and modeling limited, but the tools around the engine could also be further expanded. Operate - the Camunda 8 equivalent of Cockpit - has a noticeably limited range of functions. Currently, there is no way to delete process definitions once they have been deployed. It is also not possible to prevent the execution of individual process steps in the short term. However, Operate is under continuous development. Version 8.1 at least includes possibilities to retrigger task executions and manipulate stuck instances.
In addition to the process engine, some organizations have also made use of Camunda 7 to make its decision engine available via its REST API. This allows DMN diagrams and tables to be evaluated without having to reference them in a process. A corresponding end point is still not available in Camunda 8.
Another tool for successful business-IT alignment in DMN tables is also still missing in Camunda 8: Especially when DMN tables are supposed to document complex decision models in a way that is also understandable for business, the complexity of FEEL expressions sometimes gets in the way. To simplify complex nested expressions, Camunda 7 can provide custom FEEL functions that encapsulate more complex expressions. This is currently not provided for in Camunda 8 and is also difficult to map in its architecture.
As for allowing application users to execute BPMN processes or DMN decisions at the push of a button in a frontend and expect the result in a fraction of a second, Camunda 8 is also not as well suited as Camunda 7. The execution time of individual processes is much longer due to asynchrony, and some code must be developed around it if the service consumer expects a synchronous response. Also, it currently takes longer in the SaaS variant of Operate than in the Cockpit of Camunda 7 for the current status of a process to be displayed.
DO WE HAVE TO REBUILD AND MIGRATE EVERYTHING RIGHT NOW?
No. Camunda 7 is still an excellent product for almost all use cases and offers solutions for many process automation problems. For at least 5 years (source) new features will also be provided for Camunda 7, and it seems very unlikely that the product will be discontinued right after that. It is more realistic to assume that at least security updates will be released for some time. However, working with Camunda 8 for new projects is worthwhile, even if a direct switch is not absolutely necessary or possible. Many Camunda 7 applications can already be built and developed in such a way that they can be easily migrated in the medium term. Some guidance on possible migration strategies can also be found on Camunda's blog. The use of the External Task Worker pattern in Camunda 7 is fundamental. This is a good preparation for migrating a process application to Camunda 8. We will deal with other migration strategies in later blog posts. At this point, we would just like to point out that a migration is not trivial, due to the following points, among others:
- All technical attributes of the BPMN model must be adapted to the new structure. A suitable Desktop-Modeler-Plugin can help here. However, there is not yet an equivalent in Camunda 8 for all parameters used in Camunda 7.
- Process applications in which transaction boundaries are set to control the flow must be considered individually, as this construct no longer exists.
- All implementations of listeners must be replaced by another construct.
- The limited functionality of the BPMN elements mentioned above makes migration difficult.
- For each individual extension of the cockpit, the REST API, or other components an alternative must be evaluated in advance.
- Moving from an infrastructure with a classic application server and a relational database to Docker/Kubernetes and Elastic requires a different set of skills that may not yet exist in a team.
WHAT ARE THE NEW CHALLENGES WITH CAMUNDA 8?
The fact that Camunda 8 works differently than Camunda 7 brings some issues that will require solutions adapted to each situation. The new connectors, for example, offer exciting possibilities for implementing large parts of an automation directly in the model. However, their use also means that connectors have to run in the so-called connector runtime and task worker applications have to run in parallel in a different, self-operated environment. The task here is to develop suitable deployment and test strategies that do justice to these circumstances.
Operate may only be used productively with an Enterprise license. For Camunda 7, the functional scope of the cockpit differs between the community or enterprise version. Yet, there are definitely customers who have coped with the limited functional scope of the community version or have simply extended it with their own plug-ins.
Finally, due to its strong extensibility, Camunda 7 has also been carried by its user community, who have created and maintained various extensions and modifications for the Camunda 7 ecosystem. It remains to be seen whether and to what extent similar support will develop with Camunda 8.
CONCLUSION
The announcement of the new product or name has caused and still does cause some confusion. What we used to call Camunda is now Camunda 7. The new product Camunda 8 is to be clearly distinguished from Camunda 7 and differs fundamentally in some points. Camunda 8 is not completely new and has a correspondingly long development history as Camunda Cloud. As such, it is particularly well suited for cloud deployment and can, for example, help to involve IT-savvy business users in development with the help of connectors. Migration from Camunda 7 to Camunda 8 is possible in many cases, but requires substantial additional effort and individual consideration of each situation. Camunda 7 will continue to exist for a few more years and remains a very powerful, usable product.
THE AUTHORS
Dr. Christoph Schönnenbeck has been a consultant at viadee since 2019. His focus is on business process management and process automation, especially in the cloud environment.
Florian Runschke has been a consultant in business access management since 2017. He has worked on different architectures for process automation platforms, is an open source enthusiast, and is always looking for lean solutions to overcome challenges efficiently. He developed the Tooltip-Plugin for the Camunda Modeler.
David Zang has been a consultant for business access management and process automation at viadee since 2017. His focus is on distributed container-based process architectures and process mining.
Back to blog overview
