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:
The answer goes through each of the points that we will see in this series of articles:
We will start this path, by reviewing what levels of isolation between each of our tenants we can consider offering.
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:
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.
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:
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:
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:
As you can guess, it is represented in this way:
In this scenario, everything is shared by all tenants:
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.