Exploration of multi tenant in jnpf cloud platform


Exploration of multi tenant in jnpf cloud platform

In the field of cloud, we often hear a word:multi-tenancy 。 This word has different meanings in different contexts. This paper will introduce the concept of multi tenant in cloud platform and the idea of multi tenant support.

What is a tenant

When you first get to know this concept, you must feel that the word “tenant” is strange. But if we change the word, I believe you will feel it immediately. This word is “customer” (here the customer refers to the customer above the business).

A tenant is a customer. For example, if the service we develop is for XXX enterprise, that enterprise is our customer / tenant; assuming that the service is internet-oriented, every Internet user using the service is a customer / tenant.

Why do we need multi tenant support

Developers work hard to develop a service. Is it done for individuals / businesses? Of course, it shouldn’t be just that. We developed a service. It is better to provide it to multiple individuals / enterprises at the same time. Moreover, it is better for these customers to share the same set of service runtime, which can greatly reduce the operation and maintenance cost of the service

  • Assuming that services are executed separately, the cost of operation and maintenance is directly proportional to the number of customers (for example, the scenario of updating and deploying a large number of customers)
  • Save resources (maximize the use of resources required for services: unified operation and maintenance team, hardware use)

In addition, it can also reduce the development cost of services

  • We only need to consider how to implement the service logic of single user: the business logic is corresponding to the same customers, and the services provided by the program are the same no matter what customers use it. Furthermore, at the business level, when we develop this service, we don’t need to consider multi customer support in theory. We only use the business logic of the service to realize it
  • Multi customer management functions can be unified: developers should not consider customer management functions, which should be provided by the cloud platform

Multi tenant scenario example

If the service we want to develop is a blog platform, this service is for Internet users, and every Internet user is our customer (a user is a tenant).

In an environment that does not support multi tenant, in order to isolate the data of each user, at least we will consider that most tables have a user when designing database tables_ ID field. Use this field for user isolation when used with crud data.

For example, today’s business is “publishing articles.”. We need to save the article data in the article table. In practice, we focus on two things:

  1. Crud: This is part of the business logic implementation
  2. User isolation: need to increase user_ id。 Do business connection

1 is the implementation of “pure” business logic. This must be achieved;

2 is for the multi-user blog platform and need to be considered, this is not the business logic of the blog platform itself.

If we can get the multi tenant support of the platform, we don’t need to consider the second point. This will focus on the first point of business logic implementation, which is a typical multi tenant scenario.

Multi tenant support

We can understand multi tenant support as follows:

  • From the perspective of service provision. A service we developed can be provided to multiple customers at the same time. And the data / state between customers remains isolated
  • From the perspective of service usage, you and I can use the same executed service as different customers at the same time. At this time, the business completed by using the service will not affect each other, just as we are using our own exclusive service

Then the service supports multiple “customers”, that is, the service supports multi tenant. The “service” here can be an application, a SaaS platform, or a PAAS platform. Just according to the cloud platform we are familiar with now, multi tenant support for applications should be the most conventional. This is because the application is oriented to users, and this group is very large.

Multi tenant support from an implementation perspective. “It is a software architecture technology”. The reason why we emphasize that it belongs to the architecture level is that to realize it, we must take it into account when we do the technical architecture.

A tenant model

At the beginning of this article, we mentioned using “customer” to replace “tenant” to understand the meaning of tenant. From the perspective of “business”, it is not difficult to find that tenants are actually part of the business model implementation in their cloud environment. Business models are diverse. This means that the division of tenants is also diverse. Here we describe one of the possible tenant stacks:

  • Applications are provided to users. For applications, users are their tenants (this is more uniform in the industry)
  • SaaS provides services for application developers. For SaaS, application developers are its tenants
  • The services provided by PAAS are used by application system, for PAAS. The combination of related applications is its tenant

SaaS and PAAS are oriented to developers, systems and other non-end user roles. This part is usually decided by cloud platform developers (bundled business model). In particular, private / enterprise cloud platforms generally do not consider scenarios such as “supporting the execution of multiple SaaS platforms on PAAS platforms”. So a lot of the rest of the discussion follows around “application to multi tenant support.”.

Multi tenant application

Application multi tenant usage scenarios have been described earlier. In order to support the following cloud platforms, we need to support several cloud platforms:

  • Tenant management: crud, statistics
  • Tenant isolated / shared services: queue, cache, database, etc
  • Statistics of tenant isolation: log, quota

These support can be divided into two categories:

  1. Tenant management: it will not directly face the end users of the application. It is oriented to the operation and maintenance of applications. The platform should provide detailed implementation
  2. Isolation of tenant data / state: from the beginning of the request, it should be able to distinguish which tenant the request comes from. When processing the request, the tenant context should also be brought on the call link. Data access is segregated by tenant. The service provided by the platform is also isolated by the tenant

The first point is to compare the easy implementation. This is a problem of business model, which can abstract tenant model according to business domain. For example, enterprise application usually distinguishes tenants according to “organization”;

The second point is a pure technology requirement. It is necessary to support isolation by “tenant” in the platform technology implementation. What we emphasize is isolation. Because the goal we want to achieve in the implementation is isolation. It is only by tenant here (tenant is just a business concept, and we’d better abstract it at the technical level). Minimize the impact of business model diversification on technical architecture). We can map tenants to an abstract concept that can implement our isolation requirements.


The previous discussion on multi tenant support is from top to bottom: from application multi tenant requirements to data isolation implementation; now we can change our perspective from bottom to top: first isolate data through the namespace, and then provide the namespace to the implementation of application multi tenant. The bottom-up goal is mainly within the platform. We can abstract data / state isolation through “namespace”. Finally, the ideal scenario is that the namespace can not only support application multi tenant implementations, but also selectively expose the namespace APIs. Allow applications to isolate certain data (such as caching). Convenient for business implementation.

Implementation of isolation

From the beginning to the end of a tenant request, the platform needs to know the namespace of the request mapping. From the request processing stack, we can roughly divide it as follows:

  • Load equalizer (LB)
  • Application container (APP)
  • Platform service interface (RPC)
  • Platform service implementation (dB / cache / MQ…)

In this stack, each platform needs to know the corresponding namespace of the request. The platform can provide a unified login service to map the tenant information into a namespace and save it to the user session. In this way, every time the user requests:

  • When passing through lb, the namespace can be distinguished
  • In the app container, the
  • Passing a namespace when RPC
  • Implement the namespace according to different services (for example, DB uses different schema based on the namespace, MQ uses different queues according to the namespace)

Here we use the basic idea of isolation implementation is “shared application”, that is, multi tenant sharing an application, corresponding to a set of infrastructure.

A platform design

Having talked so much, we can now come up with a cloud platform that supports multi tenant applications

Exploration of multi tenant in jnpf cloud platform

(the design ideas here also include scenarios where some tenants require exclusive resources.)


  • The concept of tenants and customers is similar
  • For multi tenant support, we generally refer to the application support for multi tenant
  • Data / state isolation is needed to support multi tenant technology
  • Using the namespace for isolation to achieve abstraction
  • Tenant to namespace mapping can be integrated by the platform