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:
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.
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?:
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:
Operate the tenant
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:
Oriol Fernandez Moreno – Key Software Developer at Itequia
Find out how to deliver modern digital solutions with our newsletter