SaaS / Multi-Tenancy approaches for Java-based (GWT, Spring, Hibernate) web applications

Question

I am currently looking into converting a single-tenant Java based web-app that uses Spring, GWT, Hibernate, Jackrabbit, Hibernate Search / Lucene (among others) into a fully fledged SaaS style app.

I stumbled across an article that highlights the following 7 "things" as important changes to make to a single tenant app to make it an SaaS app:

1. The application must support multi-tenancy.
2. The application must have some level of self-service sign-up.
3. There must be a subscription/billing mechanism in place.
4. The application must be able to scale efficiently.
5. There must be functions in place to monitor, configure, and manage the application and tenants.
6. There must be a mechanism in place to support unique user identification and authentication.
7. There must be a mechanism in place to support some level of customization for each tenant.

My question is has anyone implemented any of the above 7 things in a SaaS /multi-tenant app using similar technologies to those that I have listed? I am keen to get as much input regarding the best ways to do so before I go down the path that I am currently considering.

As a start I am quite sure that I have a good handle on how to handle multiple tenants at a model level. I am thinking of adding a tenant ID to all of our tables and then using a Hibernate filter (and a Full Text Filter for Hibernate Search) to filter based on the logged on user's tenant ID for all queries.

I do however have some concerns around performance as well especially when our number of tenants grows quite high.

Any suggestions on how to implement such a solution will be greatly appreciated (and I apologise if this question is a bit too open-ended).

Answer 1

I would recommend that you architect your application to support all the 4 types of tenant isolation namely separate database for each tenant, separate schema for each tenant, separate table for each tenant and shared table for all tenants with a tenant ID. This will give you the flexibility to horizontally partition your database as you grow, having multiple databases each having a group of smaller tenants and also the ability to have a separate database for some large tenants. Some of your large tenants could also insist that their data (database) should reside in their premise, while the application can run off the cloud.

Here is an exaustive check list of non-functional and infrastructure level features that you may want to consider while architecting your application (some of them you may not need immediately, but think of a business situation of how you will handle such a need if your competition starts offering it)

1. tenant level customization of a) UI themes and logos b) forms and grids, c) data model extensions and custom fields, d) notification templates, e) pick up lists and master data
2. tenant level creation and administration of roles and privileges, field level access permissions, data scope policies
3. tenant level access control settings for modules and features, so that specific modules and features could be enabled / disabled depending on the subscription package.
4. Metering and monitoring of tasks / events / transactions and restriction of access control once the purchased quota is exceeded. The ability to meter any new entity in the future if and when your business model changes.
5. Externalising the business rules and workflows out of your code base and representing them as meta data, so that you can customize them for each tenant group / tenant.
6. Query builder for creating custom reports that is aware of the tenant as well as custom fields added by specific tenants.
7. Tenant encapsulation and framework level connection string management such that your developers do not have to worry about tenant IDs while writing queries.

All these are based on our experience in building a general purpose multi-tenant framework that can be used for any domain or application. Unfortunately, you cannot use our framework as it is based on .NET

But the engineering needs of any multi-tenant SaaS product (new or migrated) are the same irrespective of the technology stack that you use.