Multitenant Considerations In Azure

What is Multitenancy?

A multitenant solution serves multiple distint customers or tenants and they might be individual organizations or group of users.Examples include B2B solutions (like accounting software), B2C solutions (such as music streaming), and enterprise-wide platforms (like shared Kubernetes clusters).

a multitenant solution is mostly considered by those who building SaaS products.who mainly targeted for business or consumers.

Design Considerations for Multitenant Solution

Tenant Isolation

One of the biggest considerations in the design of a multitenant architecture is the level of isolation that each tenant needs. Isolation can mean different things:

• Having a single shared infrastructure, with separate instances of your application and separate databases for each tenant.
• Sharing some common resources, but keeping other resources separate for each tenant.
• Keeping data on a separate physical infrastructure. In the cloud, this configuration might require separate Azure resources for each tenant. It could even mean deploying a separate physical infrastructure by using dedicated hosts.

Tenancy Models

1. Automated single-tenant deployments

In an automated single-tenant deployment model, you deploy a dedicated set of infrastructure for each tenant.

• people who use this model use infrastructure as code (IaC) for repeating the infra creation and deployment for all customers and hence automate it.

• A key benefit of this approach is that data for each tenant is isolated, which reduces the risk of accidental leakage.

• cost efficiency is low, because you don't share infrastructure among your tenants. If a single tenant requires a certain infrastructure cost, 100 tenants probably require 100 times that cost.

2. Fully multitenant deployments

In this approach unlike single-tenant deployment here all components are shared. we will have only once set of infrastructure to deploy and maintain.

• operating this model is less expensive as components are shared accross tenants.even if we want to deploy with higher tiers or SKUs of resources still the overal deployment cost is lower the cost of single-tenant resources.
• Might have risk of memory leaks and down time affects all the tenants

3. Automated single-tenant deployments

This approach has combination of single-tenant and multitenant deployments. For example, you might have most of your customers' data and application tiers on multitenant infrastructures, but deploy single-tenant infrastructures for customers who require higher performance or data isolation.

• Deploy multiple instances of your solution geographically, and map each tenant to a specific deployment. This approach is particularly effective when you have tenants in different geographies.

• Since you're still sharing infrastructure, you can gain some of the cost benefits of using shared multitenant deployments. But codebase will probably need to be designed to support both multitenant and single-tenant deployments.

4. Horizontally partitioned deployments

In a horizontal deployment, you have some shared components but maintain other components with single-tenant deployments. For example, you could build a single application tier and then deploy individual databases for each tenant.

• Horizontally partitioned deployments can help you mitigate a noisy neighbor problem, if you identify that most of the load on your system is caused by specific components that you can deploy separately for each tenant.

• With a horizontally partitioned deployment, you still need to consider the automated deployment and management of your components, especially the components used by a single tenant.

Ref-https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/approaches/overview