How to manage your customers in an Azure multitenant environment | Part 2: Limits, Scaling, Life Cycle of a Tenant

In the first part of this series of articles on How to manage your clients in a multitenant environment in Azure, we reviewed the different strategies and levels of isolation that we can apply when isolating our Tenants:

• Fully insulated
• Vertical Partition
• Horizontal Partition
• Fully Shared

These strategies showed us the path between the two extremes, totally isolated Vs shared, which we can see in this figure:

Making a decision governed by the level of isolation that our users require must be accompanied by other aspects that have more to do with our business model. Therefore, we must also consider elements such as:

• Limits and scaling
• Architecture and deployment decisions

In this second part of the serie; We will go through these points to have the maximum number of tools available to follow the path toward making the best final decision.

Limits and scaling in multitenant environment

When thinking about how we are going to deploy the isolation level of each tenant in Azure, we must bear in mind that Azure has its limits. So we will have to compare the decision and the approach that we design, with the limits of Azure, which we can find in Azure Limits.

For example, let’s imagine a scenario where we decide to apply a total isolation strategy.

In this case, the most appropriate Azure tool is the use of a Resource Group for each of the tenants within our subscription.

It is a more than correct decision, in which we must take into account the limits of Azure in that we can put a maximum of 980 resource groups within a subscription (at the time of writing this article).

In this way, as the number of our tenants grows, we may find ourselves in the following situation, in which we can no longer create more Resource Groups in our subscription:

Therefore, if we want to continue growing the number of clients, we must expand to a greater number of subscriptions:

But, as expected, we can find situations like this beyond the scenario of total isolation.

Let’s think, for example, in the case of a shared resource, such as an Azure Storage Account. It can be accessed by the maximum number of users that is defined as a limit in Azure:

In Azure, each resource has its limits. We must take them into account when planning the deployment strategy of our solution.

Architecture and Deployment

When talking about architecture and deployment, we must also take into account the different deployment architectures for a multitenant environment that we can review in Architectural approaches for the deployment and configuration of multitenant solutions.

In this section, my intention is only to give some nuances to pay attention to since the details will be addressed in later articles. Keep up to date with our blog to be able to read all the news.

Starting from this premise, it is important to note that when considering the architecture of our system and the deployment options that best fit all the decisions we have made so far, we must take into account points such as:

• Planning of how the tenants will do the onboarding in our system:
  • Will it be automatic?
  • Will it require any manual intervention on our part or the part of the client?
• What scalability do we want to apply to our solution?
• How will it unfold?
• How will we design security?
• Which of all the technical deployment options is the most suitable for our needs?:
  • Use a Pipeline
  • Use a control plane
• Do we want our solution to be available in the Azure Marketplace?

As we have mentioned, all these points are outside the scope of this article, although ultimately what they want to tell us is that we pay attention to each of the points in the life cycle of a tenant:

1. Tenant Provisioning
2. Tenant Configuration
3. Operate the tenant
4. Tenant Deprovisioning

In summary, so far in this series of articles, we have learned how to manage a multitenant environment in Azure by going through:

• The different insulation options that we can apply
• Limits and scaling
• Architecture and deployment

We are waiting for you in part III, in which we will review aspects such as:

• Computing management
• Cost management
• Pricing model

Oriol Fernandez Moreno – Key Software Developer at Itequia