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.

 The architectural considerations for a multi-tenant solution architecture are about the resources for the tenants. Some are shared and others are dedicated to a tenant. In a multi-tenant architecture, there is cost and operational efficiency but it introduces complexities which include factors such as whether a tenant maps to a user or a group, how much isolation is required between the tenants, what pricing models will the solution offer, how will that affect the requirements, what level of service to provide the tenants, how to meet the scaling demand from the tenants, any unusual or special requirements pertaining to a tenant, how to monitor, manage, automate, scale and govern the Azure environment, and how multitenancy impacts this.

 

The choice of tenancy models is very important to designing the multi-tenant architecture. There are primarily two models - the business-to-business model and the business-to-consumer model. The former requires tenant isolation for organizations, divisions, teams, and departments while the latter is about individual consumers. The business-to-consumer model must respect privacy and security for the data and the business-to-business model must respect regulatory compliance.

 

The tenant lifecycle depends on the tenant. Solutions that are software-as-a-service may want to honor customer requests for trials with a trial tenant. Questions about rigor for trial data, infrastructure for trial tenants, purchase option after trials and limits imposed on trial tenants must be answered. Regular tenants can be onboarded as the first step of their lifecycle which involves routines for allocation and initialization that could also be automated, setting up protection of data, meeting compliance standards, preparing for disaster recovery and setting up pricing options and billing models. If the customers require a pre-production environment, onboarding might be different since expectations around availability might be relaxed.

 

Applying updates to tenant’s infrastructure and scaling might need to consider traffic patterns such as seasonal variations and changes in the level of consumption. Noisy neighbor issues might need to be worked out when a subset of tenant scales unexpectedly and impacts the performance of other tenants. Mitigations might include scaling individual tenants’ infrastructure, moving tenants between deployments and provisioning capacity to exceed demand.

 

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