Multi-tenancy is the practice of a shared resources physical or virtual running multiple, separate, and potentially competing software applications for different customers. The hardware and operating system are shared resources that all tenants can use to run their applications, leading to lower costs because one instance of the software can be used to serve many users. The separation of tenants also means that each tenant has a distinct identity, and the applications running on a shared server can be configured to only accept requests from certain users.
In a multi-tenant architecture, every customer runs on the same resources, which means that all customers can be impacted by another tenant's actions if proper isolation is not in place. While this situation may sound problematic, it is actually one of the greatest strengths of cloud computing. Having many users running in parallel enables cloud vendors to spread costs across their user base and provide services at prices far lower than what businesses could afford on their own. However, there are some risks associated with using shared hardware resources. If a single tenant causes problems with performance or security, this can create issues for other tenants who depend on those resources (for example, an application server that fails would prevent multiple clients from accessing its service).
In a multi-tenant architecture, the software instance is designed to serve multiple customers/users and this way you can have one single system serving all your clients at once while each tenant has their own data and specific access rights according to their subscription plan. Each customer may be an individual or company that has common access and privileges in comparison with other customers of different subscriptions.
There are two main approaches for using a multi-tenancy model:
One App Instance per Tenant (one tenant = one instance) where every user gets its own copy of every file from code libraries up to databases.
Multiple App Instances per Tenant (one tenant = several instances), where each user shares execution environments with other users but keeps its separate files space within his account - just like any SaaS product does it today (Google Docs).
The latter approach is more complex to implement and tune, but it's flexible in terms of application design. For example, you can create a tenant for each user type (e.g. developer, client) or separate tenants for different applications/features (e.g. CRM system, IoT platform).
With this approach, data shared between instances must be stored in some sort of central repository so that it can be accessed by all the client applications. That means dealing with issues such as database schema design, access control rules on the database objects, and so on; these become particularly important if you need to support different types of clients accessing the same data from different devices or via different protocols . For example, people using a browser-based interface might need totally different functionality than users running mobile apps or desktop software connecting over HTTP versus TCP/IP connections. Virtual machine images or containers can also be used instead of full virtualization where only certain processes are isolated into separate VMs; several cloud providers offer hosting services based on this model.
When a company has multiple branches or remote users, they must keep sensitive data separate from each other. The most important aspect of this type of setup is that individual tenants are completely isolated from one another to ensure the security and privacy of their information. To achieve tenant separation, companies utilize network firewalls for physical isolation and virtualization technologies for logical isolation.
In order set up secure multi-tenancy architecture there needs to work at several levels:
The architecture of the operating system. The operating system is responsible for managing different types of devices and their respective configurations, such as user profiles, power state, and permissions. This is done through a combination of hardware-based features (such as virtualization), software features (such as User Account Control or SELinux) and configuration options in the OS itself.
The security model used by the OS to enforce access control policies on data stored in memory, network connections or storage devices. Security models are based on three types: discretionary access control (DAC), mandatory access control (MAC) and least privilege (LP). DAC is based on individual users’ capabilities, while MAC focuses on groups/roles with specific rights and roles that can be assigned to users – these rights can be set within an organization via administrative tools such as Active Directory or Group Policy Editor; LP provides for least privileged accounts that have limited privileges relative to others with higher privileges.
Economics of Multiple Instances
The cost savings of the multiple-instance approach can be eclipsed by the difficulty of scaling a single instance as demand grows—increasing the performance of an individual instance on a single server can only be done by buying faster hardware, such as faster CPUs, more memory, and faster disk systems.
The multiple-instance approach can have huge benefits, but it’s important to consider the costs and tradeoffs before deciding which approach to use.
However, the multiple-instance approach can easily scale to meet increased demand by simply adding more instances. The approach is designed to scale well because it can be implemented as a series of instances distributed across multiple machines. Each instance runs in a separate process, and each instance has its own local disk space.
This means that the application can take advantage of shared resources such as CPU cores and database connections without having to worry about running into contention for these resources with other applications on the same machine.
Want to contribute or give feedback ? Send me a tweet or DM me on twitter 👇🏿