The concept of multi-tenancy became a “thing” quite a while ago, when the need for more scalable and operational cloud-based B2B services started to gain popularity. Today there can be no disagreement that multi-tenancy is the essence of SaaS. But how is the SaaS community thinking about multi-tenancy today? Which aspects of it should be considered as key, 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 concept that we call tenancy. 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 opinion, “tenancy” is about the business need. A typical B2B SaaS application provides business value to a specific business, so a tenant in our case would be defined as the specific business unit your SaaS serves.
What is “Multi-tenancy” in a nutshell?
Multi-tenancy in terms of B2B SaaS is the ability for a SaaS application to serve several customers (or accounts), from the same codebase, database, and production deployment. So, instead of having several separate production instances of your application (including 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 and thousands of customers at once — from the same codebase and server.
During the last decade the technical solution standards have been formed and well defined. So nowadays, 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. Now, questions of 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.
So it seems that the next level to cover is product. How to properly address the 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?
Key assumptions in your Multi-Tenant SaaS product
While on the software engineering end a standard is already forming regarding best practices, the situation in terms of Regulations, Security and Privacy is nowhere near as mature. In fact, in 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 some set of assumptions on your backend and everyone would align accordingly. On the contrary, they will request their own roles, their own tenancy hierarchy management, their own authentication policies, their own data privacy rules, data filters, dashboard overviews, geo-location access policy, business settings and so on.
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 control these definitions on their own. 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, where customers expect to be able to configure their own Identity Provider.
- Authentication, where customers expect to control their password complexity policy and MFA.
- Roles & Permission management, where customers want the ability to create their own set of roles.
- Events management, where customers want to be able to onboard their own channels and configure which events they want to receive on which channel.
- Dashboards & Reports, where customers want to create their own overviews and reports and be able to schedule them in their convenient times.
And the list goes on: there are many more settings and configurations which should be managed by your customer without involving your support.
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:
Allowing elastic scalability for every big customer
In many cases, a customer will start from a 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 customer shouldn’t feel that they are being moved from one backend setup to another.
Avoiding starvation for small customers
The small customers matter and they will 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 customers, big customers, and the seamless migration of small to big and vice versa.
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 (1) Customer’s cloud and (2) Geo-flexibility.
As a SaaS vendor, you would have thought that with the adoption of cloud infrastructure all you need to do is deploy your system on your cloud cluster, develop a multi-tenant system there, boom, you’re ready to fulfill the needs of all your potential customers. Well, that’s not quite the case yet. The adoption of cloud 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 of your 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.
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.
Multi-tenancy is no longer an engineering-only problem: it’s become one of the 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 value for B2B SaaS, one that defines the solution’s maturity level and can make it or break it for different levels of customers. That’s why we build very flexible and granular tenancy management capabilities and full multi-tenancy support is embedded in each and one of our composable SaaS essentials, which we would love to tell you more about 🙂