Multi-Tenant Application

Morris Muriuki Muthigani

others

09/08/2023 (9 months ago)

Multi-Tenant Application

The multi-tenancy concept is that numerous users share computational, networking, and storage resources without seeing each other’s data. A multi-tenant application is customized for every group of users (so-called tenants) while the entire architecture and core functionality remain the same. Multi-tenancy is a typical approach for Software-as-a-Service (SaaS) vendors

Resource utilization increases, and, as a result, project ownership is typically more reasonable. But it cannot be employed for every app. Let me explain how multitenancy works, how it differs from the single tenancy, and when to apply it.

Use Cases

Multi-tenant architecture best suits the following types of applications:

⦁ SaaS (software as a service) or AaaS (applications as a service)

⦁ PaaS (Platform as a Service)

⦁ IaaS (Infrastructure as a Service)

⦁ For all other applications where multiple clients use the same stack of algorithms. The main functionality is either the same or modular, and it can be tailored to any of the client’s needs.

Multi-Tenant vs. Single-Tenant

To choose exemplary architecture, we must comprehend how both work.

1. Single-Tenant

Each user receives dedicated computing, network, and storage resources. Every environment is developed and managed separately. In essence, this option does not allow for any sharing.

2. Multi-Tenant

This model supports hosting multiple customers inside one environment and reusing core application functionality. Each of the tenants is isolated and invisible to others. Residents are separated logically, not physically; thus, fewer hardware investments are needed. Other benefits include simplified security support and more affordable licensing. Less time/effort disbursed on many diverse solutions means more time/effort dedicated to the core solution. Overall quality wins in this case.

Sample Solution Architecture

Let’s continue with a simple but real-world multi-tenant solution.

Here the data layer is made of a single shared Cloud SQL (MySQL) instance and object storage. Clients (tenants) use a stack of shared Cloud Functions that comprise the serverless business layer.

Wait… one database?

Data Management in Multi-Tenant Applications

Depending on the way of storing data, there may be different multi-tenancy database solutions:

1. Single database + single schema

= One database schema contains data of all tenants

Caring about the tenants’ data separation is the most important in this case. Add database indexes like TenantID or ClientID to partition tenant’s rows.

Benefits:

⦁ It is easy to maintain one database (compared to other options)

⦁ You can add as many new customers as you want (adding is as easy as typing a new record in the table).

Pitfalls:

⦁ There is not much flexibility for diverse customers that may require different data usage patterns. Crutching and patching are needed when a non-typical client arrives.

⦁ You risk wasting hours and nerves trying to properly separate the permissions

⦁ Backup and recovery may introduce additional problems. Because it contains data from other customers, a table can not be easily dropped and recreated. It’s a real pain in the ass to have to search up and overwrite needed rows.

Verdict:

An excellent choice for clients that conduct matching actions.

2. Single database + multiple schemas

Multiple tables are required in this scenario to store data from different clients. Schemas become ‘namespaces’ that incorporate specific tables, procedures, and permissions.

Benefits:

⦁ Schemas enable access sharing at the DBMS level, so we don’t need to do anything further (we save our nerves and money, hallelujah!)

⦁ Fewer databases — fewer hardware resources. Another victory!

⦁ Good extensibility. If you need a new schema, you can build it based on another one. Each time, you can modify it as you want.

Pitfalls:

⦁ Data from several clients is kept together because tables are divided logically rather than physically;

⦁ Backup and recovery are both problematic. We have one database, and if some element fails, everything can roll back to the previous state, which is unacceptable. Then you will probably need to merge the old and new information. Is it easy? Not at all, because it is not just reverting.

Verdict:

An excellent choice for customers that are okay with working in a shared environment.

3. Separate databases

Another possible model is when the code and data are shared conceptually (and possibly physically) between clients (through a common user interface and business logic).

Benefits:

⦁ Extensibility in one click. To add a new client, you need to configure only a new storage

⦁ Scaling is simple. You can support the databases of clients on different servers

⦁ Customization. You can change the settings for each client (and even move the storage to a different DBMS)

⦁ Simple backups. Even if one component fails, the others remain unaffected.

Pitfalls:

⦁ It’s not cheap. The amount of storage supported by a single server is restricted. You will probably need more hardware (much more than when everything is kept in one spot). Keep in mind, more hardware = more administrators, server room space, and power expenses.

⦁ Again, it’s not cheap. When your server hosts many locations, the total volume is greater than the RAM size; the data is spilled into the swap file, resulting in very sluggish access to the hard drive. The solution is to purchase additional servers.

Verdict:

This is the best option for clients who want safety above everything else and are willing to pay (for example, banks).

Takeaways

I hope you’ve grasped enough information about multitenancy to make the right choice as per your requirements.

Here are the key takeaways from this article:

⦁ The multi-tenant environment hosts isolated users that share computational, networking, and storage resources.

⦁ When operating in multitenancy, you benefit from cost savings, increased resources utilization, reusable data processing elements, simple release management, and lower maintenance costs.

⦁ On the other hand, you should be ready to face such drawbacks as complex development, high release risks, limited personalization, fragile security, lower performance, and complications in making changes.

⦁ Think twice before applying to a multi-tenant scenario. But you can be sure while selecting it for SaaS, AaaS, PaaS, IaaS, and other applications where core functionality is either the same for all users or strictly modular and can be easily tailored to typical clients’ needs.