I have been looking for an answer on what does community version of camunda 8 looks like and have not got a clear understanding on what that looks like hence looking for some answers from community members if it is clear to anyone.
We currently use Camunda 7 community version as core BPM engine in our platform and have integrated it using events, Elastic search, our own custom UI, our own web modeler etc.
it was not clear to me from demos, summit and blog is what does camunda 8 community product looks like
Is it just going to be open source ZEBEE version?
Is there going to be community version with core zebee engine, web modeler, cockpit/operate etc?
Is camunda 8 is all going to be paid with SAAS or Self managed options?
It would have been great if there were some documentation around what community version of camunda 8 looks like.
core engine for Camunda 8 is the Zeebe engine which is distributed under Source-Available License (basically open-source but without the right to build a Saas Process Automation Solution). This engine is also to be used for the Community Edition.
Operate and Tasklist are available for testing and development in Community Edition, for production, there is a paid license required.
The web modeler is currently not part of the Self Managed Solution. Anyway, you can use the Web Modeler for free in Camunda Cloud.
Currently in Camunda 7 we are not paying for Tasklist / Cockpit. And i have these already running in production in which users are creating filter, monitoring workflows, also adding authorizations (Admin).
Do you think my users can still achieve this in Camunda 8 without a paid license?
Do you have any document stating Community vs Enterprise for Tasklist / Cockpit
@camunda@jonathan.lukas It would help if we can have a table comparing Camunda 7 features vs camunda 8 from community perspective and as well enteprise vs community in camunda 8 Something like what you had in Camunda 7 community vs enterprise Camunda Platform 7 Enterprise Edition - Camunda
Hello @camundaSM , i am reading these posts and would be interested very much in the same comparison of Camunda 7 features vs camunda 8 from community perspective and as well enteprise vs community in camunda 8. But the thread did run dead?
@Niall Here is something I had listed for my own knowledge
Something that can be validated by your team and updated accordingly for more accuracy
Camunda 7
Camunda 8
1
Core Process Engine
Standalone Remote or embedded process Engine
Run complete camunda process engine in individual servers >2 behind load balancer with shared database
Zeebe has built in clustering with default 3 nodes in cluster
2
Webapp or User Interface
cockpit for process and task level monitoring and operational dashboards
Task list to start process, Manage tasks, create task filters etc
Process level views to manage process definition and process instancesÂ
Cockpit provides basic process and task level dashboardÂ
Webapp(Optimize, tasklist and operate) are paid and not free in community editionÂ
However these are free in DEV and nonprod environments for free
Incident management through operate
Operational dashboards in Optimize
3
Modelling(BPMN, DMN and Forms) - Design time
Supports only Desktop modeler
No version management or collaborationÂ
Extensive support of BPMN 2.0 notations
Supports Web modeler(Paid) and as well as Desktop modeler(Community)
Version management and collaboration on BPMN/DMN/FORMS for better design experience
Does not support few BPMN 2.0 concepts like script task, few event gates etc
4
Modelling(BPMN, DMN and Forms) - Deploy time
Can be done via REST API or from Modeler in case of Remote Engine
In case of Springboot embeded all models needs to be placed in resources folder
Deploy models using grpc or desktop modeler and run using external task
Can be deployed via new web modeler as well
5
Tasklist - Task Management and monitoring - Runtime
6
Process Management and Monitoring - Runtime
7
Process engine Deployments
Allows us to define the configuration and customize the process engine configurationÂ
Single package deployment either with embeded springboot or tomcat distribution or as base docker image
SAAS Offering :Â Leverages Camunda cloud Engine is deployed to kubernetes using helm charts provided by Camunda team
Self Managed Deployment custom helm charts and kubernetes configs provided by camunda team post purchasing license. Limited option to customize or overwrite the default settings
Everything is deployable as docker image and no integration to J2EE servers like tomcat
8
API integrationÂ
Provides REST API endpoints and open API spec documentation around all APIs so all types of client(Node JS, Python, Java etc) can invoke these endpointsÂ
Does not support REST but does support gRPC and hence client needs to generate the code to invoke Engine APIs
9
Engine Plugins
Allows to customize process engine behavior before or after engine initializationÂ
Process engine can be customized in zeebe using exporter functionality but it is very limited
10
Connectors
Supports HTTP and SOAP connectors along with you can also extend connectors
Supports REST and SEND Grid Connectors(Email)
Cloud ConnectorsÂ
Example : Kafka, SQS, Apache Camel, AWS Lambda, Event Bridge
Service Connectors
Example : RPA, AI, IOTÂ
Content Connectors
Example : Open Test
Data Connectors
Example : BI systems, Datalakes or data ware houseÂ
11
Operational dashboard and Search- Runtime View
12
Process and task events - Runtime
13
Authentication - Design/Runtime
14
Authorization - Design/Runtime
15
Multi tenancy
16
Reporting and Analytics - Runtime
17
Data Types
Allows both primitive and JSON data types to be stored as process variables along with Complex Java objects
SPIN library is used to parse XML/JSON data types within modelÂ
DMN Supports both JUEL(Java Unified Expression Language) and FEEL(Friendly enough Expression language)Â
Supports only JSON data type
Does not support SPIN library need to use our own transformation code for JSON/XML parsing
DMN Supports only FEELÂ
18
State Management
State data is stored in shared relational Database tables as records and all process engines in cluster are pointing to same database
State data is stored as event stream locally within disk and is replicated across brokers
19
Scaling
APP side can be scaled horizontally where as database side had limitation since DB was shared in clustered set up
Since database is not bottle neck anymore Process engine can scale horizontally