Multitenancy Part 4:

This is a continuation of a series of articles on Microsoft Azure from an operational point of view that surveys the different services from the service portfolio of the Azure public cloud. The most recent article discussed architecting multitenant applications on Azure. This picks up the discussion on tenant model and lifecycle from the differentiation between logical and physical tenants. 

 

One of the key differences between logical and physical tenant is how the isolation is enforced. When multiple logical tenants share a single set of infrastructure, it relies on application code and a tenant identifier in the database to keep each tenant’s data separate. Physical tenants have their own infrastructure so code running on them find it less important to be aware that this is a multi-tenant environment. Physical tenants are also referred to as deployments, super tenants, or stamps. 

Tenant isolation can run deep. For example, having a single set of shared infrastructure, with separate instances of the application and separate databases for each tenant or sharing some common resources while keeping other resources separate for each tenant or keeping data on a separate physical infrastructure. Separate resources for each tenant is a practice for public cloud as well and often translates to separate physical infrastructure using dedicated hosts.

The level of isolation impacts aspects of the architecture such as security, cost, performance, reliability and responsiveness to individual tenants’ needs. When the infrastructure is deployed that is dedicated to one tenant, the configuration of the resources can be tuned to meet the specific needs of that tenant. The architecture of the software deployed also determines the level of isolation. For example, there’s a three-tier solution architecture where the user interface might be a shared multi-tenant web application and all of the tenants access a single hostname. In this case, the application is a shared layer with shared message queues and the data tier can be isolated databases, tables or containers. We can also consider mixing and matching different levels of isolation at each tier. In the case of public cloud, the level of isolation might depend on cost, complexity, customer requirements and the number of resources that can be reached before reaching quotas and limits.

Single-tenant deployments are easy to deploy using automation that repeats the deployment of a dedicated set of infrastructure for each tenant. Solutions built using the model makes use of infrastructure as a code and the resource manager APIs.

On the other hand, the multi-tenant deployments can be such that all the components are shared. There is only one set of infrastructure, and all the components share it. One of the biggest advantages of this approach is that the data does not have to be migrated between deployments.

 

Reference to multitenancy: https://1drv.ms/w/s!Ashlm-Nw-wnWhLMfc6pdJbQZ6XiPWA?e=aWj2Z0