Multi-tenant architecture, commonly referred to as multitenancy, is a software architecture in which multiple single instances of software run on a single physical server. The server then serves multiple tenants. Additionally, multitenant architecture is used to enable multiple users to use a single application, for instance a database.
Multi-tenant architecture is often used in cloud computing, to offer shared tenancy on public cloud providers like Amazon Web Services, Microsoft Azure and Google Cloud. Additionally, multitenancy is a key part of another cloud model, software as a service, and so is deployed by many SaaS companies as well as virtually every cloud company.
“Tenants” is a term for a group of users or software applications that all share access to the hardware through the underlying software. Multiple tenants on a server all share the memory, which is dynamically allocated and cleaned up as needed. They also share access to system resources, such as the network controller.
This is the opposite of single-tenancy, in which the server runs one instance of the operating system and one application. This one application could be something simple like file and print apps, complex like Web or application servers, or mission-critical, such as a database.
Multi-tenant architecture’s core advantage is that it allows exponentially more use from a single hardware or software platform.
If you’re interested in getting on the path to becoming Google Cloud Certified, check out this course!
Why Multi-Tenant Architecture Matters
Multi-tenant architecture is a core technology that enables cloud computing. So, as noted above, multi-tenant is used by all public cloud providers, and is universally deployed in the cloud landscape. Indeed, multi-tenant architecture literally makes cloud computing economically and technologically feasible by allowing a mixed number of customers to leverage one platform. As covered in greater detail below, the cost advantages of multi-tenant tends to be the make-or-break factor that attracts enterprise users to multi-tenant architecture.
The other crucial driver for multi-tenant architecture is that it enables high levels of scalability. Cloud providers can expand service to customers exponentially faster because a single platform is serving multiple customers. This scalability is as important to cloud computing as any of its many advantages. Businesses migrate from their aging datacenters to the cloud because they know they can, with a few clicks, access more computing power and an astounding array of cloud-based tools, from artificial intelligence to machine learning to data analytics. If this process were slow or in any way cumbersome – that is, if multi-tenant were not efficient and powerful – cloud computing would hardly be possible.
How Did Multi-Tenant Architecture Develop?
The concept of multitenancy actually dates back to the 1960s, when companies rented time on mainframes, which were rare and expensive. Back then it was called time sharing. Multiple customers could access the same apps at the same time, a feat only mainframes could do.
Starting in the 1990s, application service providers (ASPs) hosted applications on behalf of their customers and like mainframes, the same apps were made available to multiple customers.
In the modern era, multitenancy is part and parcel with software-as-a-service models like Salesforce, Office 365, Zoho, Box, Zendesk, Slack, and many more applications on demand.
As mentioned above, cloud providers do offer multitenancy, in a technique of shared use of computing resources. However, this shared use of resources should not be confused with virtualization, a closely related concept. In a multitenancy environment, multiple customers share the same application, in the same operating environment, on the same hardware, with the same storage mechanism. In virtualization, every application runs on a separate virtual machine with its own OS.
What is the Difference Between Single and Multi-Tenant?
Single-tenancy is largely seen as the “deluxe” option, in that a client operates in a solely dedicated environment. In a multi-tenant environment, each customer shares the software application along with a single database, so multiple people from the same company can access the database. Still, even in multi-tenant, each tenant is isolated from other tenants.
Advantages of Single-Tenant Architecture
Single-tenant hosting gives clients more control because there is no sharing of resources. This manifests in a number of ways:
- Greater customization: Since they have only one client, single tenants can customize the software for their needs, whereas multi-tenant tends to be one-size-fits-all.
- Greater isolation from security risks: You control the environment and (hopefully) what goes in and out of it.
- Faster recovery: Restoring one client is faster and easier than many.
- Better control: Single-tenant can be choosier about accepting software changes and updates and decide what add-ons they want to use.
- Avoiding “noisy neighbor” syndrome: Since you are sharing resources in multi-tenant scenarios, someone else who is really heavily using the system might slow you down.
Disadvantages of Single-Tenant Architecture
Though some companies prefer it, there are downsides to single-tenancy.
- Cost: There is no cost sharing for things like balancing, services, system monitoring, and deployment.
- Client responsibility: Clients are responsible for software updates, patches, backup, restore, and disaster recovery.
- Less efficient: Single-tenant systems can be less efficient if they don’t run at full capacity or if they are over-provisioned.
Advantages of Multi-Tenant Architecture
The chief advantage of multi-tenant hosting is that it is less expensive. The resource pooling greatly reduces the cost since you only pay for what you need. And since multi-tenant is part of a SaaS provider, you are not paying for on-premises hardware. Functions like system monitoring and servicing the deployment become shared among all of the customers, which makes it less expensive as the cost is spread around.
There are other advantages as well.
- Simplified hosting: It’s not your hardware to manage any more, reducing a lot of time and expense.
- Better protection of systems: With less interaction with the outside world, exposure to malicious software is reduced.
- Upgrading software is no longer your problem: You always get the latest version of software pushed out to you by the provider.
Disadvantages of Multi-Tenant Architecture
Despite its cost advantage, multi-tenant environments have some downsides.
- They have their own security risks: For starters, you need strict authentication and access controls to make sure the right people get access. Second, data corruption could possibly spread from one user to all, though precautions guard against this.
- Downtime: Outages can be nationwide, and often make the news when they happen. SaaS providers tend to build enough redundancy into the system to minimize this.
- Noisy neighbors: As mentioned earlier, someone else on your CPU might be consuming cycles and slowing you down. Capacity is supposed to be elastic and expand as needed but that’s not always the case.
As we said above, in a multi-tenant environment, multiple customers share the same application, in the same operating environment, on the same hardware, with the same storage mechanism and database. This is how Salesforce and every other SaaS operator runs. Every tenant is a customer/user who has common access and specific privileges in the software instance.
The database, however, is another matter. There are three ways to architect your database in a multi-tenant system.
A single, shared database schema
A schema is a layout for database tables that relate to each other. In the first approach, one database is used with tenant tables all linked to the database. The tables handle relations and version control or updates, such as handling two people attempting to manipulate the same table or data entry. This is the fastest way to operate, since only one database is being used, assuming it scales.
Single database, multiple schemas
Multiple schemas inside a single database is a popular method to have sub-databases, so you can divide up your data without having to set up multiple databases. Each schema is isolated from the others and operates differently, which can be useful in situations where different data has different regulations, like international data.
This takes the multi-schema approach one step further because now you have the data in multiple databases. Sales or customers can be divided up by region, for example. So the upside is you get the best isolation of data. Of course, that also adds to the complexity of management, maintenance and scalability that would come with deploying multiple databases.
Multi-Tenant Architecture Examples
In a virtual system, one system may have 20 instances running several operating systems, each with its own application and database. In a multi-tenant architecture, all of the instances share the OS, app, and most importantly, the database.
Does this sound familiar? That’s not only how SaaS works but how Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) operate, since both can be used to write highly scalable multitenant apps that are outward-facing, meaning customers and partners can use them.
That’s how 50 people from the same company can work on Salesforce CRM. Similarly, a SAP system is composed of a database backend and Web application servers that host Web services in a highly scalable manner. The Web services that make up the SaaS app are exposed to different customers via different domain names. Scaling is achieved by starting more services.
Most of the example conform to these three ways to structure a multi-tenant application:
- URL-based SaaS. This is the easiest one to do since it uses a single domain and database. You would have specific URLs, like subdomain1.maindomain.com, subdomain2.maindomain.com, etc. Data management and security are handled at the application level. Some SaaS operates this way, especially those that put a Web app interface between the user and the database.
- Multi-tenant SaaS. This is more complex because of multiple databases and/or schemas, and restrictions are done at the database level. This is how many SaaS apps operate and often allow more direct interaction with the database.
- Virtualization-based SaaS, like containers. This is the most complex setup because there is so much interaction between the containers as well as the apps and databases. That’s why there is so much emphasis on orchestrators like Docker and Kubernetes.
Choosing Between Multi-Tenant and Single Tenant
Choosing between single- and multi-tenant often comes down to a choice of on-premises vs. cloud. For instance, there is no single-tenant version of Salesforce and, in contrast, major databases tend to be single-tenant so as to have full access to resources.
Security of data is clearly a concern, but that falls primarily on the shoulders of SaaS providers. They are the ones responsible for monitoring tenants and making sure there is no data bleed from one customer to another, and they do a good job of it.
The client’s primary responsibility for securing the data falls to their client device. All of the major SaaS providers do offer two-factor authentication to secure logins. After that it’s up to you to maintain the security of the endpoint device.
Multi-tenancy is at the heart of cloud computing. It is designed to help scale up thousands of users both within an enterprise and externally as companies interact and do business. Whether it’s your Salesforce account or an app you built on AWS for customers, multitenancy can scale through public and private clouds and provide true economies of scale.