Im April 2022 hat Camunda mit Camunda 8 ein neues Prozessautomatisierungsprodukt vorgestellt. Damit einher ging die Ankündigung, sich mittelfristig auf dieses fokussieren zu wollen und das bisher in den meisten Unternehmen im Einsatz befindliche Camunda 7 nur noch für ein paar Jahre aktiv weiterzuentwickeln. Wir gucken uns an, was es mit Camunda Platform 8 eigentlich auf sich hat, wie es sich von der bisherigen Camunda Platform 7 unterscheidet und wie sich bestehende Prozessanwendungen möglicherweise migrieren lassen.
Inhalt des Blogbeitrags: |
Was ist passiert?
Nach neun Jahren Camunda 7 wurde im April 2022 die erste neue Major-Version angekündigt: Camunda Platform 8. Anders als vielleicht intuitiv erwartet handelt es sich hierbei nicht um eine nahtlose Weiterentwicklung von Camunda 7, sondern um die neueste Version des bisher als Camunda Cloud bezeichneten Produkts, welches bis dahin noch in Version 1.4 vorlag.
(Grafik angelehnt an an https://camunda.com/blog/2022/04/camunda-platform-8-for-camunda-platform-7-users-what-you-need-to-know/ )
Für Unternehmen, die ihre aktuelle Camunda-Prozessautomatisierungslandschaft noch viele Jahre weiterbetreiben wollten, hat die Ankündigung, die Weiterentwicklung von Camunda 7 nur noch für mindestens weitere fünf Jahre garantieren zu wollen, für Verunsicherung gesorgt. Ein Support darüber hinaus wurde bisher noch nicht festgelegt. Die gleichzeitige Umbenennung der Produktpalette hat nebenher für zusätzliche Verwirrung gesorgt.
Zunächst wollen wir die Produktnamen voneinander abgrenzen und einordnen:
- Das bisherige Produkt "Camunda Platform" (bzw. "Camunda 7", oder ugs. häufig einfach nur "Camunda") heißt ab sofort Camunda Platform 7.
- Camunda Platform 8 ist eine Weiterentwicklung des Produkts "Camunda Cloud", welches auf der eigenentwickelten Zeebe-Process-Engine basiert.
- Camunda Platform 7 und Camunda Platform 8 beinhalten im Kern jeweils eine Process Engine und können genutzt werden, um BPMN-Prozesse zu automatisieren.
- Beide Produkte sind sehr flexible "developer friendly" Lösungen, bei denen Softwareentwickler in die Prozessentwicklung mit einbezogen werden (in Abgrenzung zu sog. Low-Code Suites).
Die wichtigsten Unterschiede zwischen Camunda PLatform 7 & Camunda Platform 8
Engine
Sowohl Camunda 7 wie auch Camunda 8 beinhalten im Kern Process-Engines zur Automatisierung von im Standard BPMN 2.0 notierten Geschäftsprozessen. Die zugrunde liegende Engine ist allerdings jeweils eine andere. Camunda 7 basiert auf den vorhergehenden Camunda-Versionen und damit auf der Activiti-Engine (Camunda war ursprünglich ein Fork des Activiti-Projektes, vgl. https://camunda.com/blog/2022/04/camunda-platform-8-for-camunda-platform-7-users-what-you-need-to-know/). Dagegen nutzt Camunda 8 die Engine Zeebe, eine über die letzten fünf Jahre entwickelte und damit noch recht neue Process-Engine. Sie ist - im Gegensatz zur Camunda 7 Engine - horizontal linear skalierbar und eignet sich daher insbesondere für den Betrieb in der Cloud, um auch Prozesse mit extrem vielen Prozessinstanzen verarbeiten zu können. Anders als Camunda 7 setzt Zeebe nicht auf einer relationalen Datenbank auf, was der wesentliche Flaschenhals für die Skalierung der Engine war.
Architektur und Task-Bearbeitung
Während mit Camunda Platform 7 architekturell - je nach Szenario - verschiedene Formen des Deployments gewählt werden können (Shared Engine, Embedded Engine, Remote Engine), reduziert sich dies bei Camunda 8 auf nur eine Option, die im Wesentlichen der Remote Engine entspricht. In dieser Deployment-Form ist die Bearbeitung von Tasks vollkommen losgelöst von der Process-Engine. Letztere kümmert sich nur noch darum, dass Tasks in der richtigen Reihenfolge bearbeitet werden. Während bei einer Embedded Engine der Code zur Task-Ausführung z. B. als JavaDelegate sehr nah an der Engine läuft, ist die Engine im Remote-Engine-Pattern weiter von der Task-Ausführung entfernt. Sie kümmert sich lediglich darum, dass Tasks in der richtigen Reihenfolge ausgeführt werden, aber nicht darum, wie. Dieses Pattern kennt man vielleicht schon von Camunda 7, wo es als External-Task-Worker-Pattern bekannt ist. In der Tat ist die Prozessautomatisierung in Camunda 8 zunächst einmal sehr ähnlich zur Implementierung in Camunda 7 mit External-Task-Workern (In einem früheren Blogpost zu External-Task-Workern haben wir dieses Pattern bereits ausführlicher vorgestellt). Insbesondere folgt hieraus aber auch, dass die Task-Bearbeitung in Camunda 8 stets asynchron erfolgt, die in Camunda 7 je nach Anwendungsfall durchaus auch synchron sein kann. Einen möglichen Umgang mit dieser Tatsache beschreibt Camunda-Co-Founder Bernd Rücker in Achieving consistency without transaction managers.
Kommunikation
Ein Kern-Aspekt der Anwendungsentwicklung mit Camunda ist die Kommunikation von fachlichem Anwendungscode mit der Process-Engine. Bei Camunda 7 geschieht diese entweder über eine REST-Api oder aber, z. B. bei einer Embedded Engine, direkt über die entsprechende Java-API. Bei Camunda 8 gestaltet sich dies deutlich anders: Die Kommunikation erfolgt nicht mehr direkt mit einer Engine, sondern über das sogenannte Zeebe-Gateway. Dieses verfügt über eine gRPC-API, über welche Prozessinstanzen gestartet oder Tasks zur Bearbeitung abgeholt und abgeschlossen werden können. Da bereits berücksichtigt wurde, dass die meisten Entwickler:innen weniger Erfahrung mit gRPC als z. B. mit REST haben, werden bereits Java- und node-js-Clients für diese API bereitgestellt.
Zusätzlich sind die APIs bei Camunda 8 stärker über die Komponenten verteilt als bei Camunda 7. So gibt es eine eigene API (basierend auf GraphQL) für die Tasklist sowie eine REST-basierte API für Operate, die Camunda-8-Variante des Cockpits, welches zur Ansicht laufender Prozessinstanzen dient.
Camunda Platform 8: Was ist neu hinzugekommen?
Betriebsmöglichkeiten
Camunda 8 ist ein recht komplexes, aus mehreren Komponenten zusammengesetztes Produkt (gut ersichtlich in der folgenden Komponentenübersicht oder im Docker-Compose-File für die lokale Entwicklung) und ausgelegt für den Betrieb auf einem Kubernetes-Cluster. Es gibt durchaus die Möglichkeit, Camunda 8 auf einem eigenen Cluster zu betreiben, auch wenn diese Variante aktuell noch einigen Einschränkungen unterliegt. Auf der anderen Seite kann Camunda 8 als SaaS-Lösung genutzt werden, bei welcher Camunda das Hosting aller Komponenten übernimmt. Mit diesen können sich dann eigene Anwendungen verbinden, um wie oben erwähnt z. B. Tasks zu bearbeiten. Letzteres ist ein Angebot, das es so für Camunda 7 nicht gibt.
(Grafik angelehnt an https://docs.camunda.io/docs/components/)
Konnektoren
Camunda möchte mit Camunda 8 insbesondere auch benutzungsfreundlicher werden und arbeitet darauf hin, dass zumindest an einigen Stellen weniger technisches Know-how benötigt wird, um Prozesse zu automatisieren. Ein Feature des neuen Produkts sind die sogenannten Konnektoren. Diese können genutzt werden, um häufig verwendete Schnittstellen in einer vordefinierten Weise aufzurufen. Hierzu wird im Modeler einem Task ein entsprechender Typ zugewiesen und die notwendige Konfiguration im seitlichen Attribute-Panel vorgenommen. Als Anwendungsfälle hierfür werden generische REST-Calls, aber auch Slack oder AWS-Lambda-Functions genannt, wofür auch bereits vorgefertigte Konnektoren existieren. Mit der im Oktober 2022 veröffentlichten Version 8.1 gibt es jetzt auch grundlegenden Support für die Entwicklung und den Betrieb eigener Konnektoren. (vgl. → https://camunda.com/blog/2022/10/camunda-platform-8-1-released-whats-new/)
Was fehlt (noch) im Vergleich zu Camunda 7?
Camunda 8 ist eine spannende, auf modernen Cloud-Technologien basierende Lösung, aber Camunda 7 hat nach rund einem Jahrzehnt kontinuierlicher Verbesserungen keineswegs ausgedient und kann einige Dinge, die man in Camunda 8 (noch) vermisst.
So werden in Camunda 7 zum Beispiel häufig technische Details eines Prozesses in sogenannten Execution Listeners umgesetzt. Damit müssen eher technische Operationen nicht als Service-Task ausmodelliert werden und das Prozessmodell wird im Sinne des Business-IT-Alignments nicht zu sehr mit technischen Details aufgebläht. In Camunda 8 sucht man die Listener noch vergeblich.
Auch ist der Umfang, in dem der BPMN 2.0-Standard umgesetzt wird, bei Camunda 8 noch deutlich kleiner als bei Camunda 7. Zum Beispiel sind Compensation-Events im Moment ebenso wenig wie Conditional oder Signal-Events nutzbar. Das Transaktions-Verhalten ist ebenfalls deutlich eingeschränkt gegenüber Camunda 7, wo man es noch in Listener-Konstrukten ausnutzen konnte.
Nicht nur der Funktionsumfang in der Prozessautomatisierung und -modellierung ist eingeschränkt, auch die Werkzeuge um die Engine herum sind noch ausbaufähig. Operate - das Camunda 8-Äquivalent zum Cockpit - hat einen merklich eingeschränkten Funktionsumfang. Aktuell gibt es keine Möglichkeit, einmal deployte Prozessdefinitionen zu löschen. Auch ist es nicht möglich, die Ausführung einzelner Prozessschritte kurzfristig zu verhindern. Operate wird allerdings kontinuierlich weiterentwickelt und mit Version 8.1 sind zumindest Möglichkeiten hinzugekommen, Task-Ausführungen neu auszulösen und hängen gebliebene Instanzen zu manipulieren.
Neben der Process-Engine haben einige Organisationen auch Gebrauch davon gemacht, dass Camunda 7 über seine REST-API seine Decision-Engine bereitstellt. Dadurch können DMN-Diagramme und -Tabellen ausgewertet werden, ohne dass diese in einem Prozess referenziert werden müssen. Einen entsprechenden Endpunkt sucht man aktuell vergeblich bei Camunda 8.
Ein weiteres Werkzeug für das erfolgreiche Business-IT-Alignment in DMN-Tabellen fehlt ebenfalls noch in Camunda 8. Gerade wenn DMN-Tabellen komplexe Entscheidungsmodelle auch fürs Business verständlich dokumentieren sollen, steht die Komplexität von FEEL-Expressions manchmal im Weg. Um komplexe verschachtelte Ausdrücke zu vereinfachen, ist es in Camunda 7 möglich, eigene FEEL-Funktionen bereitzustellen, die komplexere Ausdrücke kapseln. Das ist in Camunda 8 aktuell nicht vorgesehen und auch schwierig, in dessen Architektur abzubilden.
Wenn Anwendungsnutzer auf Knopfdruck in einem Frontend BPMN-Prozesse oder DMN-Entscheidungen ausführen können sollen und im Bruchteil einer Sekunde das Ergebnis erwarten, ist Camunda 8 ebenfalls nicht so gut geeignet wie Camunda 7. Die Ausführungszeit einzelner Prozesse ist durch die Asynchronität wesentlich länger und man muss noch einiges an Code drumherum entwickeln, wenn der Service-Konsument eine synchrone Antwort erwartet. Auch dauert es in der SaaS-Variante von Operate aktuell noch länger als im Cockpit von Camunda 7, bis der aktuelle Status eines Prozesses angezeigt wird.
Müssen wir jetzt sofort alles umbauen und migrieren?
Nein. Camunda 7 ist nach wie vor für fast alle Anwendungsfälle ein sehr gutes Produkt und bietet Lösungen für viele Probleme im Bereich der Prozessautomatisierung. Für mindestens 5 Jahre (Quelle) werden auch noch weitere neue Features für Camunda 7 bereitgestellt und es scheint sehr unwahrscheinlich, dass das Produkt direkt im Anschluss abgekündigt wird. Vielmehr ist es realistisch, dass noch für einige Zeit zumindest Sicherheitsupdates nachgereicht werden. Es lohnt jedoch, sich im Rahmen neuer Projekte mit Camunda 8 auseinanderzusetzen, auch wenn ein direkter Umstieg nicht unbedingt notwendig oder möglich ist. So lassen sich viele Camunda 7-Anwendungen bereits so aufbauen und entwickeln, dass sie sich mittelfristig gut migrieren lassen. Einige Hinweise zu möglichen Migrations-Strategien finden sich auch in Camundas Blog. Grundlegend ist die Verwendung des External-Task-Worker-Patterns in Camunda 7. Dieses ist eine gute Vorbereitung für die Migration einer Prozessanwendung zu Camunda 8. Mit weiteren Migrations-Strategien werden wir uns noch in späteren Blogposts auseinandersetzen. An dieser Stelle möchten wir nur schon darauf hinweisen, dass eine Migration nicht trivial ist, was unter anderem an den folgenden Punkten liegt:
- Alle technischen Attribute des BPMN-Modells müssen an die neue Struktur angepasst werden. Ein passendes Desktop-Modeler-Plugin kann hierbei helfen. Es gibt jedoch noch nicht für alle in Camunda 7 genutzten Parameter eine Entsprechung in Camunda 8.
- Prozessanwendungen, in denen Transaktionsgrenzen zur Steuerung des Ablaufs gesetzt werden, müssen individuell betrachtet werden, da es dieses Konstrukt nicht mehr gibt.
- Alle Implementierungen von Listenern müssen durch ein anderes Konstrukt ersetzt werden.
- Der oben erwähnte eingeschränkte Funktionsumfang der BPMN-Elemente erschwert eine Migration.
- Für jede eigene Erweiterung des Cockpits, der REST-API oder anderen Komponenten muss im Vorfeld eine Alternative evaluiert werden
- Der Umstieg von einer Infrastruktur mit klassischem Anwendungsserver und relationaler Datenbank zu Docker/Kubernetes und Elastic erfordert ein anderes Know-how, welches möglicherweise in einem Team noch nicht vorhanden ist.
Welche neuen Herausforderungen ergeben sich mit Camunda 8?
Die Tatsache, dass Camunda 8 anders funktioniert als Camunda 7, bringt einige Fragestellungen mit, für die sich jeweils an die Situation angepasste Lösungen finden werden. Die neuen Konnektoren bieten z. B. spannende Möglichkeiten, um große Teile einer Automatisierung direkt im Modell zu realisieren. Ihr Einsatz führt aber auch dazu, dass Konnektoren in der sogenannten Connector-Runtime und parallel dazu Task-Worker-Anwendungen in einer anderen, selbst betriebenen Umgebung laufen müssen. Hier gilt es, geeignete Deployment- und Test-Strategien zu entwickeln, welche diesen Gegebenheiten gerecht werden.
Operate darf produktiv nur mit einer Enterprise-Lizenz betrieben werden. Für Camunda 7 gibt es zwar einen unterschiedlichen Funktionsumfang des Cockpits je nach Community- oder Enterprise-Version, jedoch gibt es durchaus Kunden, welche mit dem eingeschränkten Funktionsumfang der Community-Version ausgekommen sind oder diesen einfach um eigene Plugins erweitern haben.
Schließlich sei noch gesagt, dass Camunda 7 auf Grund seiner starken Erweiterungsmöglichkeit extrem durch seine Anwender:innen-Community getragen wurde, die diverse Erweiterungen und Modifikationen für das Camunda-7-Ökosystem geschaffen und gepflegt haben. Es bleibt abzuwarten, ob und inwieweit sich eine ähnliche Unterstützung bei Camunda 8 entwickeln wird.
Fazit
Die Kommunikation des neuen Produkts bzw. des neuen Namens hat für einige Verwirrung gesorgt und tut dies auch immer noch. Was wir bisher als Camunda bezeichnet haben, ist jetzt Camunda 7. Klar davon abzugrenzen ist das neue Produkt Camunda 8, welches sich in einigen Punkten grundlegend unterscheidet. Camunda 8 ist nicht komplett neu und hat auch schon entsprechend lange Entwicklungshistorie als Camunda Cloud. Als solches ist es insbesondere für den Cloud-Einsatz sehr gut geeignet und kann z. B. mit Hilfe von Konnektoren helfen, IT-affine Fachanwender an der Entwicklung zu beteiligen. Eine Migration von Camunda 7 auf Camunda 8 ist in vielen Fällen zwar möglich, erfordert aber relevanten zusätzlichen Aufwand und eine individuelle Betrachtung der jeweiligen Situation. Camunda 7 wird noch einige Jahre weiter existieren und kann – als nach wie vor sehr schlagkräftiges Produkt – auch weiterhin eingesetzt werden
Unser Tipp: Die Camunda User Groups Rheinland und Ruhrgebiet
Wenn Sie mehr über Camunda in der Theorie und Praxis erfahren und sich mit anderen Camunda Usern austauschen wollen, dann laden wir Sie herzlich in die Camunda User Groups (CUG) Rheinland und Ruhrgebiet ein. Beide werden von Mitarbeitenden der viadee organisiert und gesponsort. Wir bieten damit zwei regionale Plattformen für Nutzer:innen und Entwickler:innen, die sich mit Camunda BPM und der Modellierungssprache BPMN (und manchmal auch DMN) beschäftigen. In lockerer Runde teilen wir unsere Erfahrungen aus Prozessautomatisierungsprojekten, diskutieren über Good-Practises oder stellen Lösungsansätze zu Herausforderungen vor - gerne auch technisch.
Alle internationalen Camunda Chapter findet ihr auf der Camunda Community Seite.
Die Autoren
zurück zur Blogübersicht
Diese Beiträge könnten Sie ebenfalls interessieren
Keinen Beitrag verpassen – viadee Blog abonnieren
