Multi-Tenant Definition
Multi-tenant architecture serves multiple customers using a single instance of software running on a server. Separate customers in a multi-tenant environment tap into the same data storage and hardware, each creating a dedicated instance. Although every tenant’s data runs on the same server, it remains isolated and invisible to others.
Within the context of application delivery and load balancing, multi-tenancy has a similar definition. In this instance each tenant might represent a business unit or customer organization requiring access to an isolated group of resources (servers and applications). Each tenant may have different requirements based on their needs such as security protocols, compliance requirements, budget allocations. A multi-tenant load balancer can manage the requirements for each of these different tenants within the same central management cluster.
Originally, multitenancy simply referred to a single software instance that serves multiple tenants. However, the term multi-tenant has broadened in meaning beyond software multitenancy thanks to modern cloud computing, and now also refers to shared cloud infrastructure.
In cloud computing, online users access data and applications that are hosted in various data centers by remote servers. Instead of locating applications and data on servers on the premises of a company or on smartphones, laptops, and other individual client devices, they are centralized in the cloud. The ease and convenience of accessing multiple apps and platforms from various devices has, in part, driven the explosion of cloud-based multi tenant applications.
Multi-Tenant FAQs
What is Multitenant Architecture?
Multitenant architecture, multi tenant architecture, or multitenancy architecture in cloud computing refers to multiple cloud vendor customers using shared computing resources. However, although they share resources, the data of cloud customers is kept totally separate, and they aren’t aware of each other. Without multitenancy or multi-tenant architecture, cloud services including containers, IaaS, PaaS, serverless computing, and software-as-a-service (SaaS) would be far less practical.
Multi tenant architecture references a single instance of the software, such as one workable application, that runs on the multi-tenant cloud infrastructure provided by the cloud vendor, such as Azure, AWS, or GCP, to simultaneously serve the needs of multiple customers. tenants are invisible to each other and customer data is stored exclusively in multi-tenant SaaS architecture.
Some multi-tenant architecture examples would be Hubspot, Github, and Salesforce. In each case, every user shares the main multi-tenant database and software application, but each tenant’s data is invisible to others and isolated. Users can customize some features, such as notifications or themes, but core application code remains intact and cannot be changed by tenants.
Within the realm of application delivery, a multi-tenant architecture is one that can handle different policies for each entity requiring access to each pool of resources. This means one central management control plane, can govern application services for different tenants. Those tenants may access different applications, with distinct SLAs and security policies, but the ADC will handle them centrally, providing visibility across the tenant environment.
Single Tenant vs Multi-Tenant
There are several ways to think about the differences between single tenancy versus multitenancy. A classic way of thinking about single tenant architecture versus multi-tenant architecture is the analogy of a single family home versus an apartment building.
It is true that users of the multi-tenant architecture share infrastructure and amenities as you would in an apartment building or condominium complex, and that user accounts or “apartments” are customizable. However, there are drawbacks in privacy with this housing analogy that do not necessarily exist in a cloud environment.
A better analogy for understanding multitenancy might be how multiple customers use a bank. The many users of such a facility mostly are unaware of each other, and enjoy much greater security due to their shared amenities. Although they may be shared in a common location, assets are completely separate. And while at an individual branch (or on an individual app or server) there may be an occasional “noisy neighbor” effect on a busy day, bank customers mostly don’t perceive each other.
Users of public cloud computing platforms access the same servers and other infrastructure while maintaining separate business logic and data. And while originally multi-tenant architecture referred to one instance of software that served multiple tenants, modern cloud computing has expanded multitenancy to include shared cloud infrastructure.
Within application delivery, a single tenant might represent an individual customer, a business unit, a function within an organization or team. Multi-tenancy then refers to a combination of those business units, teams or customers, each of which might have their own requirements, resources and cost centers.
Single Tenant vs Multi-Tenant Pros and Cons
To better compare single tenancy and multi-tenant platforms, consider their basic structures, benefits, and drawbacks:
Single Tenant SaaS
In single tenant SaaS architecture the client is the tenant. Each user has supporting infrastructure and a dedicated server in the single tenant environment. Users cannot share single tenant products, but they can customize them to their exact requirements.
A subdivision with one basic model home that can be customized is a metaphor for a single tenant SaaS environment. In this kind of neighborhood community, the basic floor plan and infrastructure are designed and built by the same engineer, but each household uses its own infrastructure and can modify it as needed. Similarly, each user in a single tenant architecture can customize their individual software instance to meet their business requirements.
Advantages of Single Tenant Architecture
Security. Single tenancy isolates each user’s data completely from other users. This structure protects against breaches and hacking, since customers can’t access the sensitive information of others.
Reliability. Single tenant environments are more reliable because the activities of one user cannot affect anyone else. For example, downtime during one client’s difficult integration impacts that client’s software alone; it won’t impact the software of any other users.
Easier Backup and Restoration. Isolated backups to a dedicated portion of the server for each user’s database make it easier to access historical data for backup and restoration. Because all user data is stored in account-specific locations, teams can more easily restore previous settings.
Individual Upgrades. Single tenants don’t need to wait for universal updates from the software provider and can upgrade their services individually, on their own time as soon as the download is available, without disrupting workflow, after hours.
Easier Migration. Migrating to a self-hosted environment from a SaaS environment is easier because it is simpler to export and transfer data that is all stored in one space.
Drawbacks of Single Tenant Environments
Some drawbacks associated with single tenant environments include:
Cost. Typically, single tenancy costs more than multi-tenant cloud architecture. Each new user requires a new instance, and every one has an associated cost. There is also no cost-sharing for monitoring, deployment, or other services. Furthermore, more maintenance and customizations demand more time and compute resources.
Maintenance. Single tenant SaaS architecture which demands constant upgrades and updates generally requires more maintenance. This can consume extensive time, and the user must manage it.
Efficiency. Single tenant SaaS is often less efficient than multi-tenant SaaS because until it is completely onboarded it cannot make efficient use of resources. The ongoing need to update, practically, means either using an outdated version or permanently dedicating resources to maintenance.
What is Multi-Tenant Architecture?
As described above, a multi-tenant SaaS architecture sees multiple users saving and storing data with a single instance of the software along with its supporting data. Each user has some level of customization possible, but shares the same application and multi-tenant database. Based on this, there are several benefits to a multi-tenant cloud management platform.
Advantages of Multi-Tenant Architecture
Lower Costs. Multi-tenant architecture often costs less than a single tenant structure because it allows for the exchange of applications, resources, databases, and services. Additional users can use the same software, so scaling has fewer implications.
Efficient Resources. Multi-tenant software architecture shares all resources, offering optimum efficiency and the capacity to power multiple users at once, because it is a dynamic environment where users access resources simultaneously.
Lower Maintenance Costs and Fewer User Responsibilities. Typically, users don’t have to pay expensive maintenance costs and other fees to maintain the software as those costs are associated with SaaS subscriptions. Clients retain responsibility for patches, updates, and other software development, but not areas that can be moved to the cloud, such as hosting.
Common Data Centers. Customers use a common infrastructure so there is no need to create a new data center for each new customer.
Increased Computing Capacity. Multitenancy architecture allows for more computing or server capacity within the same infrastructure and data center.
Simplified Data Mining. All data can be accessed from within a single database schema by all customers, making it more accessible.
Streamlined Data Release and Installation. A multi-tenant package only requires installation on one server rather than individual releases of code and data to specific servers and client desktops.
These same advantages for SaaS also translate to application delivery whereby multiple business units (tenants) can share the central capabilities and costs of the ADC between each other, and scale them up or down as required. This prevents over-provisioning which historically has been a challenge for hardware-based ADCs that are not divisible or scalable.
Drawbacks of Multi-Tenant Cloud Architecture
Multi-tenant architecture has its own shortcomings.
Downtime. Because it relies on large, complex databases that require routine hardware and software downtime, multi-tenant architecture may experience more downtime. This can make an organization appear less reliable and cause issues with availability for customers.
Security and Compliance. Certain potential multi-tenant cloud security risks and compliance issues exist. For example, due to regulatory requirements, some companies may not be able to use shared infrastructure to store data, no matter how secure it is. Additionally, although it shouldn’t occur when infrastructure is configured properly by the cloud vendor and it is extremely rare, corrupted data or other security problems from one tenant could spread to other tenants on the same machine.
However, cloud vendors typically invest more than individual businesses can in their security. The right multi-tenant security model greatly mitigates these risks. A multi-tenant firewall provides a dedicated instance for each user, and multi-tenant monitoring software also offers added security. Ultimately, most multi-tenancy systems provide much more security than single tenant systems.
Noisy Neighbors. There may be more noise and in-app disturbances in multi-tenant environments. Shared databases inside a multi-tenant environment can mean hardware and software issues for one tenant impact others. This “noisy neighbor” effect can mean inadequate computing power and reduced performance for other users, or even an outage. However, if the cloud vendor has correctly set up their infrastructure, this should not occur.
Less Customization. Multi-tenant SaaS is less customizable than single tenant SaaS and users cannot totally control environmental quality because services and resources are shared with multiple customers.
How Multi-Tenancy is Implemented?
Various technical principles enable multitenancy in different cloud computing settings.
Public Cloud Computing. Public cloud providers implement multitenancy so that the same tool works to meet each user’s specific needs in a slightly different way. The provider will define multitenancy as a shared software instance that can be altered at runtime using stored tenant metadata so it performs better for each user. Permissions isolate the tenants from each other and they all experience and use the software differently.
Container Architecture/Multi-Tenant Kubernetes. Containers are self-contained, and can ensure consistent application performance regardless of hosting location. Each of the multitenant database containers runs as if it were the host machine’s only system, partitioned from other containers in different user space environments. These characteristics mean that it’s easy to run multiple cloud customer containers on one host machine using the single multitenant container database.
In Kubernetes multitenancy, multiple workloads or applications run side by side, sharing resources between tenants. The control plane and cluster are shared by the applications, workloads, or users.
Serverless Computing/Function-as-a-Service (FaaS). In this model of cloud computing, applications are broken up into smaller portions called functions. Each function runs separately from other functions and only on demand. Serverless functions run on any available machine in the serverless provider’s infrastructure, not on dedicated servers. Serverless providers may be running code from multiple customers on one server simultaneously because users do not have their own discrete physical servers.
Private Cloud Computing. Similar to public cloud computing, multiple tenants or customers share architecture in private cloud computing. The difference is that the multiple tenants are teams within one private organizational cloud, not multiple organizations.
Does Avi Support Multi-Tenant Solutions?
Yes – the Avi Platform supports multi-tenancy. Within Avi a tenant, such as a business unit, can manage an isolated group of resources. Each tenant as a full set of controls, monitoring, visibility and reporting across those resources.
In fact, the Avi platform supports the different forms of tenancy:
- Control plane isolation only — Policies and application configuration are isolated between each tenant. This means there are no shared policies or configurations between tenants. The applications are provisioned using a common set of Avi Service Engine entities, so the engines are shared between tenants even though the policies implemented are unique.
- Control + Data plane isolation — Policies and applications configuration are isolated across tenants. Furthermore, the applications are provisioned on an isolated set of Avi Service Engines, not shared between tenants. This enables full tenancy.
This flexibility, combined with the Platform’s ability to assign users to single or multiple tenants, gives the Avi Platform a high degree of configurability to meet a range of enterprise requirements and situations.
For more on the actual implementation of load balancing, security applications and web application firewalls check out our Application Delivery How-To Videos.
Find out more about how the Avi platform here.