How to Manage Your Customers in an Azure Multi-Tenant Environment | Part 1: How to isolate each Tenant?
With the appearance of Cloud Computing, one of the most common uses that can be given to it is to deploy our applications using the SaaS (Software as a Service) model. Without being aware of it or being so, we have been using this model for many years and we do it every day: we listen to Podcasts with an application, the same with our music, we upload our documents to the cloud, we send mail, etc.
Many organizations require a SaaS model, and this can be accessed by different types of “entities”. They can be other organizations (such as a payroll management SaaS) – A business to Business B2B model -, they can be individuals (such as a podcast playback SaaS) – Business to Customer B2C model -.
Be the “entities” that are accessing our SaaS in the cloud; these are called “Tenant”.
The question that I would like to be able to help answer for each of our clients in Itequia who require a scenario similar to the ones described above is:
- How do I manage my environment (no longer just SaaS), but all the associated infrastructure, in a multi-tenant environment?
- How do I ensure that each tenant sees their data while giving the illusion that they are using a dedicated system?
The answer goes through each of the points that we will see in this series of articles:
- Understand the requirements of our tenants
- Understand our business model and requirements
- We must consider what level of isolation (data, resources, etc.) we need for our solution
We will start this path, by reviewing what levels of isolation between each of our tenants we can consider offering.
Insulation Levels Between Tenants
To begin with, one of the points to take into account is knowing how to differentiate what level of isolation we will apply for each tenant in our system. We can take these elements into account when thinking about what we isolate:
- Application logic
- Data
- Azure resources
And, as in everything, it is not black or white, but there are different levels of isolation that we can consider depending on the requirements of the tenants (for example, GDPR compliance), system availability requirements, etc.
So we can see different models of Isolation together with the considerations that we must take into account.
Fully Isolated
In this model, nothing is shared. Each resource is a resource dedicated to each tenant:
It is the Individual Deployment or Stamp (stamp) since every time we create a new tenant in our system we apply (stamp) an environment template.
In this stage:
- Each tenant has their environment
- At the workload level, it is optimal since we only have to apply “the stamp”
- It is the model that has the highest cost in terms of resources since none can be shared
Vertical Partition
In this case, it is about applying the template shared by several tenants at the same time and we also apply it individually to one or more of them.
The application of this approach is usually governed by user requirements and will provide us with some aspects such as:
- Deploy our solution globally (various Azure regions), increasing system performance by being able to offer it closer to each tenant
- Offer various pricing modalities for our system
- Offer different SLAs
- Roll out updates to our app gradually
Horizontal Partition
This model would respond to:
In this example, we’re sharing the app among all of our tenants, but we’re keeping each tenant’s data isolated in different Azure databases.
In this case, keep in mind that:
- We can reach the maximum of resources depending on how “active” the tenants are
- We have to know how to determine which component will be dedicated and which will be shared and why (for example, performance or compliance criteria)
Fully Shared
As you can guess, it is represented in this way:
In this scenario, everything is shared by all tenants:
- It has a great cost advantage since we make more effective use of resources
- Easier management, everything is in one place, maintenance complexity is less
- We will have to be very careful since, in this case, it must be the logic that separates the data from the tenants, redirecting the requests to the databases of the tenants that are making the request.
- You also have to pay attention to the use of resources by each of the tenants
- If we have many tenants we should not forget about the resource limits of Azure
But now we have only seen some of the resources (Web server and database), but our decision may vary when more resources come into play: analytics, performance, Azure AD, Application Insights, Artificial Intelligence, etc.
In this first article of the series, we have learned the different options we have when it comes to isolating the tenants of our application.
We hope to see you again in part II, where we will review: limits, scaling, compute management, costs, and pricing.