If you’ve already read the Zeebe 0.12 release announcement, then you know that in addition to significant advancements in BPMN support, Zeebe 0.12 includes changes to the scope of the problem that Zeebe solves and introduces a couple of new concepts.
In this post, we’ll walk through those changes in more detail so that it’s clear what’s different about Zeebe and why we’ve decided to take a different approach.
At a high level, the 0.12 release makes Zeebe a lighter and simpler system that’s more focused on the problems it solves best: large-scale workflow automation. We realized that building Zeebe as a solution for workflow automation and long-term data storage would result in a system that was overly complex, with significant overlap with existing data storage tools.
While Zeebe will no longer provide long-term storage of historic workflow data, we added a new exporter feature that makes it easy to get this data into a storage system of your choice, and we’re including a ready-to-use Elasticsearch exporter in the 0.12 release.
In the rest of this post, we’ll cover the three major conceptual changes in Zeebe 0.12 and explain the reason behind each change. And we updated the documentation to reflect these changes, too, so after each summary, we’ll point you to the section of the docs where you can learn more.
Removal of topics from Zeebe
How it was before 0.12: Zeebe uses multiple dynamically-created partitioned topics for multi-tenancy
How it will be from 0.12 onward: Zeebe is a static, partitioned system without multi-tenancy
Why we made this change: Multi-tenancy inside a system makes it a lot more complex, and there are already well-established systems such as Kubernetes for resource management and isolation. And static systems are much easier to deploy and manage.
Topic subscription is being replaced by Exporters
How it was before 0.12: Zeebe could serve as a long-term data store, and external systems pulled data out of Zeebe as needed.
How it will be from 0.12 onward: Zeebe streams (pushes) historic workflow data to external systems via exporters, and Zeebe will remove data that’s not required for execution of active workflows.
Why we made this change: Many well-established data storage systems already exist, and it’s easy to use these systems with Zeebe. And Zeebe’s ability to provide long-term data storage overlapped heavily with these systems. On the other hand, Zeebe’s ability to do workflow automation at large scale is what makes it unique and compelling, and so that’s what Zeebe will focus on. This makes Zeebe much simpler and narrower in scope, and it also reduces the footprint of a Zeebe cluster.
Introduce RPC Clients and Gateway
How it was before 0.12: Zeebe clients were heavy and complex, with logic duplicated in every different client. There was a complex, multi-layer protocol, and Zeebe clients required access to every broker in the cluster.
How it will be from 0.12 onward: Zeebe clients are thin and “dumb”, and the protocol is defined with gRPC and Protobuf. Clients only require access to a newly-introduced stateless gateway. It should now be easier to build and maintain Zeebe clients in new programming languages.
Why we made this change: Clients in different languages will require much less maintenance, and gRPC and Protobuf are well-established technologies from which Zeebe can benefit. And it’ll now be easier to deploy and properly secure a Zeebe cluster.
Questions or Comments?
These simplifications will allow us to get Zeebe to production readiness more quickly, and we’re excited to be working with a more focused product as we move forward. We expect these changes will also make it easier for contributors to get involved with Zeebe.
If you have questions or comments for us, please see our Community page for all the ways you can get in touch. We hope to hear from you.