Since Zeebe uses ElasticSearch in the backend and not all features of ElasticSearch are free, I wonder if a clustered Zeebe setup is still free to use for commercial projects.
From the official pricing info it seems so, is there any experience with operating Zeebe in a clustered environment in a commercial setup?
1 Like
Hi @grexe, ES is one exporter target for Zeebe, not a dependency. So it’s not accurate to say “Zeebe uses ElasticSearch”. It would be accurate to say “Zeebe can export data to ElasticSearch and there is an exporter for that.”
Operate does use ElasticSearch. Operate is not free for production usage. It is free for development and testing environments.
You can use a clustered Zeebe setup in production without paying any licensing fees for Zeebe.
If you want to use Operate in production, you need to contact Camunda for a license.
And you can use both Zeebe and Operate on Camunda Cloud for free in the open beta.
There will be a charge for production usage on Camunda Cloud eventually as well, but the Zeebe/Operate/ElasticSearch will all be managed and with some kind of SLA when that happens.
Thanks for the clarification @jwulf, but what if I don’t use ES exporter and don’t want to use Operate?
Will it the only use the RocksDB and Raft partitions log or where is the state then persisted?
How do you handle rollback/restore if all brokers go down in such a minimalistic scenario?
Current state is persisted in RocksDB in memory and on disk in the append-only log and replicated to other brokers in the cluster.
Something to understand is the exporter is a one-way trip. There is no “restore”. The exported data is for external analysis only.
If all your brokers go down, they will rebuild the running state from the log and snapshot on restart.
If the data center was overrun by Zombies and destroyed by a nuke from the CDC, then you just lost all the running state data - even if you have an export in your underground base in Alaska, exporting is a one-way journey.
Exporters are not “back up mechanisms”, they are “archivers of historical state for data analysis”.
The replicated on-disk log is the back-up of in-memory (running) state.
See also: Multi region fail-over
1 Like
Thanks very much for the detailed and funny answer @jwulf;=)
This explains my open points I still had, was not clear to me re ES/data analysis only.
This greatly simplifies our setup and makes it a lot cheaper to run in production then, because we can share an ES instance and don’t need backup mechanisms for that.
2 Likes