About multitenancy
Unfortunately, this term does not have a good Russian-language counterpart. "Wikipedia" gives the translation "multi-leased, multiple lease". This is sometimes called “multiple ownership.” These terms may be somewhat confused, since the subject matter is not connected with rent or possession. This is a matter of software architecture and its organization of operation. And the latter is no less important.
We began to form our understanding of multitenancy at the same time as we began to design an approach to the cloud (service) work model of 1C: Enterprise. That was a few years ago. And since then, our understanding is constantly expanding. We are constantly discovering in this subject more and more new aspects (pros, cons, difficulties, features, etc.).
Sometimes developers understand multitenancy as a completely simple thing: “in order for the data of several organizations to be stored in one database, you need to add a column with the organization identifier to all the tables and set a filter on it”. We, too, of course, began our study of the issue from this point on. But rather quickly they realized that this was only one glade (also, by the way, not easy). In general, it is a "whole country."
')
The basic idea of ​​multitenancy can be described something like this. A typical application is a cottage designed for one family, which uses its infrastructure (walls, roof, water supply, heating, etc.). A multitenancy application is an apartment building. In it, each family uses the same composition of the infrastructure, but the infrastructure itself is implemented for the entire house as a whole.
Is the multitenancy approach good or bad? You can find very different opinions on this. It seems that there is no “good or bad” at all. You need to compare the pros and cons in the context of specific tasks. But this is a separate topic ...
In the simplest sense, the goal of multitenancy is to reduce the cost of maintaining the application by “socializing” infrastructure costs. This is the same movement as reducing the cost of the application due to the use of a lottery solution (possibly with adjustment and refinement), rather than writing “to order”. Only in one case the development is socialized, and in the other - exploitation.
And, again, there is no direct link to the method of sale. The multitenancy architecture can also be fully applied in the corporate or departmental IT infrastructure for automating a large number of similar branches and holding companies.
We can say that multitenancy is not just a matter of organizing data storage. This is a model of the entire application (including a significant part of the aspects of its architecture, and a deployment model, and organization of services).
The most difficult and interesting thing in the multitenancy model seems to us that the essence of the application is “forked”. Some of the functionality works with specific data areas (apartments) and is “not interested” in the fact that there are residents in other apartments. And the part perceives the house entirely and works at once for all tenants. At the same time, the latter cannot abstract from the fact that these are still separate apartments, and the necessary level of granularity and security must be ensured.
In 1C: Enterprise, the multitenancy model is implemented at the level of several technologies. These are the mechanisms of the 1C: Enterprise platform, the mechanisms of 1C: Technology of publishing 1cFresh solutions and 1C: Technology of developing 1cFresh solutions , BSP mechanisms (libraries of standard subsystems).
Each of these items contributes to the construction of a common infrastructure of an apartment building. Why is this implemented in several technologies, and not in one, for example, in a platform? First of all, because part of the mechanisms, in our opinion, is quite appropriate to modify for a specific deployment option. But in general terms, this is a difficult question, and we are constantly facing a choice - at what level is it better to implement one or another aspect of multitenancy.
Obviously, the basic part of the mechanisms was required to be implemented in the platform. Well, for example, the actual separation of data. What usually start talking about multitenancy. But in the end, the multitenancy model “traveled” through a substantial part of the platform's mechanisms and required their refinement, and in some cases, rethinking.
At the platform level, we implemented exactly the basic mechanisms. They allow you to create applications that work in the model multitenancy. But in order for applications to “live and work” in such a model, you need to have a system for managing their “life activity”. The 1cFresh technologies and the unified layer of business logic at the level of the BSP are responsible for this. Just as in an apartment building, the infrastructure provides residents with everything they need, and 1cFresh technology provides all the necessary applications that work in a multitenancy model. And so that applications can interact with this infrastructure (without significant modifications), they fit the appropriate "connectors" in the form of BSP subsystems.
From the point of view of the mechanisms of the platform, it is easy to notice that as we gain experience and develop the cloud use case of 1C: Enterprise, we are expanding the mechanisms that are involved in this architecture. We give one example. In the multitenancy model, the roles of the participants in application servicing change significantly. Significantly increases the role (level of responsibility) of those responsible for operating applications. They have become necessary to have more powerful application control tools. Because application users (tenants) trust first of all the provider with whom they work. To this end, we have implemented in version 8.3 a new security profile mechanism . This mechanism allows the provider's administrators to limit the freedom of application developers to the necessary level of security - in essence, isolating the work of the application for each tenant within a certain sandbox framework.
No less interesting is the architecture for managing applications running in multitenancy mode (which is implemented in 1cFresh and BSP technologies). Here, compared to the conventional deployment model, the requirements for automation of management processes increase significantly. There are dozens of such processes: creating new data areas (“apartments”), updating applications, updating regulatory information, backing up, etc. And, of course, requirements for reliability and availability are increasing. For example, to ensure reliable interaction of applications with control system components, we implemented asynchronous call system technology with guaranteed delivery.
A very subtle point is the way in which data and processes are socialized. It seems simple (if it seems to someone) only at first glance. The greatest difficulty is the balance between centralization of data and processes and decentralization. On the one hand, centralization allows to reduce costs (disk space, processor resources, efforts of administrators ...). On the other hand, limits the freedom of "tenants". This is just one of the moments of “splitting” the application, when the developer needs to think simultaneously about the application in the narrow sense (serving one “apartment”) and in the broad sense (serving all “tenants” at once).
As an example of such a "dilemma" can provide regulatory reference information. Of course, there is a great temptation to make it common to all the "tenants" of the house. This allows you to store it in one copy and update it for all at once. But it happens that some tenant needs specific changes. Oddly enough, but in practice it is found, even for information that is specified by regulators (government agencies). It turns out a difficult question: to socialize or not to socialize? It is tempting, of course, to make general information for everyone and private for those who want it. And this already leads to a very difficult implementation. But we are working on it ...
Another example is the design of the implementation of regular processes (performed on a schedule, initiated by the management system, etc.). On the one hand, they can be implemented for each data region separately. It is easier and more convenient. But, on the other hand, such a small granularity creates a large load on the system. To reduce the load, you need to implement socialized processes. But they require more careful study.
Of course, this begs a very significant question. How do application developers get multitenancy? What do they need to do for this? Of course, we strive to ensure that the burden of technological and infrastructure issues falls as much as possible on the shoulders of the supplied technology, and the application developer would think only in the tasks of business logic. But as with other important architectural issues, application developers need to have some idea of ​​how to work in the multitenancy model, and some development efforts will be needed. Why? Because there are moments that the technology can not provide automatically without taking into account the semantics of the data. For example, the same definition of the limits of socialization of information. But we try to keep these difficulties small. Examples of the implementation of such applications already exist.
An important point in the context of the implementation of multitenancy in 1C: Enterprise is that we create a hybrid model in which one application can work both in multitenancy mode and in normal mode. This is a very difficult task and the subject of a separate discussion.
We began to form our understanding of multitenancy at the same time as we began to design an approach to the cloud (service) work model of 1C: Enterprise. That was a few years ago. And since then, our understanding is constantly expanding. We are constantly discovering in this subject more and more new aspects (pros, cons, difficulties, features, etc.).
Sometimes developers understand multitenancy as a completely simple thing: “in order for the data of several organizations to be stored in one database, you need to add a column with the organization identifier to all the tables and set a filter on it”. We, too, of course, began our study of the issue from this point on. But rather quickly they realized that this was only one glade (also, by the way, not easy). In general, it is a "whole country."
')
The basic idea of ​​multitenancy can be described something like this. A typical application is a cottage designed for one family, which uses its infrastructure (walls, roof, water supply, heating, etc.). A multitenancy application is an apartment building. In it, each family uses the same composition of the infrastructure, but the infrastructure itself is implemented for the entire house as a whole.
Is the multitenancy approach good or bad? You can find very different opinions on this. It seems that there is no “good or bad” at all. You need to compare the pros and cons in the context of specific tasks. But this is a separate topic ...
In the simplest sense, the goal of multitenancy is to reduce the cost of maintaining the application by “socializing” infrastructure costs. This is the same movement as reducing the cost of the application due to the use of a lottery solution (possibly with adjustment and refinement), rather than writing “to order”. Only in one case the development is socialized, and in the other - exploitation.
And, again, there is no direct link to the method of sale. The multitenancy architecture can also be fully applied in the corporate or departmental IT infrastructure for automating a large number of similar branches and holding companies.
We can say that multitenancy is not just a matter of organizing data storage. This is a model of the entire application (including a significant part of the aspects of its architecture, and a deployment model, and organization of services).
The most difficult and interesting thing in the multitenancy model seems to us that the essence of the application is “forked”. Some of the functionality works with specific data areas (apartments) and is “not interested” in the fact that there are residents in other apartments. And the part perceives the house entirely and works at once for all tenants. At the same time, the latter cannot abstract from the fact that these are still separate apartments, and the necessary level of granularity and security must be ensured.
In 1C: Enterprise, the multitenancy model is implemented at the level of several technologies. These are the mechanisms of the 1C: Enterprise platform, the mechanisms of 1C: Technology of publishing 1cFresh solutions and 1C: Technology of developing 1cFresh solutions , BSP mechanisms (libraries of standard subsystems).
Each of these items contributes to the construction of a common infrastructure of an apartment building. Why is this implemented in several technologies, and not in one, for example, in a platform? First of all, because part of the mechanisms, in our opinion, is quite appropriate to modify for a specific deployment option. But in general terms, this is a difficult question, and we are constantly facing a choice - at what level is it better to implement one or another aspect of multitenancy.
Obviously, the basic part of the mechanisms was required to be implemented in the platform. Well, for example, the actual separation of data. What usually start talking about multitenancy. But in the end, the multitenancy model “traveled” through a substantial part of the platform's mechanisms and required their refinement, and in some cases, rethinking.
At the platform level, we implemented exactly the basic mechanisms. They allow you to create applications that work in the model multitenancy. But in order for applications to “live and work” in such a model, you need to have a system for managing their “life activity”. The 1cFresh technologies and the unified layer of business logic at the level of the BSP are responsible for this. Just as in an apartment building, the infrastructure provides residents with everything they need, and 1cFresh technology provides all the necessary applications that work in a multitenancy model. And so that applications can interact with this infrastructure (without significant modifications), they fit the appropriate "connectors" in the form of BSP subsystems.
From the point of view of the mechanisms of the platform, it is easy to notice that as we gain experience and develop the cloud use case of 1C: Enterprise, we are expanding the mechanisms that are involved in this architecture. We give one example. In the multitenancy model, the roles of the participants in application servicing change significantly. Significantly increases the role (level of responsibility) of those responsible for operating applications. They have become necessary to have more powerful application control tools. Because application users (tenants) trust first of all the provider with whom they work. To this end, we have implemented in version 8.3 a new security profile mechanism . This mechanism allows the provider's administrators to limit the freedom of application developers to the necessary level of security - in essence, isolating the work of the application for each tenant within a certain sandbox framework.
No less interesting is the architecture for managing applications running in multitenancy mode (which is implemented in 1cFresh and BSP technologies). Here, compared to the conventional deployment model, the requirements for automation of management processes increase significantly. There are dozens of such processes: creating new data areas (“apartments”), updating applications, updating regulatory information, backing up, etc. And, of course, requirements for reliability and availability are increasing. For example, to ensure reliable interaction of applications with control system components, we implemented asynchronous call system technology with guaranteed delivery.
A very subtle point is the way in which data and processes are socialized. It seems simple (if it seems to someone) only at first glance. The greatest difficulty is the balance between centralization of data and processes and decentralization. On the one hand, centralization allows to reduce costs (disk space, processor resources, efforts of administrators ...). On the other hand, limits the freedom of "tenants". This is just one of the moments of “splitting” the application, when the developer needs to think simultaneously about the application in the narrow sense (serving one “apartment”) and in the broad sense (serving all “tenants” at once).
As an example of such a "dilemma" can provide regulatory reference information. Of course, there is a great temptation to make it common to all the "tenants" of the house. This allows you to store it in one copy and update it for all at once. But it happens that some tenant needs specific changes. Oddly enough, but in practice it is found, even for information that is specified by regulators (government agencies). It turns out a difficult question: to socialize or not to socialize? It is tempting, of course, to make general information for everyone and private for those who want it. And this already leads to a very difficult implementation. But we are working on it ...
Another example is the design of the implementation of regular processes (performed on a schedule, initiated by the management system, etc.). On the one hand, they can be implemented for each data region separately. It is easier and more convenient. But, on the other hand, such a small granularity creates a large load on the system. To reduce the load, you need to implement socialized processes. But they require more careful study.
Of course, this begs a very significant question. How do application developers get multitenancy? What do they need to do for this? Of course, we strive to ensure that the burden of technological and infrastructure issues falls as much as possible on the shoulders of the supplied technology, and the application developer would think only in the tasks of business logic. But as with other important architectural issues, application developers need to have some idea of ​​how to work in the multitenancy model, and some development efforts will be needed. Why? Because there are moments that the technology can not provide automatically without taking into account the semantics of the data. For example, the same definition of the limits of socialization of information. But we try to keep these difficulties small. Examples of the implementation of such applications already exist.
An important point in the context of the implementation of multitenancy in 1C: Enterprise is that we create a hybrid model in which one application can work both in multitenancy mode and in normal mode. This is a very difficult task and the subject of a separate discussion.
Source: https://habr.com/ru/post/326654/
All Articles