What better time to write this blog post about Camunda 8 than during #CamundaCon 2022? That's exactly what I thought!

In this blog post I want to give a short overview of what Camunda 8 is.

After motivating the topic and looking on the overall architecture, we now want to take a look at the core components of that architecture and start with Camunda 8.

The docs on Camunda 8 a extensive and I will not cover all the aspects here and only focus on the things I used so far. 

What is "Camunda 8"?

To explain that, let me start one step before that and look at "What is Camunda?". Camunda is a globally operating company that created and maintains developer friendly bpmn engines among other things (e.g. a collaborative bpmn modelling solution in a google drive fashion). Being developer friendly and having a great DevRel team, Camunda has developed a huge community that is rather active and very supportive. This is also due to the fact that in general the core parts of Camunda's engine can be used for free.

As in our company we already had teams that used the Camunda 7 engine, our team also looked into it on our journey to the next iteration of our internal automation product. At that time there was a new cloud native bmpn engine being developed at Camunda which is called zeebe. Later down the road zeebe was extended and re-branded to CamundaCloud and than again re-branded to Camunda 8 later on.

The claim of the new engine was, that it is the perfect match for microservice orchestration with the ability to horizontilly scale out as central part of the architecture. Just what we were looking for.

Camunda 7 vs. Camunda 8

There are three major differences between Camunda 7 and Camunda 8:

  1.  the storage of the current worklow state is done in an RDBMS in Camunda 7 while Camunda 8 uses event-sourcing to store events and commands thus enabling the use of the CQRS pattern as the queries are performed against an elasticsearch instance
  2. While in Camunda 7 projects it is rather common to implemnent the business logic right next to the workflow engine, running in the same process, Camunda 8 itself will not execute business logic. It relies on so called "workers" to exceute "jobs". For the sake of completeness, let me mention that Camunda 7 also offers the concept of external tasks, which can be used just like Camunda 8 jobs. 
  3. While Camunda 7 offers a REST api to interact with the engine in Camunda 8 grpc is used which is designed to be scaleable and thus on high load scenarios will scale out better and provide better performance than REST.

 

As our architecture looked for a workflow engine that would ideally be provided as SaaS we went with Camunda 8 naturally.

gRPC api

When communicating with the workflow engine the clients use the gRPC api. Let me try to describe one possible scenario of the order of how commands might be sent to the api, while not using the whole api feature set.

The first thing to do is a DeployResource call in order to deploy one or more bpmn or dmn file(s). This can be done from the cloud or desktop modeler as well as from an app that uses the client sdk. 

After a CreateProcessInstance call for the new process is performed, the workflow engine will let the token enter the start event and from there the first "Service Task" will be activatable by a client using the ActivateJobs api. The next call will be a CompleteJob or a FailJob. This will be done for every Service Task there is in the deployed model.

When a "Receive Task" or a "Message Boundary Event" is modelled the PublishMessage call is being sent to the engine.

zbctl

Whenever you are faced with maintenance work, like killing a batch of broken instances due to a faulty model, zbctl as the CLI for the zeebe engine is your first choice. It is very handy and makes it easy to perform such tasks if you have some CLI experience.

Modeler

There are actually two modellers available:

We use both modelers as we als keep the bpmn files in git and do the dev work on the Desktop version while we collaborate with business on modells using the web variant. Both versions are easy and intuitive to use.

Operate

When you are looking for a quick overview of the state of your workflows, your place to go is "Operate". You will see an overview of your workflows, active process instances and if there are any incidents. It helps a lot for keeping an overview of the state of the processes.

Anyhow there is one feature that we would like to see: RBAC on a process level, so we can let business users access operate, without any fear of "the other department can see my processes' state".

Connectors

A brand new feature in Camunda 8 we are looking forward to use are the "Connectors". We will let Camunda 8 push work to us whenever it is available instead of pulling it using the activate jobs call for a bunch of actions in the future, as this imposing load on the cluster and is rather ineffective.

 

Next time we will look on how we use Apache Camel to interoperate with Camunda 8 as well as with a plethora of other systems.