Camunda multi-tenancy approaches

What is Multi-Tenancy?

• Multi-Tenancy is where the same application is run as multiple incarnations or tenants on the same server. That server may be catering for differently defined instances of that application.
• With regard to Camunda specifically, this document will be discussing how a single Camunda installation serves more than one tenant. The document intends to clarify what options are available for someone who wants to implement multi-tenancy with Camunda as well discussing the pros and cons of each approach.

Multi-Tenancy Use Case

• First we should discuss why someone might come to implement multi-tenancy in Camunda. The most common use case is where the Camunda engine is driving business processes for a SaaS application. In this case each tenant is operated on by a completely different client. When a client logs into their tenant they’ll of course only be expecting to see their own data and functions. Nothing a client can do in their tenant should ever be able to interfere with any other tenant and so data isolation is paramount.
• So why is multi-tenancy so useful in a case like this? Scalability. With multi-tenancy, granting a new client access to a tenant has the lowest cost and quickest implementation time. The alternative is to deploy and maintain a brand new server, database and software installation each time a new client joins.

Data Isolation vs. Resource Consumption

• Each type of multi-tenancy implementation walks a line between data isolation and resource consumption. To have the maximum possible data isolation (i.e. a single database per tenant) requires the use of a lot of resources and is generally quite wasteful of those resources – and so this is often avoided. On the other end of the spectrum is of course perfectly optimized resource consumption (i.e. all tenants sharing the same database and tables) but in this case all it takes is a lazily written database query to completely break down the data isolation between tenants.
• The ideal scenario is of course to have the most robust data isolation with the fewest possible wasted resources.

Camunda Multi tenancy approaches

Multi-Tenancy can be achieved in two different ways. One way is to use one process engine per tenant. The other way is to use just one process engine and associate the data with tenant identifiers. The two ways differ from each other in the level of data isolation, the effort of maintenance and the scalability.

Supported by Camunda 

• Single Process Engine With Tenant-Identifiers
• One Process Engine Per Tenant

Single Process Engine With Tenant-Identifiers

• Multi-Tenancy can be achieved with one process engine which uses tenant identifiers (i.e., tenant-ids) in discriminator column.
• The data of all tenants is stored in one table (same database and schema).
• Isolation is provided by the means of a tenant identifier that is stored in a column.

Multi tenancy deployment model (clustered process engines sharing same database with tenant markers)

 Pros

• Highly scalable and resource utilization
• Provisioning new tenant is easier by just deploying process definition for the new tenant
• Maintenance is easier

Cons

• Data isolation is very low
• Depends on the load one tenant can utilize maximum resource utilization so other tenants will lack in resource usage

One Process Engine Per Tenant

• Multi-Tenancy can be achieved by providing one process engine per tenant.
• Each process engine is configured to use a different data source which connects the data of the tenant.
• The data of the tenants can be stored in different databases, in one database with different schemas or in one schema with different tables.

 Database Isolation

• If different tenants should work on entirely different databases, they have to use different JDBC settings or different data sources.

Schema or Table Isolation

• For schema- or table-based isolation, a single data source can be used which means that resources like a connection pool can be shared among multiple engines.
• Configure the setting useSharedSqlSessionFactory=true. This setting controls whether each process engine instance should parse and maintain a local copy of the mybatis mapping files or whether a single, shared copy can be used. Since the mappings require a lot of heap (>30MB), it is recommended to switch this on. This way only one copy needs to be allocated.

Pros

• Highly scalable but for every new tenant provisioning need to run new instance of process application.
• Data isolation is higher level when compared to tenant markers approach and data isolation level is less when compared to database per tenant approach
• We can configure tenant per process definitions

Cons

• Currently spring boot starter doesn't support configuring more than one process engine in same process application.
• One should run new instance of process application to provision the new tenant to support multi-tenancy
• Might require many instances of process application for every tenants and for scalability
• Configuring multiple process engines in same process application will not bootstrap the more than one process engine.

For more information about why multiple process engines configuration not supported in one springboot app refer below discussions

• https://forum.camunda.org/t/psqlexception-error-relation-act-ge-property-does-not-exist/14074/3
• https://forum.camunda.org/t/dynamic-manage-multi-tenant-process-engine-in-combination-with-spring-boot/12921
• https://github.com/camunda/camunda-bpm-spring-boot-starter/issues/210
• https://forum.camunda.org/t/multitenancy-with-shared-process-engine-and-separate-schema-per-tenant/11867
• https://forum.camunda.org/t/multi-tenancy-schema-strategy/3954
• https://stackoverflow.com/questions/28588465/camunda-architecture-and-decisions-for-a-high-performance-dynamic-multi-tenant

Database selection can be based on below choice      

Conclusion (Recommended approaches)

• Multi tenancy with tenant identifers.
• Run new process application for each tenant(one process engine per tenant, schema/database level isolation) because springboot application doesn't support configuring multiple process engines in same process application.
• Use dedicated webserver/appserver as SaaS to configure multiple process engines to serve different applications, and business applications should be deployed as .war/.ear files in the server to consume process engine services.