...

One very important aspect in a multi-tenant is data separation. Persistent data for one tenant should under no circumstances be shared with other tenants. The image below lists strategies on how a multi-tenant system can be set up. Blueriq doesn't support the third strategy. When you are creating the solution architecture for your multi-tenant solution, you should consider the trade-offs that each strategy has.

Image RemovedImage Added

Onboarding a new tenant means setting up a new system	Only one runtime to manage	Not currently supported by Blueriq
Each system needs maintenance separately	Only one Blueriq software stack to maintain
Maintenance can be performed without other tenants noticing	Maintenance on the runtime affects all tenants
Easier to scale a single tenant	When the system needs to scale, you need to scale the entire system
Resources can be allocated per tenant. Easier to prevent noisy neighbors.	If the system experiences a sudden burst in activity, all tenants will notice this.
Least chance for mixing up data	Tenant data ends up in the same system, however, with proper configuration, the data is always stored in the right tenant database.

We expect the solution architect to consider the characteristics of each strategy and choose what suits best. For example, if you run on a container platform, the first solution may be more feasible, while when you run on VMs, the second strategy may be easier. Aspects that you may want to consider are operating costs, maintainability, data separation, availability, elasticity, flexibility and scalability.

Why use multi-tenancy?

When you want to offer a SaaS service to multiple companies, you need a multi-tenant setup.

...

• Resource sharing: you can be more cost efficient by sharing resources between tenants
• Performing a runtime upgrade needs to be done only once to have effect on all tenants
• Publishing a new version for a model only needs to be done once to have effect on all tenants
• Build once, sell multiple times

What do you need to have in place when using multi-tenancy?

Scaling strategy and availability

When having a multi-tenant service, the tenants will demand the service to be available, according to the SLA that was agreed on in the contract. This means that when your service becomes more popular, or when it has peak usage windows, it will require more processing power. Hence, you need to be able to scale your system to fit the service's demands

Tenant onboarding

When a new tenant will use your service, you will need a procedure that describes what needs to be done to add that tenant.

Service contracts

In a multi-tenancy setup, all models are shared between all tenants. However, it is possible to define different endpoints for external Rest/Soap service calls. It is important to know that those service calls can be routed to different URLs, but that they cannot differ in message structure (contract).

When not to use multi-tenancy?

When your service differs in a substantial way for each tenant, multi-tenancy might not be suitable for your solution: more diversity between tenants leads to higher costs in development and maintenance.

In Blueriq terms, if you need to make exceptions based on tenant in your model, or if you need a different model for each tenant, we strongly advise against using multi-tenancy.

System requirements

Generally, a multi-tenant system can accommodate the same amount of simultaneous users as the same system that is single tenant.

...