Hi everyone,
I intend to implement an architecture based on microservices and I have some questions after reading many articles about best practices.
I’m not a fan of using a same DB to store camunda engine data and model entities so I wondering what architecture is the best for my use case.
I would embed an Engine per microservice. Is it a good way as I want to separate DBs?
Thanks for your awsers !
It’s perfectly find to run each engine with their own data-source if you like, especially in a micro-service architecture.
The only downside would be that you wouldn’t have a cockpit view across your whole architecture.
Thank you @Niall for anwsering.
That means I have to use only one SQL DB for my microservice?
My idea was to use No-SQL for my model entities and use related DB for Camunda. Doing that, make me have two DBs per Microservice and I’m not sure It’s good.
Camunda does indeed require a relational DB - are you planning on storing the entity data in a No-SQL db? that seems find to, but that could certainly be shared across microservices if you wanted.
My model fits well for No-SQL so yes, I’m planning on storing it in No-SQL DB.
In this case, I definitely need to use a shared database for camunda’s engines?
@fabienOuedraogo currently camunda doesn’t support NoSql database support.
https://docs.camunda.org/manual/7.11/introduction/supported-environments/#databases
Thank you @aravindhrs.
I know Camunda doesn’t support NoSQL.
Through my question, I would like to have suggestions for the best architecture to use to fit well the principle of separation for microservice.
You can refer the architecture from docs https://docs.camunda.org/manual/latest/introduction/architecture/
I’m sorry but that’s not give me a satisfied response. I prefer https://blog.bernd-ruecker.com/the-microservice-workflow-automation-cheat-sheet-fc0a80dc25aa even if I don’t know how to mix embedded engine with it’s dedicated DB and dedicated NoSQL for my data model.
Fabien, great to see you on our forums!
Actually it is perfect to run an embedded engine in every microservice that requires Camunda - and every engine has its own relational database. This way you have isolated your microservices (with the price of running multiple engines).
If your own business data lives in NoSQL where is the problem? It simply means that you will have two data stores used from your microservices, SQL for Camunda and NoSQL for business data. That’s actually no problem. You just have to think about transactions a little bit - as the both datasources can’t share a technical ACID transaction.
Are there any specific questions open around that?
Best
Bernd
Thank you for your anwser.
Hi Fabien,
Another approach would be to let BPM and Camunda do the orchestration and let the microservices choose their own datastore what would fits best. You can use the external-task pattern to communicate between the process engine and the microservices. I have written an article about it here https://www.linkedin.com/pulse/find-your-path-death-star-microservices-architecture-van-der-schaaf
sketching the idea.