Multi-tenant system with the possibility of "customization"

Asked

Viewed 780 times

5

I am raising knowledge for the creation of a multi-tenant system. I’ve been taking a look at some references from MSDN, SOEN and SOPT, as well as several websites.

Although I have read the references, even clarifying many doubts, there are still some issues that are not yet fully clear to me. So I decided to come here to see if I could shed some light.

In the references I read, the two models to work with multi-tenant that most caught my attention were:

Isolated systems

This approach has some advantages, such as the ease of creating code and not worrying so much about security issues. However, I believe it is an illusory facility, and, as said, only for the development of the application, because the maintenance of the system would become costly as the number of customers increased.

Using this approach would also allow the possibility of customizing or customizing the system for the specific needs of the customer. And this possibility is important for this system.

Shared system

This approach hampers the development of implementation in view of the fact that security needs to be better designed to prevent unauthorised access to data that do not belong to the tenant. However, the system maintenance would be reflected for all customers. But this is not necessarily a good thing, because some customer may not want to update their system.

To make customization on this template I planned to use MEF to load dynamic plugins to extend system functionality to the tenant. And for the customization of the views I thought to use a structure like this: {tenant}/Views/.... If there was no view in the client folder would use a default system view even.

A few more considerations

The tenant access the system and may have a linked website. Ex: by accessing the site www.meusite.com.br he can see the "result" of the information he added to the system. On this website the client of tenant can access a restricted area. Customers of tenant are divided into 2 profiles: To and B.

An example to clarify:

The tenants will own dealerships that can pick up used cars for consignment sale. The tenant adds the car in the system and soon it becomes visible on the website to the customer with the 'Customer' profile. This profile can have a 'wish list' for example. And the customer with 'Owner' profile can also access the site in a restricted area to see how are the issues related to your vehicle.

Explained the situation the remaining doubts are as follows:

  • Using the isolated model the DBMS would be with many databases. What would be the possible implications of this?
  • Using the shared model, the operations in the database would not have a loss of performance due to the filters needed to ensure access to only the data of the tenant?
  • Still in the shared model, the increasing number of records in the table would be a further obstacle to performance?
  • Regarding the scalability of an application with this structure, what could be done to avoid performance problems?
  • It would be a good idea to use MEF to load extensions to controllers for the purpose of adding functionalities?
  • It would be possible to make the tenant is redirected to the 'public' content of the system?
  • How could you automate the creation of these tenants to reduce human interaction?
  • It would also be possible to make custom mailboxes available for these tenants. Ex: [email protected].
c# asp.net-mvc mvc saas

  • Could you elaborate on the last three questions? It was unclear what "public" content would be, what you understand about automating tenant creation and your specific difficulty with email boxes.

  • This answer will get huge. It will take me a while to type everything.

  • @Dherik the public content is as in the example of the conceissionário. It has the administrative vision of the system and a view as a website, where it would be like a display of registered vehicles, with option of predefined filters. In relation to automation would be something like: The tenant makes the online payment and the creation of the database and the other information necessary for it to use the system are generated without the need for human interaction.

2 answers

1

Using the isolated model the DBMS would be with many databases. What would be the possible implications of this?

It would take one publication per client. It would take a little work, but with a script it is possible to automate.

Using the shared model, operations in the database would not have a loss of performance due to the filters needed to ensure access to only tenant data?

They would, of course. You’d be dealing all the time with a customer identifier. It is one more column and therefore one more burden for performance. With a good architecture, this problem is not felt.

Still in the shared model, the increasing number of records in the table would be a further obstacle to performance?

If your architecture doesn’t agree, yes.

Regarding the scalability of an application with this structure, what could be done to avoid performance problems?

It depends on database technology, but as stated above, if your application has a good architecture the problems are mitigated naturally.

For relational databases, it would be interesting to study the performance of queries. There is an intense study of consultation plans in this article. Another alternative would be to use the Dapper together with the Entity Framework for caching queries.

It would be a good idea to use MEF to upload extensions to controllers for the purpose of adding features?

If the application is not gigantic, no.

MEF is recommended for huge and extensible systems. If your system doesn’t have this requirement (which, frankly, I don’t think is the case), there’s no need to use.

It would be possible to redirect the tenant site to the 'public' content of the system?

Yes. It all depends on the design pattern that will be used for the lieutenant application.

How could you automate the creation of these tenants to reduce human interaction?

It would also be possible to provide custom mailboxes for these tenants. Ex: [email protected].

It gets more as a hint: avoid numeric and sequential primary keys. It is known that the use of Guids penalties at least 10% of overhead, but the gain in implementation compensates the burden, such as the possibility of joining the bases without worrying about the keys.

The question of the input boxes is a broader problem: you would have to have a DNS sync mechanism, SMTP addresses, IMAP, POP... It’s possible, but it wouldn’t be simple.

  • Taking into account your experience, which option you would choose, the shared or the isolated?

  • Also, would you have any suggestions for modeling this architecture or a reference for me to base myself on? Another question is: the use of Orms does not add an overhead to the query?

  • I would do the isolated for reasons of cohesion and basic simplicity. A good start would be this article. The use of ORM’s adds overheads always, but it is an almost imperceptible burden given the ease of building the application.

1


Using the isolated model the DBMS would be with many databases. What would be the possible implications of this?

You would have a greater difficulty in maintaining the database, as SQL scripts would have to be applied multiple times instead of once and would have to monitor multiple databases (nothing a good tool can’t fix). But other than that, this is the best scenario in my opinion, because: already ensures that one tenant will not see data from another, decreases the risk of a corruption problem affect all tenant, possibility to move a specific bank to another environment, apply specific solutions for certain bank consultation profiles, etc.

Using the shared model, operations in the database would not have a loss of performance due to the filters needed to ensure access to only tenant data?

There will be, but it wouldn’t be that significant. This particular problem would be the least of your problems in such an application, in my view. I would be more concerned with the next question on the question of performance.

Still in the shared model, the increasing number of records in the table would be a further obstacle to performance?

If this application provides many records in some tables, you will probably have performance problems since you will have a single database of the data for all tenants. And this problem will affect in the same magnitude even tenants who have few records.

Regarding the scalability of an application with this structure, what could be done to avoid performance problems?

Webapi: use of http cache.

Entity Framework: use of second-level cache.

Database: assuming that all Fks already have index, it would closely monitor the most common queries in the database and create indexes for the data they access as well. These consultations may be identified by own third party tools for this or monitoring the performance of the system by some other general monitoring tool, such as the Newrelic, acting punctually in the consultations that are causing more problems of slowness. Anyway, I recommend that an experienced DBA can track this and help.

It would be a good idea to use MEF to upload extensions to controllers for the purpose of adding features?

I am going to owe this answer now, I will read first about MEF :).

But it depends on the degree of customization you plan to have among tenants. Some customizations I think could be extended to all tenants. It is important to evaluate this to make not only your life easier, but to make everyone more happy.

Now, if the customizations are really particular, you might also be interested to read about External Assembly.

Anyway, it would be important to detail what degree of customization you expect for tenant, because each case can be solved differently: will they have only distinct business rules for the same functionality? The screens are the same for everyone but with different validations? Are there many particular screens for tenants? There will be entire features present only in one of the tenants?

It would be possible to redirect the tenant site to the 'public' content of the system?

In the application, I see no particular problems of a multi-tenant system to solve this. You will be able to control without problems the different types of user profile of each tenant and which part of the site it will access, because the logic will be in the profile (which is common to all tenant, because the profile "Owner" will exist in all).

How could you automate the creation of these tenants to reduce human interaction?

If you are talking about creating a new tenant as soon as a new one appears, the best way is by scripts that prepare it for you. As the platform is Microsoft, it would be with Powershell. For everything you told me, should be done:

  • Database creation. The Powershell script would connect to the database and create the database (yes, it is possible).
  • Creation of tables and completion of domain tables. Imagining that it will use some mechanism of bank migration (as the Fluentmigrator), it would be enough to execute it to popular the newly created bank.
  • Population of the private information of the tenant. SMTP configuration, path to tenant logo, tenant superuser account, email from tenant, etc. It would be all settings belonging only to each tenant and which, in my opinion, could be in each tenant’s database for this type of application.
  • (optional) Create new directories in the application. Imagine that you will follow with the idea of {tenant}/Views, the script will create these directories which are only for tenants. But I think this is only necessary when the tenant really needs these directories, which as I understood it would be in moments that the tenant would have a screen of his own or something like that.

It would also be possible to provide custom mailboxes for these tenants. Ex: [email protected].

I believe the previous question answers this. You would leave these settings in the tenant database.

  • Thank you very much for your reply, as well as @Ciganomorrisonmendes have clarified many of my doubts. From what I understand, you would choose the isolated model, correct? How you would manage the versioning issue of each tenant as well as the customizations performed for them?

  • Yes, single mode. If you’re talking about the versioning of each tenant in the versioning control (Git, Svn, etc.), I would try to keep everyone on the same branch. If you create a branch for each tenant, the chances of each tenant branch becoming a "new application" and you lose control (even if you rebase/merge) is high. Customizations can be of different levels and may have different solutions. Unfortunately, I find it difficult to have a "killer" answer that will solve all cases of customization. If you want, give more details in the question of the degree of customization you expect to have in the application.

Browser other questions tagged c# asp.net-mvc mvc saas

You are not signed in. Login or sign up in order to post.