Building resilient cloud native app with Camunda and K8S


I’m currently evaluating the implementation of an application based on several micro-services and using camunda engine to orchestrate some processes. I’m thinking at the following:

  • build a java application with spring boot and camunda process engine in micro-service A
  • Implement other micro-services B, C…N

The application will be deployed on Kubernetes (K8S) and will need to support deployment of multiple instances of each micro-service on a K8S cluster.
The micro-service A (embedding camunda process engine) will rely on a maria db cluster deployed in the same K8S cluster

My questions are:

  1. can someone confirm that camunda can be used in such context and that it should provide some form of High Availability (assuming the underlying K8S is still operational with some worker nodes alive).
  2. If yes is there a recommended app server TomCat ? Jboss ? WildFly ? Websphere Liberty ? to be used when deploying camunda in docker container to be deployed in K8S env. with HA in mind like in this case here ?
  3. In this context will the cockpit and admin app still be usable running in separate containers/pods ?
  4. Should the micro-service A rely on a persistent volume to read the process definition files
  5. any known limitations ?
  6. any other hints & tips are welcome :slight_smile:


I’m posting here a reply on my own question as after some investigations what I was looking for above is feasible, here is a summary of a preliminary PoC that I performed with another colleague:

  • Implement a Spring Boot (with Tomcat inside) application embedding the Process Engine and packaged in a docker container image (microService A)

  • Implement webapp standalone (Cockpit/Tasklist/Admin) in another docker container image (microsService A-Mgt)

  • Deploy x instances of micro-Service A & y instances of A-Mgt micro-service all connected to a mySQL DB (also deployed on the same K8S cluster)

It works. We have not yet done extensive testing on how resilient it is to container instances crashes or underlying K8S worker node crashes but are confident this is quite a good basis to move forward.

Hope that helps some other folks thinking about using same kind of arch.

1 Like