Was ist Camunda? Ein Name, zwei verschiedene Produkte

Camunda ist heute zwei verschiedene Produkte mit einem gemeinsamen Namen. Camunda 7 ist eine Java-Bibliothek: Die Prozess-Engine läuft in Ihrer eigenen Anwendung, im selben Prozess, oft an derselben Datenbank. Camunda 8 ist eine vollständige Neuentwicklung: Die Engine heißt Zeebe, läuft als eigener Dienst neben Ihrer Anwendung, und Ihre Anwendung spricht sie über das Netz an.

Fast jede Frage, die danach kommt, hängt an dieser einen Unterscheidung: was ein Upgrade kostet, welche Lizenz Sie brauchen, ob Ihr Code weiterläuft, und ob eines der Wartungsdaten Sie überhaupt betrifft. Deshalb steht sie hier vorn und nicht am Ende.

Wer steht hinter Camunda?

Die Camunda Services GmbH mit Sitz in der Zossener Straße 55-58 in Berlin. Für Kunden aus Deutschland, Österreich und der Schweiz ist die Berliner GmbH der Vertragspartner, nach deutschem Recht, mit Gerichtsstand Berlin. Das ist für eine Beschaffungsabteilung in der Schweiz gelegentlich die erste relevante Information über das Produkt.

Camunda 7 heißt in den älteren Unterlagen auch „Camunda BPM“ oder „Camunda Platform 7“. Es ist dasselbe Produkt. Camunda 8 hieß zeitweise „Camunda Platform 8“. Auch das ist dasselbe Produkt.

Camunda 7: eine Engine, die in Ihrer Anwendung läuft

Camunda beschreibt Camunda 7 selbst als Java-Framework, das auf zwei Arten betrieben werden kann: „Camunda can be used both as a standalone process engine server or embedded inside custom Java applications.“ Und weiter: „The embeddability requirement is at the heart of many architectural decisions within Camunda.“ (docs.camunda.org, Architecture)

Die Dokumentation nennt drei Betriebsarten. Welche Sie fahren, entscheidet später darüber, wie teuer ein Wechsel wird.

Nur die dritte dieser drei Formen hat in Camunda 8 eine Entsprechung. Das ist der Kern des ganzen Themas, und es ist der Grund, warum zwei Unternehmen mit derselben Camunda-Version völlig verschiedene Migrationen vor sich haben.

Camunda 8: eine Engine, die neben Ihrer Anwendung läuft

Die Engine von Camunda 8 heißt Zeebe. Camunda beschreibt sie so: „Zeebe is the process automation engine powering Camunda 8. While written in Java, you do not need to be a Java developer to use Zeebe.“ Und zur Architektur: „Zeebe doesn’t rely on a central database“. Die Daten werden über die Broker eines Clusters verteilt, mit Speicherung direkt auf dem Dateisystem des Servers. (docs.camunda.io, Introduction to Zeebe)

Aus einer eingebetteten Bibliothek wird damit ein betriebener Cluster. Das ist kein Nachteil und für viele Lasten ausdrücklich ein Vorteil, aber es ist eine andere Betriebsaufgabe als eine Java-Abhängigkeit, und sie kostet dauerhaft Aufwand, nicht nur einmalig bei der Umstellung.

Neben der Engine gehören zu Camunda 8 weitere Komponenten, unter anderem Operate, Tasklist, Identity, Optimize, die Connectors und der Web Modeler. Bei Camunda 7 heißen die Oberflächen Cockpit, Tasklist und Admin. Die Namen sind der schnellste Weg, eine Screenshot-Frage zu beantworten.

Woran erkennen Sie, welches Camunda Sie betreiben?

Vier Prüfungen, jede in unter einer Minute, keine davon erfordert Zugriff auf ein laufendes System außer der ersten.

1. Die Abhängigkeit in Ihrem Build. Steht dort die Gruppe org.camunda.bpm, etwa org.camunda.bpm:camunda-engine, ist es Camunda 7. Steht dort io.camunda, ist es Camunda 8.
2. Der Name der Oberfläche. Cockpit bedeutet Camunda 7. Operate bedeutet Camunda 8.
3. Die Domain der Dokumentation, die Ihr Team benutzt. docs.camunda.org ist Camunda 7. docs.camunda.io ist Camunda 8.
4. Die Versionsnummer. Alles, was mit 7. beginnt, ist Camunda 7; die letzte Minor-Version ist 7.24. Alles, was mit 8. beginnt, ist Camunda 8.

Wenn Sie Camunda 7 betreiben, ist die nächste Frage die nach Ihrer Minor-Version und Ihrer Edition, denn daran hängen die Wartungstermine. Die vollständige Matrix je Version steht in Camunda 7: Wartungsende je Version.

Unter welcher Lizenz steht Camunda, und was ist daran kostenlos?

Camunda veröffentlicht für keine kommerzielle Variante einen Preis. Was veröffentlicht ist, sind die Lizenzbedingungen. Für Camunda 7 schreibt die Dokumentation zur Community Edition: „If you are using the community edition, the entire software is provided under various open source licenses (mainly Apache 2.0 and MIT).“ (docs.camunda.org, Licenses) Das Repository camunda/camunda-bpm-platform trägt auf GitHub die Apache-2.0-Lizenz und ist inzwischen archiviert.

Für Camunda 8 ist die Lage anders. Der Quelltext der Kernkomponenten steht unter der Camunda License v1, die kompilierte Software unter einer proprietären Lizenz, und die Dokumentation ist an dieser Stelle unmissverständlich: „To use the software in production, purchase the Camunda Self-Managed Enterprise Edition.“ (docs.camunda.io, Licensing)

Für einen Bestand, der Camunda 7 Community Edition jahrelang kostenlos betrieben hat, ist das die unauffälligste und teuerste Zeile im ganzen Vergleich: Aus einer kostenlosen Bibliothek wird eine lizenzpflichtige Plattform. Wir nennen hier keine Zahl, weil es keine veröffentlichte gibt. Was Camunda zur Preisfrage tatsächlich schreibt, und was die Enterprise Edition für dieses Geld liefert, steht in Camunda 7 weiterbetreiben.

Welche Standards deckt Camunda ab?

Camunda 7 implementiert drei Standards der Object Management Group: BPMN 2.0 für Prozesse, DMN für Entscheidungen und CMMN für Fallmanagement (docs.camunda.org, Implemented Standards). Der wichtigste davon ist BPMN, und er ist auch der einzige, den Sie kennen müssen, um bei einer Migrationsentscheidung mitreden zu können. Was BPMN ist und was es ausdrücklich nicht ist, steht in Was ist BPMN?.

Wenn Ihre Antwort Camunda 7 lautet und Sie wissen wollen, was ein Wechsel auf Camunda 8 tatsächlich bedeutet: Camunda 7 vs. Camunda 8 geht die Unterschiede durch, die Camunda selbst dokumentiert.