-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:
| Camunda | Zeebe | |
|---|---|---|
| Main architecture | Single engine model | client/server model |
| Workflow definition | Using BPMN 2.0 | Using BPMN 2.0 ² (limited) |
| Storage | Using a database | Using event sourcing |
| Collaboration type | Collaboration / Orchestration of tasks controlled by the engine | Orchestration of microservices by using event streaming |
| Native programming interfaces / technologies | Java API / Rest API / External tasks | Clients 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
