Conceptual differences with Camunda 7 and Camunda 8

Conceptual differences

This section does not compare Camunda 7 with Camunda 8 in detail, but rather lists differing aspects important to know when thinking about migration.

No embedded engine in Camunda 8

Camunda 7 allows embedding the workflow engine as a library in your application. This means both run in the same JVM, share thread pools, and can even use the same data source and transaction manager.

In contrast, the workflow engine in Camunda 8, Zeebe, is always a remote resource for your application, while the embedded engine mode is not supported.

If you are interested in the reasons why we switched our recommendation from embedded to remote workflow engines, refer to this blog post.

The implications for your process solution and the programming model are described below. Conceptually, the only big difference is that with a remote engine, you cannot share technical ACID transactions between your code and the workflow engine. You can read more about it in the blog post on achieving consistency without transaction managers.

Different data types

In Camunda 7, you can store different data types, including serialized Java objects.

Camunda 8 only allows storage of primary data types or JSON as process variables. This might require some additional data mapping in your code when you set or get process variables.

Camunda 7 provides Camunda Spin to ease XML and JSON handling. This is not available with Camunda 8, and ideally you migrate to an own data transformation logic you can fully control (e.g. using Jackson).

To migrate existing process solutions that use Camunda Spin heavily, you can still add the Camunda Spin library to your application itself and use its API to do the same data transformations as before in your application code.

Expression language

Camunda 7 uses Java Unified Expression Language (JUEL) as the expression language. In the embedded engine scenario, expressions can even read into beans (Java object instances) in the application.

Camunda 8 uses Friendly-Enough Expression Language (FEEL) and expressions can only access the process instance data and variables.

Most expressions can be converted (see this community extension as a starting point), some might need to be completely rewritten, and some might require an additional service task to prepare necessary data (which may have been calculated on the fly when using Camunda 7).

Different Connector infrastructure

Through Camunda Connect, Camunda 7 provides an HTTP and a SOAP HTTP Connector. Camunda 8 offers multiple Connectors out-of-the-box.

To migrate existing Connectors, consider the following options:

Use the REST protocol Connector to leverage an out-of-the-box Connector.
Create a small bridging layer via custom job workers.

Process solutions using Spring Boot

With Camunda 7, a frequented architecture to build a process solution (also known as process applications) is composed out of:

Java
Spring Boot
Camunda Spring Boot Starter with embedded engine
Glue code implemented in Java delegates (being Spring beans)

This is visualized on the lefthand side of the picture below. With Camunda 8, a comparable process solution would look like the righthand side of the picture and leverage:

Java
Spring Boot
Spring Zeebe Starter (embedding the Zeebe client)
Glue code implemented as workers (being Spring beans)

spring boot

The difference is that the engine is no longer embedded, which is also our latest greenfield stack recommendation in Camunda 7. If you are interested in the reasons why we switched our recommendation from embedded to remote workflow engines, refer to this blog post.

The packaging of a process solution is the same with Camunda 7 and Camunda 8. Your process solution is one Java application that consists of your BPMN and DMN models, as well as all glue code needed for connectivity or data transformation. The big difference is that the configuration of the workflow engine itself is not part of the Spring Boot application anymore.

Process Solution Packaging

Process solution definition taken from Practical Process Automation.

You can find a complete Java Spring Boot example, showing the Camunda 7 process solution alongside the comparable Camunda 8 process solution in the Camunda 7 to Camunda 8 migration example.

Programming model

The programming models of Camunda 7 and Camunda 8 are very similar if you program in Java and use Spring.

For example, a worker in Camunda 8 can be implemented like this (using spring-zeebe):

@JobWorker(type = "payment")
public void retrievePayment(ActivatedJob job) {
  // Do whatever you need to, e.g. invoke a remote service:
  String orderId = job.getVariablesMap().get("orderId");
  paymentRestClient.invoke(...);
}

You can find more information on the programming model in Camunda 8 in this blog post.

note

JUnit testing with an embedded in-memory engine is also possible with Camunda 8, see spring-zeebe documentation.

Camunda deployment

A typical deployment of the workflow engine itself looks different because the workflow engine is no longer embedded into your own deployment artifacts.

With Camunda 7 a typical deployment includes:

Your Spring Boot application with all custom code and the workflow engine, Cockpit, and Tasklist embedded. This application is typically scaled to at least two instances (for resilience)
A relational database
An Elasticsearch database (for Optimize)
Optimize (a Java application)

With Camunda 8 you deploy:

Your Spring Boot application with all custom code and the Zeebe client embedded. This application is typically scaled to at least two instances (for resilience)
The Zeebe broker, typically scaled to at least three instances (for resilience)
An elastic database (for Operate, Tasklist, and Optimize)
Optimize, Operate, and Tasklist (each one is a Java application). You can scale those applications to increase availability if you want.

Camunda 7 vs Camunda 8 Deployment View

Camunda 8 deployments happen within Kubernetes. There are Helm charts available if you want to run Camunda 8 Self-Managed.

Camunda 8 is also available as a SaaS offering from Camunda. In this case, deploy your own process solution and Camunda operates the rest.

note

For local development purposes, you can spin up Camunda 8 on a developer machine using Docker or Docker Compose. Developers could also create a cluster for development purposes in the SaaS offering of Camunda.

Plugins

Process engine plugins are not available in Camunda 8, as such plugins can massively change the behavior or even harm the stability of the engine. Some use cases might be implemented using exporters or interceptors.

note

Exporters are only available for Self-Managed Zeebe clusters and not in Camunda 8 SaaS.

Migrating Desktop Modeler Plugins is generally possible, as the same modeler infrastructure is used.

Cockpit or Tasklist plugins cannot be migrated.

Conceptual differences with Camunda 7 and Camunda 8