Blog

27.08.2020. | Author: Gerardo Manzano

Zeebe – Going into conceptual details

-I thought Camunda and Zeebe are pretty much the same thing
-Well… not quite the same thing, there are some fundamental differences

-You are not talking about the logo, are you ?
-OK, we’ll have to explain things a bit more

What exactly does Zeebe solve?

A common concept in microservices architecture is that each microservice should be responsible for only one business capability. We can see this as workers that are allowed to do one and only one thing, once they are done they wait until they are told to do the same thing again. We can infer that each worker contributes with one step to a broader process.

The following question comes up: who can see where we are at in the broader process? In this case none of the workers. Because of it, the type of architecture described in the example lacks visibility of the process sequence. What is more, if a single worker has a problem, there is no way the other workers know about it, and the process as a whole might be compromised.

This architectural design has very good workers but a troublesome process overview. Now lets rephrase it: Microservices architectures produce very good software at the microservice level, but they lack visibility at a process level, impacting the business outcome. This is clearly a problem and that’s what Zeebe solves¹.

How does Zeebe solve the problem?

To understand how Zeebe tackles the problem, we have to see some of its characteristics.

  • Designed as a distributed system with no central component
  • Using BPMN to explicitly define sequences that span multiple microservices
  • Having event sourcing instead of a central database.
  • Having event streaming for communication between microservices

Let’s see the last two points in detail; normally a workflow stores process states inside a database, with event sourcing process states are seen as “events“. Events are saved inside an append-only log, instead of a database. This log is called topic, the state of the workflow can be derived or sourced from the logs of a topic.

A traditional workflow has an engine as a the main entity, Zeebe has one engine as well, but in reality it follows a client/server model. The server is a broker that saves topics and distributes work items to the clients. The clients are embedded in the actual microservices in order to connect with the broker. The communication happens through a stream. This is event streaming. Through event streaming the broker orchestrates the rest of the microservices, orchestration is a concept known for Camunda users, the difference here is that in Camunda we as well have the concept of collaboration.

This last concept should be familiar for people with experience on Apache Kafka or Apache Pulsar for example. Indeed Zeebe can be integrated into existing microservices solutions. It can subscribe to existing streaming or messaging platforms, then it can correlate the events/messages to predefined sequences modelled with BPMN 2.0 and deployed to the broker(s). We can see in this example that Zeebe can somehow act as a descriptive workflow, meaning, it describes the steps that happened instead of dictating the steps to happen.

To conclude this part, lets think of what we read in the last two paragraphs. We see, Zeebe can be used with or without streaming or messaging platforms, and that is a highlight of the platform.

In what aspects is Zeebe similar or different to Camunda?

After explaining two fundamental concepts we know a great deal of Zeebe, there are more details but for now let’s stop here and compare it against something we are already familiar with, Camunda:

 CamundaZeebe
Main architectureSingle engine modelclient/server model
Workflow definitionUsing BPMN 2.0Using BPMN 2.0 ² (limited)
StorageUsing a databaseUsing event sourcing
Collaboration typeCollaboration / Orchestration of tasks controlled by the engineOrchestration of microservices by using event streaming
Native programming interfaces / technologiesJava API / Rest API / External tasksClients based on gRPC
Two out-of-the-box clients, Java and Go

As we can see the two products have very noticeable differences, which may be few but they set the two products clearly apart. One can of course find uses cases where the two do pretty much the same thing but that depends on opinions, circumstances and decisions.

We can say that choosing Zeebe requires some thinking because it is new, its architecture is suitable for only a range of microservices solutions, and finally it is less mature than Camunda, which is already becoming a standard in process automation. However the characteristics of Zeebe and the fact that microservices are on the rise, makes us think, we will see more of Zeebe in the future. In the upcoming post of this series we will some mode details, current uses of Zeebe, and why people choose it, until then stay curious and stay home.

¹ This architectural model in microservices is one of many, therefore, it is important to keep in mind that Zeebe’s solution is suitable for some situations and not all in the broader microservices universe

² Zeebe currently supports few symbols, such as:

Tasks: service and message receive

Gateways: exclusive, parallel, and event-based

To see the full set of supported symbols visit: https://docs.zeebe.io/bpmn-workflows/bpmn-coverage.html

More Blog articles

04.04.2022.

Maler oder Macher sein

Author: Mirko Pawlak

Digitale Transformation ohne Grenzen. Ich bin Prozessmacher. Ich hocke tief drinnen im Maschinenraum und schau mir an, was das Unternehmen einzigartig macht. Ich tu das gern, denn jeder Prozess ist lebendig und einzigartig. Es gibt einen Anfang, dann passiert etwas und am Ende ist es vorbei. Wie geht man am besten mit seinen Prozessen um? […]

read more
02.12.2021.

How to deploy a Camunda Spring Boot application to a shared application server

Author: Maximilian Kamenicky

Context Do you still remember our Blog: How to deploy a Camunda Spring Boot application to an external application server? In that blog, my colleague Gerardo Manzano Garcia explained the steps necessary to run a spring boot application on a dedicated application server i.e. an external Tomcat. In other words, run the spring boot application […]

read more
15.11.2021.

Ways to integrate Kafka with Databases

Author: Denis Savenko

Kafka is a great instrument. It is widely used in event-driven architectures, and it does the job perfectly fine. However, this is not the only use-case for it. Kafka is also very well suitable for data replication and ingestion use-cases, as well as for building modern ETL or ELT pipelines. The most noteworthy reasons for […]

read more