Why jBPM is not suited for a Public Cloud based Workflow offering

jBPM is not suitable for a cloud based workflow service.

There are several unique challenges in a cloud based workflow engine when compared to traditional workflow engines that are deployed on premise. In traditional workflow engines, the code that implement the tasks in the workflow are made available to the workflow engine in one of 2 ways –
 Upload the code to the workflow engine (much easier to do in an on premise workflow engine than to a cloud based one)
 Make the code available as an endpoint (say Rest API) accessible by the workflow engine


The above introduces challenges in the context of a cloud based workflow service.

If consumers of a workflow service are allowed to upload code to a multi-tenant, cloud based workflow service, solving for security, isolation, and scalability become lot more complicated. It is definitely possible to solve for some of these concerns by using techniques like “sandboxing”, however that does increase implementation complexity. It also limits the client’s choices in terms of what language the code is written, the container the code is run, etc. Clients also have limited visibility and control on the processing of their workloads.

Another method is to require workflow clients to expose the tasks as public facing endpoints that the workflow service can invoke. This requires workflow clients to deploy and expose the workflow tasks as public endpoints. This constraint could be limiting for many of the potential customers. Workloads that are deployed in non-internet facing on premise stack cannot be hooked into the workflow. Hybrid app integration where a workflow spans on premise and cloud environments also cannot be easily implemented.