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 Service Fabric and this discusses architecting multitenant applications on Azure

Tenancy is about customers not users. Multiple users from a single organization can form a single tenant. Examples of multi-tenant applications include Business-to-Business solutions, Business-to-Consumer solutions and Enterprise-wide platform solutions. Building your own multi-tenant solution in Azure comes with some guidance. These are discussed below.

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 requirements from the tenants drive the architecture so getting a clearer understanding of the requirements will help meet them. Tenant expectations around how things should behave must be documented properly.  As an example, building a multitenant solution that sells to businesses in the financial services industry can highlight some of these considerations. The customers have very strict security requirements, and they need to provide a comprehensive list of every domain name that the solution uses, so they can add it to their firewall's allow list. This requirement affects the Azure services that are used by the multi-tenant service and the level of isolation that must be provided between the tenants. They also require that their solution has a minimum level of resiliency. There may be other expectations, that must be considered across the whole solution.

The choice of tenancy models is very important to designing the multi-tenant architecture. The business-to-business model differs significantly from the business to consumer model. The former requires tenant isolation for organizations, divisions, teams and departments some of which may be spread across geographical regions. A single customer might need to map to multiple tenants.  A customer might want to maintain two instances of these services separated for production and development environments. The second model is one where each consumer can be a tenant. Grouping depends more dynamically on associations between users. For example, a music streaming service might support both individuals and their families.

 

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