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 keine neue Hauptversion von Camunda 7, sondern eine eigene Plattform mit einer anderen Engine, einer anderen API und einem anderen Betriebsmodell.

Wie groß 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 konnte die Engine als Bibliothek in Ihre Anwendung einbetten. Beide liefen im selben Java-Prozess, teilten sich Thread-Pools und konnten 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)

Die Folge, die in Projekten am meisten kostet, steht auf derselben Seite: Sie können keine technische ACID-Transaktion mehr zwischen Ihrem Code und der Engine teilen. Wo Ihre Anwendung sich bisher darauf verlassen hat, dass ein Datenbankschreibvorgang und ein Prozessschritt gemeinsam gelingen oder gemeinsam scheitern, muss dieses Verhalten künftig fachlich nachgebaut werden.

Das ist keine Zeile Konfiguration. Es ist eine Entwurfsentscheidung an jeder Stelle, an der Ihre Anwendung heute stillschweigend von der gemeinsamen Transaktion profitiert, und diese Stellen findet man nicht durch Lesen der Modelle, sondern durch Lesen des Codes.

Was Camunda selbst als Showstopper benennt

Der offenste Absatz in der gesamten Camunda-Dokumentation steht in der Migrations-Checkliste (docs.camunda.io, Migration readiness): „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? Well, you guessed it — 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“ heißt, ist in vielen Fällen einfach das, was eine eingebettete Engine über zehn Jahre erlaubt hat, und es ist genau der Teil Ihres Bestands, den niemand dokumentiert hat. Die ehrliche Konsequenz ist: Der Aufwand einer Migration lässt sich nicht aus der Anzahl Ihrer Prozessmodelle schätzen. Er hängt an Ihrem Java-Code.

Welche Werkzeuge Camunda mitliefert

Camunda dokumentiert für den Weg zu Camunda 8 mehr Werkzeuge als jeder andere Anbieter für seinen eigenen Weg (docs.camunda.io, Migration tooling). 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, nicht die an einen Umzugsdienst: Sie nehmen die mechanische Arbeit ab und lassen die Entscheidungen bei Ihnen.

Lizenz und Produktivbetrieb: der Posten, der übersehen wird

Bei Camunda 7 galt für die Community Edition, dass die gesamte Software unter Open-Source-Lizenzen bereitgestellt wurde, hauptsächlich Apache 2.0 und MIT. Bei Camunda 8 steht der Quelltext der Kernkomponenten unter der Camunda License v1, die kompilierten Artefakte unter einer proprietären Lizenz, und 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 kostenlosen Bibliothek wird eine lizenzpflichtige Plattform plus ein zu betreibender Cluster. Beides zusammen ist eine laufende Kostenposition, nicht nur ein 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. Es gibt zwei Fälle, in denen der Wechsel auf Camunda 8 nicht die naheliegende Entscheidung ist.

Erstens: Sie stehen mit einer Enterprise-Subscription auf 7.24 LTS. Dann läuft die Wartung bis April 2030, Camunda liefert weiter Patches und zertifiziert weiter neue Umgebungen, und es gibt keinen Termin, der Sie zu etwas zwingt. Wer Ihnen in dieser Lage Dringlichkeit verkauft, verkauft Ihnen ein Datum, das es nicht gibt.

Zweitens: Ihre Engine ist tief eingebettet. Dann ist Camunda 8 der teuerste der belegbaren Wege, und die Forks der Community Edition, die dieselbe Bauform behalten, verdienen zumindest eine Prüfung, bevor Sie sich festlegen. 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, nicht an einer allgemeinen Aussage und nicht an einer Vergleichstabelle, unsere eingeschlossen.

Wenn Sie an dieser Stelle noch nicht sicher sind, welches der beiden Produkte bei Ihnen überhaupt läuft: Was ist Camunda? nennt vier Prüfungen, die je unter einer Minute dauern.