What is Multi-Tenant Architecture?

Share it on Twitter  
Share it on Facebook  
Share it on Linked in  

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.

“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.

Multitenancy is often used in cloud computing, to offer shared tenancy on public cloud providers like Amazon Web Services and Microsoft Azure. Additionally, multitenancy is a key part of another cloud model, software as a service, and so is deployed by many software as a service companies.

Development of Multi-Tenant Architecture

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 model 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.

Single-Tenant vs. 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 Hosting

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 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 Hosting

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 Hosting

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 Hosting

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.
  • Noise 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.

Multi-Tenant Databases

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 regulation, like international data.

Multiple databases

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 20 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 is 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 comes down to a choice of on-premises vs. cloud. There is no single-tenant version of Salesforce and, in contrast, databases like Oracle are 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.

A major concern between single- and multi-tenant systems is data ownership. Larry Ellison once called Salesforce a “roach motel of clouds,” meaning data goes in but doesn’t come out. Obviously, he was overstating the matter. It is certainly possible to get your CRM data out of Salesforce, but more likely in a CSV format than a SQL database.

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.