Unfortunately, this term does not have a good Russian-language counterpart. Wikipedia gives "multi-tenancy, multiple lease". This is sometimes referred to as "multiple ownership". These terms can be somewhat confusing, since the subject matter is not inherently related to either rent or ownership. This is a question of the software architecture and the organization of its 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) model of 1C:Enterprise operation. This was several years ago. And since then, our understanding has been constantly expanding. We are constantly discovering more and more new aspects of this subject (pluses, minuses, difficulties, features, etc.).
Sometimes developers understand multitenancy as a quite simple subject: “in order for the data of several organizations to be stored in one database, you need to add a column with the organization ID to all tables and set a filter on it.” Of course, we also began our study of the issue from that moment. But they quickly realized that this was only one clearing (also, by the way, not easy). In general, this is a “whole country”.
The basic idea of multitenancy can be described something like this. A common application is a single-family cottage that 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? There are 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 to be solved. But that's a separate issue...
In its simplest sense, the goal of multitenancy is to reduce the cost of maintaining an application by “sharing” infrastructure costs. This is the same movement as reducing the cost of the application through the use of a circulation solution (possibly with customization and refinement), and not writing “to order”. Only in one case development is socialized, and in the other - exploitation.
And, we repeat, there is no direct link to the method of sale. The multitenancy architecture can also be used in a corporate or departmental IT infrastructure to automate a large number of branches of the same type, holding enterprises.
We can say that multitenancy is not just a matter of organizing data storage. This is the model of the entire application (including a significant part of the aspects of its architecture, and the deployment model, and the service organization).
The most difficult and interesting thing about the multitenancy model, it seems to us, is that the essence of the application is “forked”. Part of the functionality works with specific data areas (apartments) and is "not interested" in the fact that there are tenants in other apartments. And some perceive the house as a whole and work immediately for all residents. At the same time, the latter cannot ignore the fact that these are still separate apartments, and it is necessary to ensure the necessary level of granularity and security.
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" and "”, mechanisms (libraries of standard subsystems).
Each of these items contributes to the construction of the overall 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, in our opinion, it is quite appropriate to modify some of the mechanisms for a specific deployment option. But in general terms, this is not an easy question, and we are constantly faced with a choice - at what level is it better to implement one or another aspect of multitenancy.
Obviously, the basic part of the mechanisms needed to be implemented in the platform. Well, for example, the actual separation of data. What usually starts a conversation about multitenancy. But in the end, the multitenancy model "travelled" through a significant 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 multitenancy model. But for applications to “live and work” in such a model, you need to have a system for managing their “life activity”. 1cFresh technologies and a unified layer of business logic at the BSP level are responsible for this. Just as in an apartment building, the infrastructure provides residents with everything they need, so 1cFresh technologies provide everything necessary for applications running in a multitenancy model. And so that applications can interact with this infrastructure (without significant modifications), the corresponding “connectors” are placed in them in the form of BSP subsystems.
In terms of platform mechanisms, it is easy to see that as we gain experience and develop the cloud 1C:Enterprise use case, we expand the list of mechanisms that are involved in this architecture. Let's take one example. In the multitenancy model, the roles of application service participants change significantly. The role (level of responsibility) of those responsible for the operation of applications is significantly increased. It became necessary for them to have more powerful application control tools. Because application users (residents) trust first of all the provider with which they work. To do this, we implemented in version 8.3 a new . This mechanism allows provider administrators to limit the freedom of application developers to the necessary level of security - in fact, to isolate the operation of the application for each tenant within a certain sandbox.
No less interesting is the architecture for managing applications operating in multitenancy mode (what is implemented in 1cFresh and BSP technologies). Here, in comparison with the conventional deployment model, the requirements for automation of management processes are significantly increased. There are dozens of such processes: creating new data areas (“apartments”), updating applications, updating regulatory information, backup, etc. And, of course, the requirements for the level of reliability and availability are increasing. For example, to ensure reliable interaction between applications and control system components, we implemented the technology of an asynchronous call system with guaranteed delivery.
A very subtle point is the way data and processes are shared. 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 you to reduce costs (disk space, processor resources, administrator efforts ...). On the other hand, it restricts the freedom of "residents". This is just one of the moments of the "bifurcation" of the application, when the developer needs to think at the same time about the application in the narrow sense (serving one "apartment") and in the broad sense (serving all the "tenants" at once).
As an example of such a “dilemma”, reference information can be cited. Of course, there is a great temptation to make it common for all the "residents" of the house. This allows you to store it in one copy, and update it for everyone at once. But it happens that some tenant needs specific changes. Oddly enough, but in practice this occurs, even for information that is specified by regulators (state bodies). 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 wish. 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 (run on a schedule, initiated by the control system, etc.). On the one hand, they can be implemented for each data area separately. It's easier and more convenient. But, on the other hand, such a fine granularity creates a large load on the system. To reduce the load, it is necessary to implement socialized processes. But they require more careful study.
Of course, this raises a very important question. And how can application developers ensure that they work in multitenancy mode? What do they need to do for this? Of course, we strive to ensure that the burden of technological and infrastructure issues falls on the shoulders of the supplied technology as much as possible, and the application developer thinks only in business logic tasks. But as with other important architectural issues, application developers need to have some understanding of working in a multitenancy model and some effort in application development will be required. Why? Because there are moments that technology cannot provide automatically without taking into account the semantics of the data. For example, the same definition of the boundaries of the 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 are creating 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: habr.com