What is a Multi-Tenant Architecture
In a hyper-competitive world, companies are trying to maximize their efficiency across the entire organisation. Whether it’s upskilling employees, modernising legacy infrastructure, or adapting the best production/development process, enterprises constantly look to make themselves better. Well, at least the ones that are planning to stay in the game for long certainly are! Hence it should come as no surprise that companies of varying scale and different verticals have adapted Cloud Computing for their infrastructure needs. The older ways of on-premise infrastructure and owned IT hardware is giving way to simpler ways of accessing, configuring, and implementing infrastructure via the Cloud. The economies of scale, complemented with higher security and operational ease, are the primary reason companies have embraced the Cloud. If Infrastructure/hardware is considered as one end of the spectrum, then the software is the other. And the Cloud has managed to redefine user relations with software as well.
Cloud computing and multi-tenancy
It is evident that with the advent of mobility, desktop applications have given way to cloud-based SaaS. If desktop, mobile devices can be thought of as mediums of consuming software, hard disk and cloud infrastructures are mediums of software delivery. No longer are people installing/updating software using USBs or CDS on their systems. But instead are simply logging via thin clients like browsers to use their essential and favourite software. SaaS applications are of varying kinds. Emails, productivity tools, enterprise applications, storage, etc. Cloud infrastructure helps enterprises manage economies of scale. The cost of infrastructure is only as much as it is required. There is no need for a costly, high-end compute node that is only used for a fraction of its price. A SaaS application running on a cloud with 100 users can easily transition to 1000 users. With Cloud, updates and configurations can be done with minimal downtime.
A simple definition of software architecture is “The art or science or both of designing software systems either as part or whole”. In SaaS delivery models, a customer is referred to as a tenant. And the architecture most commonly used for SaaS applications is a single-tenant or multi-tenant. Let have a quick look at what single-tenant architecture is
Single Tenant architecture
A single unique, stateful running instance of the application for every customer Single database.
- Complete isolation from other applications and data
- Dedicated infrastructure
- Can be deployed on-premise or Cloud
- Backups are isolated, secure.
- Unlimited customization. Supports legal and compliance requirements
As we can see, a single-tenant application is as its name implies. A single, stateful instance of an application runs for every customer which is installed locally, on-premise. Since it’s on-premise, there is a dedicated database, and data is isolated. This leads to higher data security. The client or tenant has total control over the configurations, settings, updates, and upgrades. The benefits of being “in control” of the infrastructure are easier migration, customisation, and flexibility. But it’s not all sunshine and rainbows!
For a single-tenant system, particularly on the Cloud, the economies of scale are gone. Imagine running an entire EC2 instance for a few thousand records. Resources won’t be fully utilised and hence cost will be huge. Similarly, being “in control,” particularly on-premise, means the customer has to manage the entire system by themselves. This leads to more time to update, upgrade or manage.
Multi-tenant architecture takes this single-tenant architecture forward in a different manner. Since we are talking about a SaaS application, it is a given that there will be multiple customers or tenants for the application. In other words, there are a few groups of users belonging to different organisations that have access to the same software. With multi-tenant applications, deployment is done in one place. Similarly, the operations and infrastructure team needs to support the deployment only in one place. In this regard,
i.e., deployment, maintenance, and up-gradation, multi-tenant architecture simplify the development process.
Clearly, by definition, in a multi-tenant architecture, data is no longer isolated. Since multiple tenants or users use the same instance of the app, database access is also shared. Data isolation is significant for any customer. The reasons could be security, compliance, upgrades, etc.
How does multi-tenant architecture support data isolation?
To implement the database for multi-tenant applications, we have to consider the degree to which data is isolated.
- How much information needs to be in a silo?
- How much is in shared storage?
Based on this requirement, we can have three different kinds of database architecture for multi-tenant applications.
- One database per user (Database level tenancy)
- One database for all users with unique schemas for each user (Schema level tenancy)
- One database and one schema for all users (Record level tenancy)
1. One database per user (Database level tenancy)
Database level tenancy is pretty similar to the single-tenant architecture. Data isolation is the maximum here. Only the tenant’s data resides in this database instance. The database is on a separate server. They are physically separated. The benefits of this and the shortcomings of this architecture are similar to what we discussed above. Since data is entirely isolated, administrators can update records, backup data, and encrypt data quickly and easily. It won’t affect other tenants. But having a unique instance of a database per user is costly.
2. One database for all users with unique schemas for each user (Schema level tenancy)
Under this architecture, every tenant or user will have access to the same database. There are no separate databases for each user or dedicated servers. This way, the cost associated with individual databases is reduced. Under this architecture, data isolation is better than the one database per user architecture by having separate schemas for each tenant in the same database. By having different schemas, tenants can customise their schemas as per their business requirements. The drawback or the challenge in such an approach is that backing up only a particular schema set is challenging. Imagine if one tenant’s data gets corrupted, the entire database need not and should not be rewritten. Only the specific tenant’s data or schema should be updated.
3. One database and one schema for all users (Record level tenancy)
This is the third approach and perhaps the easiest to implement. Under this approach, all the tenant’s data are in the same database and have the same schema. Unique ids are assigned to each tenant, which separates the tenant’s records from each other. These unique ids help in querying, indexing, and searching. Under this architecture, there is no need for separate servers and infrastructure. Everything resides on one single physical database. But to a significant extent, data isolation is lost. Similarly, as the number of tenants grows, searching and querying become difficult.
As we can see, multi-tenant architecture is implemented in a variety of ways. There is no fixed model for what is the best multi-tenant architecture. Depending on the business requirements, the choice of multi-tenant architecture can vary. All said and done, multi-tenancy is at the core of modern cloud architecture. And with the wide adoption of cloud computing, multi-tenancy is here to stay. Whether it is an app on AWS, Azure, or Google Cloud, multi-tenancy helps an application quickly scale.