Multi-Tenant Architecture

Overview

Multi-Tenancy (MT) is a type of Server Architecture that allows a single software instance to serve multiple, different groups of users. The primary characteristic of an MT architecture is the segregation of data at rest. In Decisions, users have a variety of approaches available to deploy an MT architecture. The following document compares and contrasts the characteristics of these approaches by looking at three primary Multi-Tenant design methodologies.

Standard Server vs Multi-Tenant Server

Standard Server

In a Standard Server, all users on the Server share the same Portal/Studio. All data that is saved into Decisions Default Database Types by the Workflows executed, is stored within a single Database. While users share the same physical Portal, the view of that Portal can be configured uniquely at the Group/User Account level. 

The resource requirements for the Host Server depends completely on the usage of the applications running on it. Further, Admins can control the amount of accessible data and how it is accessed via user context and Folder Permissions; this allows the ability to create separate unique work environments while utilizing just a single Server. 

Multi-Tenant Server 

By contrast, Multi-Tenant Servers provide the ability to allow multiple User Accounts to log into separate instances hosted on a single Server. A Multi-Tenant Architecture allows the ability to break out individual installations/instances from the Control (Primary) Instance. This provides the ability to host each instance as a separate instance running on a Single-Host Server.

Differences Between Physical and Logical Multi Tenancies

The primary difference between Standard and MT Servers is that data is segregated into separate Databases by default. This type of architecture is referred to as Physical Multi-Tenancy. Decisions provides the flexibility of an additional option when designing a MT architecture that is known as Logical Tenancy.
Logical Tenancies can be separated into two different types: Standard and Data Segregated. The option a user chooses depends on the requirements of their process under consideration.

Decisions Flows do not put any constraints on where the data being handled is read from or is written to. Default Decisions Datatypes save themselves into the Server's SQL Server Database. Though there is no configuration available to define different Databases for these Dataypes, Decisions does not require users to save data into the Backend Database. There is an Integration Layer that allows the ability to access data from external sources using the same patterns. This feature paired the Flow Engine’s ability to integrate with an unlimited number of external Datastores can be used to imagine a process defined to read data from/write data to user/customer-specific Databases at runtime. 

Use Case Examples 

Standard (Physical) Multi-Tenancy 

• An example Physical MT environment involves multiple customers each with their own completely separate process. This customer wants to reduce hosting costs by moving hosting to a single instance. As Multi Tenancies allow a customer to run multiple instances on one Windows Server, but they wish to provide their customers with independent work environments, a Physical MT is a good fit. This allows each customer to have their own unique work and environment.
• Another example would be a Workflow that shares all of its main components amongst all of the customers accessing it. The customer needs to retain the flexibility to handle the biggest customers with completely custom Workflow versions. Physical MTs allow the ability to run 99% of the customers on the Single-Tenant and break these bespoke customers out into their own, independent tenants.

Standard Logical Tenancy 

• A Customer that may consider a Logical Tenancy has built a Business Rule engine that they need each of their customers to consume. Each customer uses the same version of the Flow-based Business Rule config but needs to view their transaction data separately (via a Customer Portal). Logical Tenancy allows the ability to separate the data being viewed so each customer can only view their own data.

Data-Segregated Logical Tenancy 

• The above example for the Standard Logical Tenancy may be applied with the added requirement that the transactional data from the Business Rules Engine gets saved into customer-specific datastores.