Camunda BPM excels in executing processes that require user (human) tasks, there is no question about it. However, for processes that are mostly or fully programmatic (Script Tasks and Service Tasks), you may ask: “Which one is the better approach: Camunda BPM or regular script/program?” Specifically since Lovia Team uses TypeScript as the default programming language, and serverless architecture:
Which one is better: Camunda BPM or Serverless TypeScript Functions?
Hendy Irawan
Pros and Cons
| Concern | Camunda BPM | Serverless JS/TypeScript Functions |
|---|---|---|
| Designer perspective | ||
| Visualized diagram | Yes, BPMN 2.0 diagram | No, code only |
| Integrates with User Tasks | Yes, easily | No (unless you call the function from Camunda) |
| Price | Starts from free (open source), up to Enterprise | Starts from free. Lumigo starts from free, then $119/mo. Serverless.com Cloud pricing at $20/developer/month. Hendy’s note: After trying Serverless Cloud, I think Lumigo is better and has more monitoring features. |
| Passing environment variables and secrets | ||
| Pass environment variables by instance | Requires Camunda Docker container reconfiguration | Can be done per-function basis |
| Pass environment variables by instance via AWS Parameter Store | Requires Camunda Docker container reconfiguration | Can be done per-function basis |
| Read AWS Parameter Store directly | Access AWS SDK using Camunda Script Task. AWS SDK must be embedded inside Camunda BPM image. The entire ECS Task for Camunda BPM must be launched with appropriate IAM Role for ECS Tasks. | Function must use AWS SDK. Function deployed with appropriate AWS Lambda execution role. |
| Pass variables via HTTP request variables | Yes, becomes process instance variables | Yes, becomes query parameters or fields in request body |
| Technical ease-of-use | ||
| Scripting language/runtime | ES5.1 JavaScript (Nashorn) | TypeScript on NodeJS 14 Hendy’s note: AWS Lambda Web UI has good Cloud9-ish IDE support for editing Lambda functions, but only supports JavaScript, not TypeScript. It is similar to MongoDB Realm editor, but with better UI. However, you can’t easily sync with Git. |
| Ease of calling REST APIs | Moderate, using Jsoup (need to rebuild Camunda Docker image). Not awesome (no editor hints & autocomplete, no OpenAPI support), but not bad. | Good, using Axios. If needed, good support for OpenAPI code generation. |
| Ease of calling GraphQL APIs | Moderate, using Java GraphQL library. No editor hints & autocomplete. | Good, using urql. If needed, can generate type-safe urql client using graphql-code-generator. |
| Ease of coding | Using Inline Script -> Really bad: ES5.1 syntax is ancient, adding libraries is complex (requires rebuilding Camunda Docker image), accessing variables requires the execution.getVariable(…) syntax, JSON/XML must be parsed using Spin. Coding in Java or Kotlin might result in better developer experience. | Good: VS Code editor support, serverless tooling (both local/offline and remotely), adding dependencies is straightforward with yarn add |
| Ease of debugging (developer-friendliness) | Bad: even the syntax for logging with SLF4J is cumbersome to write as Inline Script | Good: remotely with CloudWatch logs, and locally using normal logs |
| Observability of process variables (manager-friendliness) | Good: using Camunda Cockpit | Moderate: CloudWatch Logs is developer-friendly, however it is not meant for managers. For better experience, send logs to Elasticsearch and viewing them with Kibana. |
| Middleware Framework | None | Base: Serverless Framework (either cloud dashboard or CLI) Optional (monolithic style): NestJS, Middy |
| Starting/Triggering process instances | ||
| Start process instance by REST API | Yes, POST /process-definition/key/{key}/start | Yes, via AWS HTTP API or REST API |
| Schedule process instance by timer | Yes, Timer Events | Yes, run Lambda via EventBridge (does not require HTTP/REST API endpoint) |
| Start process instance by AWS SQS | Complex, either: 1. embed Camel, then add AWS SQS Camel component, and route it to start a process instance 2. start a long-running dedicated Camunda process that uses AWS SDK to consume SQS queue, start the proper process, delay a bit, then loop 3. process SQS using AWS EventBridge then route it to as REST API call to Camunda | Yes, Lambda supports SQS natively. Furthermore, Lambda supports batching, so the function can process multiple SQS messages at once. |
Comparing Inline Script in Camunda vs. TypeScript Serverless Function Code
Scheduling Processes
The choices are: AWS EventBridge, Camunda, AWS Step Functions, or a combination of them.
AWS Lambda serverless functions can be triggered with AWS EventBridge, and for simple cases this may be sufficient.
For dynamic cases, AWS EventBridge may not be good.
For example, you may want:
- To run a “Review time logs” function at specific time on Monday through Friday.
- Instead of a single invocation, you want to run the function multiple times, each with different data (team members).
This can be tiring using AWS EventBridge. However, using Camunda, it is pretty straightforward as you can set timer event and have a logic for invoking the function. You will need to invoke the Lambda function using HTTP/REST API Gateway.
Alternatively, wrap the multiple invocations using a single function that calls the inner function internally.
Conclusion
Hendy’s conclusion is:
- If you’re sure that what you want to do is fully programmatic, start with a TypeScript Function using Serverless Framework.
- If you’re not sure, start by drawing the process as a BPMN diagram in Camunda Modeler.
- Then identify the tasks, are they User Tasks or Script/Service Tasks?
- If all of the tasks are Script/Service Tasks, it’s better to leave the BPMN diagram just as documentation, but not executable. And implement the process entirely using a TypeScript Function using Serverless Framework.
- If some of the tasks are User Tasks, then it is good fit for executable BPMN process.
- Find connected paths of Script/Service Tasks. By connected, meaning can have BPMN logic in between, but not separated by User Tasks or Events. Hendy recommends to merge these related Script/Service Tasks together and call it as a single Script/Service Task instead. That task can then be implemented as a Serverless Function.
- To call Serverless Functions from Camunda BPM, it’s recommended to use AWS SDK (embedded within Camunda) and Run Lambda call directly, instead of using HTTP API. It is more performant, more secure (due to IAM Roles for ECS Tasks), less expensive, and easier to debug.