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.

Read more in the documentation.

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.

Read more in the documentation.

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.

  • Title slide that reads "Why Camunda 8"

    Why R-KOM Chose Camunda Platform 8

    In this blog series, we highlight the customers who have chosen to utilize Camunda Platform 8 and explore the challenges those companies are attempting to overcome using process orchestration. For the latest installment of Why Camunda 8, we spoke with R-KOM, a telecommunications company based in Regensburg, Germany. When R-KOM was founded in 1997, its shareholders pooled their telecommunications infrastructure, which had evolved over decades with utility networks for water, electricity, and gas. Initially, R-KOM’s services were limited to business and the public sector, but now it has developed further in line with demand. Over the years, the company’s high-performance infrastructure and a broad range of products have grown. Today, R-KOM has a number of city networks in Eastern Bavaria...

    Read more
  • Title slide that reads "Why Camunda 8"

    Why Gruner + Jahr Chose Camunda 8

    In this new blog series, we explore the reasons why customers are migrating to Camunda 8. For our first installment of Why Camunda 8, we talked to Gruner + Jahr, one of the largest premium magazine publishers in Europe. G+J includes such established (German) print and digital brands as STERN, GEO, BRIGITTE, ESSEN & TRINKEN, and SCHÖNER WOHNEN, as well as younger brands such as CHEFKOCH, BARBARA, BEEF, 11FREUNDE. In addition to the numerous print and digital media offerings, G+J offers products and licenses such as the SCHÖNER WOHNEN collection. The digital business contributes more than half of revenues and is exhibiting continued strong growth. Indeed, the company’s digital products lead the rankings in all publishing segments, from news through...

    Read more
  • Camunda Platform 8.1.0-alpha3 Released

    We’re excited to announce the release of Camunda Platform 8.1.0-alpha3. If you’d like to get started with Camunda Platform 8.1.0-alpha3 right away, you can sign up for a free trial now. Create Process Instance Starting at User-Defined Elements An often requested feature is now available as a preview with Camunda Platform 8.1.0-alpha3: create a process instance starting at user-defined elements. When creating a process instance through the CreateProcessInstance RPC, the process instance is started at the default none start event. For testing purposes, you may want to start at one (or multiple) of the other elements. This feature is now available through both the CreateProcessInstance RPC and the CreateProcessInstanceWithResult RPC. It is available for use in the Zeebe Java client...

    Read more

Ready to get started?

Still have questions?