While backpacking through Southeast Asia, I picked up one of my favorite phrases in Thai, “same same, but different.” In Thai, words are often repeated to emphasize their meaning, for example, “คล้ายคล้าย” translates to same same. This is a very polite way to say “No, it is not the same, but it doesn’t matter, because it is almost the same.”
In that sense, Camunda Platform and Camunda Cloud are “same same, but different.” You could consider both as languages that use the same letters (BPMN symbols) with some key differences. Same same, but different.
Camunda Platform is the mature Java workflow engine that can be embedded in an application or run as a standalone server, and uses a relational database to store the workflow state.
Camunda Cloud is the new cloud-native, horizontally scalable workflow engine built on stream processing concepts, and uses a replicated append-only event log to store the workflow state.
General differences
There are a few significant differences between implementing a workflow in Camunda Cloud and in Camunda Platform:
- The infrastructure and its maintenance are biggest differences.
- The words “synchronous” and “relational database” don’t exist in the Camunda Cloud universe. In the Camunda Platform universe, you have to make sure you understand database transactions and the database settings of the workflow engine to manage performance and your workflow (like learning grammatical rules). In the Camunda Cloud universe, in contrast, backpressure needs to be managed in the system, along with balance replication and throughput.
- Service orchestration in Camunda Platform can be achieved by using its Java API or the REST API. Camunda Cloud uses gRPC. There are existing clients for Camunda Platform and high-level abstraction clients for Camunda Cloud that can be used to communicate with the engine in your preferred coding languages. So unless you’re writing a new language client, you don’t need to dig deeper into the implementation of gRPC, unless you want to.
Implement
Now that we’ve covered the big differences, let’s look at the ones that are only slightly different, but still have an impact. For example, let’s take a look at the implementation of Service Tasks in both platforms.
Differences in implementing a Service Task
The most common implementations of a BPMN Service Task within Camunda Platform are java delegates (synchronously) or an external task (asynchronously). As mentioned before, the word “synchronous” does not exist within Camunda Cloud – everything happens asynchronously. The implementation of a BPMN Service Task in Camunda Cloud is similar to the concept of external tasks in Camunda Platform. In the Camunda Cloud universe, these are called job workers.
Adding the technical details to your BPMN model is simple in both cases, but it is highly important to define the task item. In Camunda Cloud, this is accomplished by specifying the type. In Camunda Platform, the topic is used for the definition. The left-hand side shows the property panel for the Service Task implementation of Camunda Platform. The right-hand side shows the property panel for the Service Task implementation for Camunda Cloud.
What other technical details are there to add? Let’s have a closer look at the properties panel for both workflow engines.
Retries
Within Camunda Cloud, there is one more field for Retries besides the Type. In general, it’s good to have a retry strategy in mind for service tasks because they connect to a different system by calling it over the network, and therefore not every call may be successful. Often, it can be a network and connection problem. A dependent service or database may not be available to the job worker. Having a number of retries can reduce network errors that show up in your workflow administration tool, like Cockpit or Operate.
The default behavior of Camunda Cloud is to retry every service task three times in a short amount of time. The job executor of Camunda Platform has the same default behavior for failing jobs. Nevertheless, external tasks are not handled by the job executor. Therefore, the retries and the timeout must be managed within the external task worker and the REST call to communicate with the engine. In Camunda Cloud, the Retry field in the Properties Panel of the modeler allows defining the number of retries for each service. At the moment, you cannot schedule retries. A failed service task with remaining retries is immediately available for reactivation by a worker.
For Camunda Platform, there is a community extension that provides a similar feature.
Asynchronous continuation
This grammatical feature in Camunda Platform can be set on each element. External tasks already create a transaction in the engine’s database, so using those flags requires you to understand the transaction behavior well. It would be a bad idea to use the asynchronous before for external tasks while an asynchronous after may make more sense depending on the following symbols and logic in the workflow.
Listeners
What else can be configured? The different tabs in each properties panel provide different options. One handy feature Camunda Platform offers is the usage of Listeners. Listeners are a great way to handle code that should not be represented as a service task within the BPMN model. Therefore, code is needed but should not be represented with a symbol in the BPMN diagram. Listeners can be used on user tasks (created on events related to user tasks) as well as on other BPMN elements (created on events related to the execution of those). Currently, Camunda Platform only allows you to define listeners as Script or Java delegates. As of now, there is no way to configure the listeners as external task workers, though this may be an option in the future.
Moreover, if you only used external tasks as code to connect to Camunda Platform, listeners couldn’t be used. In Camunda Cloud, there are no concepts for listeners yet. Therefore, both platforms don’t currently allow this language feature for external code.
Field Injections
Another tab that is visible for service tasks within the Camunda Platform is Field Injection. This is another feature that is used for Java delegates and does not apply for external task workers. Therefore, it does not differ from the implementation of job workers in Camunda Cloud.
Input/Output mapping
Both platforms support defining variable input and output for service tasks. Input/Output mapping allows you to specify the variables that are used within a task and the variables that are put back into the overall scope of the process. The mapping follows the same concept in Camunda Cloud and Camunda Platform.
Property extensions and headers
Some of the features explained above, like Input/Output mapping and Listeners, use property extensions — this means the XML model that is defined by the BPMN Standard from the OMG is extended. Later, the process engine uses those extensions and the information to execute the logic. There are some property extension elements defined by Camunda that are used frequently.
Additionally, Camunda Platform allows you to specify your own extensions that can be used to define your own execution logic — this can be used to implement your own plugins. For example, if you want to use the External Task Retry Extension, the retry is defined within the property extensions, and from there, the plugin later gets the information from the retry strategy.
Instead of extensions, Camunda Cloud allows defining meta data in Headers. The headers can be used to pass along static metadata to the job worker. Therefore, the same job worker can be used for the implementation of multiple service tasks, but the information in the header can be used to implement the logic of the service task slightly differently. For example, a telegram worker could publish to a specific telegram channel based on the header information. Based on the headers, generic plugins and workers can be built with specialized behavior that is customizable in the BPMN diagram. For example, the Http-Worker for Zeebe.
Same in the end
Ultimately, both Camunda Platform and Camunda Cloud automate your processes — same same, but different.
Similar to learning a new language or visiting new places, I still feel like I’m discovering the nuances of the Camunda Cloud and Camunda Platform workflow engines. I invite you to join me on this journey and explore the possibilities with either option. Who knows, something once foreign to you might just become your favorite.
Automate Any Process, Anywhere
Digital transformation initiatives can’t avoid all potential roadblocks. Learn how to overcome them when they arise.
