Camunda 7, Camunda 8 und Operaton — wie hängt das zusammen?
Camunda 7 war jahrelang die klassische Java-BPMN-Engine — genau die Codebasis, aus der nach der Lizenzänderung Operaton als offener Community-Fork entstand. Camunda 8 ist dagegen ein eigenständiger Neubau: Statt der klassischen Engine läuft im Kern Zeebe, eine cloud-native, ereignisgetriebene Workflow-Engine, die auf horizontale Skalierung und verteilte Systeme ausgelegt ist.
Betrieben wird Camunda 8 entweder als SaaS (Camunda Cloud) oder selbst gehostet (Self-Managed). Beide Wege spielen praktisch eine Rolle — welcher passt, hängt stark vom Anwendungsfall ab.
Camunda 8 vs. Operaton — wann was?
- Operaton: klassische Java-Engine, unkompliziert per Docker selbst zu hosten, vollständig Apache-2.0-lizenziert — gut für kleinere bis mittlere Lasten und wer volle Kostenkontrolle will.
- Camunda 8 / Zeebe: cloud-native gebaut, für hohen Durchsatz und verteilte Architekturen ausgelegt, verfügbar als SaaS oder Self-Managed. Das Lizenzmodell unterscheidet sich vom rein offenen Operaton-Ansatz — lohnt sich, vor dem produktiven Einsatz genau zu prüfen.
Praxisbeispiel: Ticket-Routing
Der Anwendungsfall „Support-Tickets per KI analysieren & routen" auf dieser Seite ist tatsächlich auf Camunda 8 (Zeebe) modelliert und lauffähig — inklusive Claude als Service Task und der kritisch/unkritisch-Verzweigung per Gateway.
Geplante Inhalte
- Zeebe-Grundlagen: Event-Streaming statt klassischer Prozess-Datenbank
- Deployment-Optionen im Vergleich: Camunda Cloud (SaaS) vs. Self-Managed
- Job-Worker anbinden: das Worker-Pattern mit Zeebe-Clients
- Migration Camunda 7 → Camunda 8 — was sich wirklich ändert