Key Considerations Regarding Multi-Tenancy Architecture
Multi-tenancy is an old computing term that traces its roots back to the very first computer networks in the 1960s, when companies had to rent shared space on mainframe computers and access the same applications.
Why is the term “multi-tenancy” experiencing a resurgence today? To answer that, let’s look at the concept of multi-tenancy as it relates to cloud computing which is one of today’s major computing concepts.
What is Multi-Tenancy?
Multi-tenancy is an architecture that allows multiple clients to share a single instance of a software application. Each client is called a “tenant,” and each tenant may have some control over the appearance and functionality of the software. Tenants may be able to customize the UI, for example, but will have no control over the software’s code.
In cloud computing, multiple tenants share resources such as configurations and data. Shared resources can be customized and physically integrated but are logically separated. For example, in a public cloud, the same servers can be used to host multiple users. Each user (or tenant) is given a logically separate and secure space within the same server.
Why is Multi-Tenancy Needed?
Multi-tenancy allows many users to share limited hardware infrastructure. Both public and private clouds are dependent on multi-tenancy architecture to operate efficiently and economically. Without it, systems would not be scalable, and performing many cloud-computing processes across many clients would become technologically untenable.
Multi-Tenant Architectural Options
There are three primary multi-tenant architecture types:
1. One App Instance / One Database
This type of architecture allows a single instance of the software to support a single database. All tenants (user accounts) that access the software have their data stored in the same database.
|Cheap because resources are shared||Easy to scale|
|Noisy neighbors||Risk of exposing one client’s data to another client|
2. One App Instance / Multiple Databases
In this type architecture, a single instance of the software supports multiple databases. Each tenant has a separate database instance that is independently maintained.
|Reduced noisy-neighbor effect / better isolation of tenants||Easy to implement|
|Doesn’t scale well||Expensive because fewer resources are shared among clients|
3. Multiple App Instances / Multiple Databases
The final type of multi-tenant architecture, every client installs and maintains a separate instance of the software on their own device or system. This furthermore entails that every client also maintains a separate database.
|Highly secure and very isolated||Allows clients to have full control of the application.|
|Difficult to maintain.||Very expensive|
|Adding new tenants is difficult and costly.|
Real-World Examples of Multi-Tenant Architectures
One real-world example of this type of architecture is a large enterprise with multiple departments, where each department is a tenant in the system but requires access to the same data. This might be achieved using a one-app instance / single database architecture.
Other real-world examples include GitHub, Slack, Salesforce, and other online SaaS solutions. In these applications, users all have access to the same basic set of core features and user interfaces. Users can customize certain aspects of the software, like the UI skin and notifications, but cannot change core functionality.
This is a high-level explanation of a complex decision to be made regarding your software platform. But hopefully provides some idea of key factors to consider.