Multi-Tenancy Trends in SaaS Applications

The concept of multi-tenancy became a “thing” when the need for more scalable and operational cloud-based B2B services started to arise. Today, there’s no arguing the fact that multi-tenancy is the way to go. But why is the SaaS community thinking about multi-tenancy today? Which aspects should be considered as vital, and what are the core assumptions under which multi-tenancy is operating? If you need to get up to speed on multi-tenancy, here’s a break-down of the latest trends and leading concepts governing it today. 

What is a “Tenant” Anyway?

Different products use different naming conventions to refer to the Tenancy concept. Some call it an “Account”, “Customer”, “Workspace”, “Team”, and more. 

They all refer to the same concept of a granular encapsulation level of a team, permissions, views, settings, and policies. But most of all, in my humble opinion, “tenancy” is about the business need.  A typical B2B multi tenant SaaS solution provides business value to a specific business, so a tenant in our case would be defined as the specific business unit your SaaS offering is catering to.

What is a Multi Tenancy Model?

Multi-tenancy in terms of B2B SaaS is the ability for a SaaS app to serve several customers (or accounts), from the same codebase, database, and production deployment. Instead of having several separate production instances of your app (Frontend, Backend and Data Layers) you can have one logical instance which serves many accounts, based on a set of permissions and associations.

Note: The environment still can (and should) be distributed and include multiple microservices and databases, which most likely be separated by business-domain and not by customer relevance.

Different Aspects of Multi-Tenancy

Fifteen years ago, the multi-tenancy discourse was super technical since this was the main challenge organizations had to solve back then. Everyone had to deal with transitioning from years of on-prem software installations that didn’t require a real-time production database, to finding a scalable, secure, and operational-light way to establish a real-time service that accommodates hundreds or thousands of customers at once — from the same codebase and server.

Proper technical solution standards have been formed and defined over the years. Now, when everybody has a pretty good idea of how to solve multi-tenancy in their backend infrastructure, the discussion has moved to the operational level – how to handle proper development cycles, bug fixes, CI/CD, monitoring and scaling of multi-tenant SaaS environments are taking center stage. 

But even the operational angle is starting to get covered by standardized solutions. These are led by thought leaders in each of the above mentioned operational topics: Agile Development flows are promoted and adopted by companies like Atlassian for example, and Scaling and Monitoring are promoted by the open-source community with tools like Kubernetes, Prometheus, Istio and many more.

How do Multi Tenancy Applications Work? 

The next level to cover is the product. How to properly address multi-tenancy on the user experience level? Should it even be called multi-tenancy in this context, or by some other name that will be more relevant to the business end-user? What are the main requirements and best practices in handling multi-tenancy in terms of your SaaS product? Is a real standard starting to form?

Now that we have the overview covered, it’s time to dive into the key assumptions in your multi tenant SaaS solution.

Granularity

While on the software engineering end a standard is already materializing, the situation in terms of regulations, security and privacy is nowhere near as mature. In fact, based on our experience, every customer will ask for a different permutation of roles, security policies, and settings within your SaaS application. 

Don’t assume that you can define a randomly-determined set of rules in your backend and everyone will align themselves accordingly. They will most certainly request their own roles and tenancy hierarchy management, separate authentication policies, geo-centric data privacy rules, data filters, dashboard overviews, geo-location access policy, business settings, and more.

This means that you should provide a high level of granularity that will allow maximum flexibility within your app, so when a customer presents a new requirement (and they will) you won’t need to run a quarterly estimated epic to meet this requirement or lose the deal. Although you don’t need the highest level of flexibility at the MVP stage, keep in mind that a mature SaaS product has to enable a rich level of tenant-based granularity for the different sets of customers.

Inversion of Control

You would think that supporting a rich and granular set of definitions per tenant is enough — but customers expect more than that. They also want to define, manage, and control these definitions on their own as per their specific use cases. 

Self-service and the ability to solve product-based requirements without the need to contact the SaaS vendor’s support is becoming a standard requirement when using SaaS applications. As a customer, you expect to have the full level of control over the product so if a concept exists within the app, it’s properties and settings can be fully controlled according to your requirements. 

This concept is becoming increasingly popular in several SaaS product essentials:

• SSO – Customers want to configure their own Identity Provider. 
• Authentication – Customers want to control their password complexity policy and Multi-Factor Authentication (MFA).
• Roles & Permission Management – Customers want the ability to create and manage their own set of roles based on their requirements. 
• Event Management – Customers want to be able to onboard their own channels and configure which events they want to receive on which channel.
• Dashboards & Reports – Customers want to create their own overviews and reports in order to be able to schedule them as per their convenience.

And the list goes on: there are many more settings and configurations which should be managed by your customer without involving your support.

Multi Tenant SaaS Architecture: Scale for All

The Pareto rule may apply here. In many B2B SaaS cases, especially when a product becomes enterprise-facing in one of its tiers —  20% of your customers will produce 80% of activity within your app. This brings two main challenges to the table:

1. Allowing Elastic Scalability for Big Customers

In many cases, a customer will start from a Proof of Concept (POC) and then expand their usage of your product. So even if you end up maintaining two product environments, one for heavy-scale and one for small-scale customers, the migration experience should be seamless: the customers shouldn’t really feel that they are being moved from one backend setup to another.

2. Avoiding Small Customer Starvation 

Small customers matter. They usually advance the “thought-leadership” and “bottom-up penetration” approaches. In any case, it’s clear that their user experience shouldn’t be compromised for the sake of accommodating the needs of the big sharks. Keep in mind that your system must be elastic to the extent that it can support small and big customers, with seamless migration between the tiers.

Environment Flexibility

Allowing your customers to control where they want their tenant to reside  physically is one of the main requirements for most SaaS products these days. The two main concepts that apply here are Customer’s cloud and Geo-flexibility.

• Customer’s Cloud

As a SaaS vendor, you may be thinking that all you need to do is deploy your system on your cloud cluster, develop a multi-tenant system there, and you’re ready to meet the needs of your customers. Well, that’s not quite the case yet. Cloud adoption doesn’t mean that on-prem is dead. In fact, in many cases, it just means that the new on-prem is now your customer’s cloud environment.

In other words, many customers will require an installation of your product in their cloud environment. The multi-tenancy infrastructure that you’ve developed should accommodate the requirement to have some of the tenants installed on their cloud.

• Geo-Flexibility

Due to GDPR and other geo-related restrictions on data access and storage, you need to be quite flexible in the physical geo-location in which your customers’ data resides. Some customers will even need user-based granularity so they could choose which end-users’ data resides on which geo-location.

Summing up

Multi-tenancy is no longer an engineering-only problem. It has become one of the main pillars of B2B SaaS applications and needs to be taken seriously. To handle multi-tenancy, you need to start by conceptualizing the granularity level your customers will require. You then need to provide your customers with the highest level of self-service control over their account’s different configurations. 

At Frontegg, we believe that multi-tenancy is a core B2B SaaS value, one that defines the solution’s maturity level, a make it or break it for different types of customers. That’s why we build very flexible and granular tenancy management capabilities. Full multi-tenancy support is embedded in each and one of our composable SaaS essentials, which we would love to tell you more about.