Camunda 7 vs. Camunda 8: was sich wirklich ändert

Der wichtigste Satz zu diesem Vergleich stammt von Camunda selbst und steht in der offiziellen Migrationsanleitung: „It is important to understand that Camunda 8 is not a drop-in replacement for Camunda 7.“ Camunda 8 ist eine eigene Plattform mit einer anderen Engine, einer anderen API und einem anderen Betriebsmodell.

Wie gross der Unterschied für Sie ist, hängt an genau einer Frage: Läuft Ihre Engine heute in Ihrer Anwendung oder daneben? Läuft sie daneben, ist der Wechsel ein Projekt. Läuft sie darin, ist er ein Umbau.

Der eine Unterschied, aus dem alle anderen folgen

Camunda 7 erlaubt, die Engine als Bibliothek in Ihre Anwendung einzubetten. Beide laufen dann im selben Java-Prozess, teilen sich Thread-Pools und können dieselbe Datenquelle und denselben Transaktionsmanager benutzen. Für Camunda 8 schreibt die Dokumentation das Gegenteil: „the workflow engine in Camunda 8, Zeebe, is always a remote resource for your application, while the embedded engine mode is not supported.“ (docs.camunda.io, Conceptual differences)

Dieselbe Seite nennt die Folge, konzeptionell „the only big difference“: „with a remote engine, you cannot share technical ACID transactions between your code and the workflow engine.“ Ihre Anwendung verlässt sich vielleicht darauf, dass ein Datenbankschreibvorgang und ein Prozessschritt gemeinsam gelingen oder gemeinsam scheitern. Dieses Verhalten muss dann fachlich nachgebaut werden.

Wo Ihre Anwendung heute stillschweigend von der gemeinsamen Transaktion profitiert, braucht es eine Entwurfsentscheidung. Diese Stellen stecken in Ihrem Code, also findet man sie durch Lesen des Codes.

Was Camunda selbst als Showstopper benennt

Einen bemerkenswert offenen Absatz enthält Camundas Seite zu migrationsbereiten Lösungen (docs.camunda.io, Migration-ready solutions): „Given that Java delegates and the workflow engine are embedded as a library, projects can do dirty hacks in their code. Casting to implementation classes? No problem. Using a ThreadLocal or trusting a specific transaction manager implementation? Yeah, possible. Calling complex Spring beans hidden behind a simple Java Unified Expression Language (JUEL) expression?“ Auch das ist laut Camunda „doable!“

Und der Satz danach: „Those hacks are the real showstoppers for migration, as they cannot be migrated to Camunda 8.“

Lesen Sie das ohne den abwertenden Ton. Was hier „dirty hacks“ heisst, ist in vielen Fällen einfach das, was eine eingebettete Engine über Jahre erlaubt hat. Gut möglich, dass genau dieser Teil Ihres Bestands nirgends dokumentiert ist. Die ehrliche Konsequenz: Die Anzahl Ihrer Prozessmodelle sagt wenig über den Aufwand einer Migration. Ihr Java-Code, in dem diese Muster stecken, bestimmt ihn.

Welche Werkzeuge Camunda mitliefert

Camunda dokumentiert eigene Werkzeuge für den Weg zu Camunda 8 (docs.camunda.io, Migration tools). Die Seite beginnt mit dem Satz: „Camunda is invested in supporting and easing your migration from Camunda 7 to Camunda 8 with migration tools.“ Das ist ein echter Vorteil dieser Option und gehört in jeden fairen Vergleich.

Die richtige Erwartung an diese Werkzeuge ist die an einen Compiler: Sie nehmen die mechanische Arbeit ab und lassen die Entscheidungen bei Ihnen.

Lizenz und Produktivbetrieb: der Posten, der übersehen wird

Für die Community Edition von Camunda 7 schreibt Camunda, dass die gesamte Software unter Open-Source-Lizenzen steht, hauptsächlich Apache 2.0 und MIT. Bei Camunda 8 steht der Quelltext der Kernkomponenten unter der Camunda License v1, die kompilierte Software unter einer proprietären Lizenz. Für den Produktivbetrieb schreibt Camunda: „To use the software in production, purchase the Camunda Self-Managed Enterprise Edition.“ (docs.camunda.io, Licensing)

Für einen Bestand auf der Community Edition ist das die eigentliche Veränderung. Aus einer Open-Source-Bibliothek wird eine Plattform, die im Produktivbetrieb eine Lizenz braucht, dazu ein Cluster, den jemand betreiben muss. Beides zusammen ist eine laufende Kostenposition, zusätzlich zum Projektbudget. Camunda veröffentlicht dazu keinen Preis, und wir veröffentlichen hier auch keinen.

Die Gegenüberstellung, kurz

Wann ein Wechsel nicht die richtige Antwort ist

Wir verkaufen Camunda-7-Migrationen, deshalb dieser Abschnitt ausdrücklich. In den folgenden Fällen ist der Wechsel auf Camunda 8 nicht die naheliegende Entscheidung.

Erstens: Sie stehen mit einer Enterprise-Subscription auf 7.24 LTS. Dann wartet Camunda 7.24 LTS für die Enterprise Edition bis April 2030. Für die Enterprise Edition liefert Camunda weiter Patch-Releases und Environment Update Releases mit neu unterstützten Umgebungen. Kein Termin zwingt Sie zu etwas. Wer Ihnen in dieser Lage Dringlichkeit verkauft, verkauft Ihnen ein Datum, das es nicht gibt.

Zweitens: Ihre Engine ist tief eingebettet. Dann ist der Wechsel auf Camunda 8 der Umbau, von dem oben die Rede ist. Camundas Anleitung sagt dazu: „This effort greatly depends on how your existing Camunda 7 solution is built.“ Die Showstopper oben entstehen aus der eingebetteten Bauform. Die Forks der Community Edition verdienen zumindest eine Prüfung, bevor Sie sich festlegen. Sie stehen nebeneinander in Camunda-7-Forks im Vergleich. Welche Ziele es gibt und woran jedes scheitert, steht in Camunda 7: Wartungsende je Version.

Beide Fälle stellen Sie an Ihrem eigenen Bestand fest. Eine Vergleichstabelle, unsere eingeschlossen, ist dafür nur der Ausgangspunkt. Wird neben Ihrem Bestand ein Prozess noch von Hand erledigt, können Sie diesen Prozess automatisieren lassen, der zwei Wochen nach dem Kickoff-Workshop live ist.

Wenn Sie an dieser Stelle noch nicht sicher sind, welches der beiden Produkte bei Ihnen überhaupt läuft: Was ist Camunda? nennt vier schnelle Prüfungen. Nur für die erste brauchen Sie Zugriff auf Ihren Code.