This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses the resource organization for multi-tenant resources.

Resource organization helps a multi-tenant solution with tenant-isolation and scale. There are specific tradeoffs to consider with multi-tenant isolation and scale-out across multiple resources. Azure’s resource limits and quotas and scaling the solution beyond these limits will be discussed.

When a multi-tenant solution is deployed, a decision needs to be taken whether the resources should be dedicated or shared. There are many categories of resources and there are many options and trade-offs. There are a range of options for tenant isolations. Considerations for tenancy model for a multitenant solution will provide more guidance and decide on the isolation policy. Multitenancy approaches and service specific guidelines are both applicable to the isolation policy.

The ability to scale must be planned for. There are limits and quotas to overcome and they vary with resource types, skus and subscriptions. Both scaling out and bin packing must be considered. Scaling, unlike tenant isolation, is dependent on growth.  If the number of tenants are going to increase rapidly, there is no need to over-engineer the scale-out strategy. But if it can be planned, then a scale-out strategy can be thought through.

When there is an automated deployment process and there is a need to scale across resources, the way to deploy and assign tenants must be decided. As we are approaching the number of tenants that can be assigned to a specific resource, we must detect the threshold. When we plan to deploy new resources, it must be decided whether they will be ready just in time or ready ahead of time.

When assumptions are made in code and configuration, they can limit the ability to scale. There might be a need to scale out to multiple storage accounts, but the application tier might be assuming a single storage account for all tenants.

Azure resources are deployed and managed through a hierarchy. Most resources are deployed into resource groups which are contained in subscriptions. This hierarchy pertains to a tenant. When we deploy the resources, we have the option to isolate them at different levels. Different models can be used in different components of the same solution.

Resources that are shared across multiple instances can still achieve isolation on a single instance for all the workloads from the tenants. When we run a single instance of resource, the service limits, subscription limits and the quota applies. When these limits are encountered, the shared resources must be scaled out.

In all these cases, the application code must be fully aware of multitenancy, and it restricts access to the data for a specific tenant.

Resources can also be dedicated to a single tenant where a single copy of the application is provided to the tenant. A clear naming convention, strategy, resource tags, or a tenant catalog database is needed.