About Multitenancy
Our understanding of multitenancy has developed since we started designing the 1C Enterprise cloud (service) model. This was several years ago. Since then, we have gone much further in understanding this concept, and we still keep discovering new aspects: pros and cons, complexities and peculiarities.
Some developers describe multitenancy as simple as follows. In order to keep data of several companies in a single database, you should append all tables with the company id column and apply the corresponding filter. This was our starting point. We quickly realized this was just a small "village" that can be pretty complicated, though. At that, the concept is much bigger and holds a whole world within.
I believe if you want to picture an idea of multitenancy, it should look something like this. An ordinary application is similar to a single-family home. The whole infrastructure, including walls, roofs, water supplies, heating, and others, serves just one family. A multitenancy application is similar to an apartment house, where the building infrastructure is available to all families occupying the building.
Is the multitenancy approach a good or a bad thing? Opinions vary. We assume that in the real world, there is no ultimate good or bad thing. You need to consider the pros and cons in the context of particular tasks. We'll skip it for now.
The most apparent benefit of multitenancy is to reduce application maintenance costs by sharing them among tenants. The approach to lowering customer price is similar to offering an off-the-shelf product instead of developing custom solutions. But the difference is that with an off-the-shelf product, they split the cost of development, while with multitenancy, the split goes into the use of the software.
The architecture does not limit how a piece of software can be used. Multitenancy is equally good as part of the SaaS sales model and as a solution for a corporate or agency IT infrastructure to automate a large number of similar affiliates or sites within an organization.
In other words, multitenancy is not just an approach to data storage. This is about how an application works in general, including most of the architecture-related aspects, deployment model, and approach to support.
In our opinion, the most complicated but still fascinating thing in multitenancy is that an application gets, so to say, double personality. Some functionality deals with specific data areas (apartments) and has no interest in residents of other apartments. While the other part of the application treats the house as a whole and works for all residents together. At that, the latter cannot but remember that apartments are separated and require a certain level of isolation and safety.
Multitenancy in 1C:Enterprise
1C:Enterprise implements multitenancy model through several technologies. These include 1С Enterprise platform mechanisms, 1сFresh development and publishing technologies, and 1C:Subsystems Library.
Every element mentioned above contributes to the joint infrastructure of the apartment house. Why use several technologies and not just combine everything in a single solution, say, the platform? The reason is that some mechanisms are better to be modified during the deployment stage based on the particular project requirements. Clearly, this is a complicated task. Every time we have to decide on a better way to implement one or another aspect of multitenancy.
It is no doubt that the primary mechanisms to enable multitenancy (like the data separation mechanism) must be implemented in the platform. This is what you actually start with. But in fact, the multitenancy model creates a significant impact on many platform mechanisms, causing their modification or even redesign.
The mechanisms we have implemented on the platform level provide basic functionality that makes multitenant applications possible. However, to run and maintain such applications, you need appropriate management tools. We achieve this with 1cFresh technologies and the unified business-logic layer in the 1C:Subsystems Library. Like an apartment house infrastructure provides for tenants' needs, 1cFresh technologies offer the necessary support for multitenant applications. In order for applications to be immediately capable of interacting with the infrastructure, we have added a kind of "sockets" that are standard subsystems within the Standard Subsystems Library.
As we gain more experience and feedback on 1C:Enterprise cloud solutions, we keep developing it by expanding the list of mechanisms involved in the multitenancy architecture. Here is an example. With the multitenancy model, there is a significant change in the roles of personnel involved in support. The helpdesk role with their level of responsibility gets higher, and they simply cannot go on without more powerful management tools. This is because application users (tenants) heavily rely on providers they work with. To meet these needs, we have implemented in 1C:Enterprise 8.3 a new security profiles feature. It enables service administrators to limit developers by applying certain levels of security. In other words, a provider can prevent tenants from leaving their sandboxes.
The architecture built for managing multitenant applications is of interest as well. And here we mean 1cFresh technologies and 1C:Subsystems Library. The automation requirements for administrative processes tend to be much higher as compared to the regular deployment model. There are dozens of such processes: creating data areas ("apartments"), updating applications and regulatory data, backups, and others. Of course, this sets higher requirements for service availability and reliability. Thus, we implemented the guaranteed asynchronous messaging technology to ensure failsafe interaction between applications and management system components.
Though it might look simple at first glance, data and process sharing can be tricky. The greatest difficulty is to find the right balance between centralization and decentralization of data and processes. On the one hand, centralization reduces costs (in terms of disk space, CPU resources, administrator efforts, and so on...). On the other hand, it restricts tenants' freedom. This is where we can face the double personality mentioned before: developers must simultaneously treat applications both in a narrow sense (a service for a single "apartment") and in a broad sense (a service for all the tenants).
A good example of such a dilemma for developers is how to present regulatory and reference information. Granting shared access to all "tenants" seems the most obvious here. A single copy means it is easy to store and update information. However, a tenant might want to have some pieces of these data modified. I imagine how strange it seems, but in real life, such a requirement can even refer to data provided by state authorities. And the question here is if we should use a single resource or several ones? It is tempting to have both a common-use database and a dedicated one with limited access. However, the implementation here becomes really complex. Well, we are still working on the proper solution.
Another example features the design of regular processes. This includes scheduled processes, processes initiated by the master system, and others. On the one hand, we can design such a process for each matter specifically. It is easy and convenient. On the other hand, such a level of granularity creates a massive load on the system. The way to reduce the load is to implement shared processes. Though this still requires a thorough study.
There comes a natural question. What should developers do to add multitenancy support into their applications? We work hard to place the burden of technology and infrastructure issues on our solutions so that developers can focus on business logic. Though, as with other critical architecture-related matters, developers need at least a basic understanding of the relevant model and take some effort to design multitenant applications. Why? Because in some cases our technology is unable to automatically process items until relevant semantics data is provided. For example, the system will need it to decide how a piece of information should be shared. Still, we work hard to simplify the handling of such tasks. And some applications that enjoy the benefit of such efforts have already entered the market.
It is important to note that within 1C:Enterprise we provide a hybrid model where a single application can be both an ordinary and multitenant one. Still, this is a challenging task that is well worth a separate article.
