Designing for multi-tenancy
The major benefit of multi-tenancy is cost savings due to shared infrastructure and operational efficiency of managing a single instance of the application across multiple customers or tenants. However, multi-tenancy introduces complexity, and issues can arise when a tenant's action or usage can affect the performance and availability of the application for other tenants on the shared infrastructure. In addition, security, customization, upgrades, recovery, and so on, requirements of one tenant can create issues for other tenants and/or introduce further complexity.
Additionally, customers are concerned about their business-critical data residing on public cloud infrastructure (in the hands of a third-party SaaS application provider). It is of vital importance to ensure that the data architecture is robust and secure to satisfy the security standards, privacy policies, regulatory requirements, etc. in place at large enterprises (as well as smaller businesses). For example, businesses in the financial or healthcare sector are governed by a host of very strict regulatory requirements in terms of privacy, and location and usage of customer data. We need to have strict access control mechanisms to ensure a tenant does not access resources belonging to a different tenant. Simultaneously, we also need to ensure that mechanisms we use are operationally cost-effective and easy to administer.
Customization requirements can easily derail a SaaS product company’s business model. Handling differences in data requirements, UI interfaces, business logic, and business workflows requires careful design and implementation across the tiers. In addition, provisioning new tenants, measuring resource usage per tenant, and being able to respond to differences in Quality of Service SLAs per tenant can impose further strain on designers of such applications.
In the multi-tenancy models discussed in Chapter 1, Cloud 101 – Understanding the Basics, we discussed models that may lie anywhere on the shared-nothing to share-everything continuum. While technical ease may be a key factor from the IT department’s perspective, the cloud architect should never lose sight of the business implications and costs of selecting the appropriate approach to implementing multi-tenancy.
Whatever the multi-tenancy model, the data architecture needs to ensure robust security, extensibility, and scalability in the data tier. For example, storing a particular customer’s data in a separate database leads to the simplest design and development approach. Having data isolation is also the easiest and the quickest to both understand, and explain to your customers.
It is very tempting to offer tenant-specific customizations when each tenant’s data is stored in separate databases. However, this is primarily done to separate data and associated operations, and not to arbitrarily allow dramatic changes to the database schema per tenant.
In this model, suitable metadata is maintained to link each database with the correct tenant. In addition, appropriate database security measures are implemented to prevent tenants from accessing other tenants' data. From an operations perspective, backups and restores are simpler for separate databases as they can be executed without impacting other customers. However, this approach can lead to higher infrastructure and licensing related costs.
Typically, you would offer this approach to your bigger customers who may be more willing to pay a premium to isolate their data. Larger enterprise customers prefer database isolation for higher security, or in some cases to comply with their security policies. On a related note, such customers may also demand more customization.
While architecting multi-tenanted applications, pay particular attention to the expected number of tenants, storage per tenant, expected number of concurrent users, regulatory and policy requirements, and so on. If any of these parameters are heavily skewed in favor of a particular tenant then it may be advisable to isolate their data.
For applications that have a few tables in their database schema, an approach that shares the database server instance across multiple tenants but has a separate database schema for each tenant can be used. This approach is relatively simple to implement and offers flexibility for custom tables to be defined per tenant. However, data restore for a particular tenant can impact other tenants hosted on the same database instance. This approach is often a preferred approach as it can reduce costs while separating out the data of each tenant.
In a shared database, with a shared schema, approach, the costs are minimized but the complexity of the application is much greater. This model works well for cost-conscious customers. However, restoring a customer's data is complicated, as you will be restoring specific rows belonging to a specific tenant while other customers are using the system. Aside from possibly impacting other tenants using the shared database, it can significantly add complexity to scheduling such operations and communicating about them to all other tenants.
In cloud architectures, the main factors to consider while implementing multi-tenancy are data security, extensibility, and scalability.