27.08.2020. 17:25 Uhr | Autor: JIT Editor

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:

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:

Weitere Blog

27.08.2020. 17:39 Uhr

Zeebe – Meeting the new kid in town

Autor: JIT Editor

-Zeebe is workflow engine for microservices orchestration developed by Camunda and made publicly available in late 2019.-Wait… what ? -Let’s define first what a workflow engine is, and what the concept of microservices orchestration is all about. Workflow engine Software application that manages business processes. It manages what activities should take place after the completion […]

Blog lesen
27.08.2020. 17:45 Uhr

What are the advantages of taking an official Developers Training? – The Camunda Case.

Autor: JIT Editor

In our branch the ability to bring people to a productive pace is very important and can be a daunting process. The amount of knowledge to be learnt is considerable and a good strategy has to be in place. In the case of JIT, where we pursue that each and every individual reaches a high […]

Blog lesen