Multi-tenancy of cloud Platform

Multi-tenancy of cloud Platform

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

what is a tenant

When you first get into this concept, you must feel that the word "tenant" is strange, but if we change the word, I believe you feel it right away, the word "customer" (the client here refers to a commercial customer). A tenant is a customer, for example, we develop the service is for the XXX enterprise use, that the enterprise is one of our customers/tenants; If the service is Internet-facing, every Internet user using the service is a customer/tenant.

why multi-tenant support is required

Developers have worked hard to develop a service that is available to individuals/businesses, so is it done? Of course, we should not just do this, we develop a service that is best able to be available to multiple individuals/businesses at the same time , and these customers are better off sharing the same set of service runtime (runtime), which can significantly reduce the operational costs of the service:

• If the service runs separately, the cost of operations is proportional to the number of customers (such as the scenario of updating a large number of customers)
• Save Resources (Maximize Service resource utilization: Unified operations team, hardware use)

In addition, this can also reduce the development cost of services:

• We only need to consider how to implement the single-User Service logic: The business logic is the same for all of its customers, no matter what customers are using, the services provided by the program are the same. Further, we do not need to consider multi-customer support when we develop this service at the operational level, we only use the business logic that focuses on the service to achieve
• Multi-client management capabilities can be unified: developers should not consider the customer management function, which should be provided by the Cloud Platform unified

examples of multi-tenancy scenarios

Suppose we want to develop a service that is a blogging platform that is intended for Internet users, and each Internet user is our customer (a user is a tenant).

In an environment that does not support multi-tenancy, in order to isolate each user's data, at least we will consider the existence of a user_id field in most tables when designing a database table, which is used for user isolation when using CRUD data.

For example, the current business is "Publish article", need to save the article data in the article table, in reality, when implemented we focus on two things:

1. CRUD: This is part of the business logic implementation
2. User isolation: Need to join user_id to do business correlation

1 is the "pure" business logic part of the implementation, which must be achieved, 2 is for the multi-user blog platform to consider, this is not the business logic of the blog platform itself. If you can get multi-tenant support for the platform, you don't have to think about the 2nd, so you can focus on the 1th business logic implementation, which is a very typical multi-tenancy scenario.

Multi-tenancy support

We can understand multi-tenancy support in this way:

• From a service offering standpoint, one of the services that we develop can be provided to multiple customers at the same time, and the data/status between customers is kept isolated
• From the point of view of service usage, I and you can use the same running service as different customers at the same time, the business we use the service to do is not affect each other, as if we are using our own exclusive service

Then this service is supported by multiple "customers", that is, the service supports multi-tenancy. The "service" here can be an application, either a SaaS platform or a PaaS platform. However, as we are familiar with the cloud platform, the application of multi-tenant support should be the most conventional, because the application is targeted to the user, this group is very large.

Multi-tenancy support from the perspective of implementation, "is a software architecture technology", the reason is to emphasize that it is at the architectural level because to achieve it must be in the technical framework to be taken into account.

a tenant model

At the beginning of this article we mentioned the use of "customer" to replace "tenants" to understand the meaning of tenants, and from the "business" aspect, we can not find that tenants are actually part of the business model implementation in their cloud environment. The business model is diverse, which means tenants are divided into a variety of types, and here we describe one of the possible tenants stacks:

• The application is provided to the user, and for the application, the user is its tenant (the industry is more unified)
• SaaS provides services for application developers, and for SaaS, the application developer is its tenant
• PAAs provides services that are used by applications, and for PAAs, the combination of applications is its tenant

SaaS and PaaS are for developers, systems and other non-end user roles, which is generally determined by the cloud Platform developers (bundled business model), especially the private/enterprise cloud Platform is generally not considered as "support running multiple SaaS platform on the PaaS platform" scenario. So here's what we're talking about in "app-to-multitenant support."

apply multi-tenancy

The use of multi-tenancy has been described earlier, and now suppose we are a cloud platform developer, in order to meet the needs of supporting multi-tenant support applications, we need to provide the following support in the cloud Platform:

• Tenant Management: CRUD, statistics
• Tenant-Isolated/shared services: Queues, caches, databases, etc.
• Statistics for tenant Isolation: logs, quotas

These support can be divided into two categories:

1. Tenant management: Not directly facing the application of the end user, oriented to the operation of the application, the platform should provide concrete implementation
2. Tenant Data/State isolation: From the start of the request, you should be able to distinguish which tenant the request is from, when the request is processed, the tenant context is also required on the call link, and the data is accessed in isolation from the tenant, which is also tenant-isolated when invoking the service provided by the platform.

The 1th is easier to implement, which is a business model problem, can be based on the business domain to abstract tenant model, such as enterprise applications generally according to "Organizational structure" to differentiate tenants;

The 2nd is a purely technical demand, need to support the implementation of the platform in the "tenant" run-time isolation , we emphasize the isolation, because in the implementation of our goal is to achieve isolation, but here is the tenant (tenant is just a business concept, At the technical level we'd better be able to abstract it to minimize the impact of the diversification of the business model on the technology architecture, and we can map the tenant to an abstract concept that can implement our isolation requirements.

name Space

Before we discussed multi-tenant support is top-down: From the application of multi-tenant requirements to data isolation implementation; Now let's take another look at the bottom-up: First isolate the data through the namespace, and then make the namespace available to the application multi-tenant implementation. The bottom-up goal is primarily within the platform, where we can abstract data/state isolation through "namespaces", and ultimately the ideal scenario is that namespaces not only support the application of multi-tenant implementations, but also selectively expose namespace APIs, allowing applications to isolate certain data (such as caching) facilitate business implementation.

implementation of Isolation

Tenant requests from start to end platform need to know the namespace of this request mapping, from the request processing stack we can roughly divide:

• Load Balancer (LB)
• App container (APP)
• Platform Service Interface (RPC)
• Platform Service implementation (DB/CACHE/MQ .... ）

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

• When you are over LB, you can distinguish the namespaces
• In the APP container, you can use the session
• Passing namespaces when RPC is in place
• Namespaces are implemented according to the different services (for example, DB uses different schema,mq according to the namespace using different queues depending on the namespace)

The basic idea of the isolation implementation we use here is "shared application", where multiple tenants share an application and a set of infrastructure (see: Converting a single-tenant application to a multitenant application).

A platform design

Having talked so much earlier, we can now think of a cloud platform that supports the application of multi-tenancy:

(The design idea here also includes a scenario where tenants require exclusive resources.)

Summary

• The concept of tenants and customers is similar
• Support for multi-tenancy we generally refer to the application's support for multi-tenancy
• Support for multi-tenancy at the technical level requires data/state isolation
• Using namespaces for isolation implementation abstraction
• Tenant-to-namespace mapping can be integrated by the platform

Multi-tenancy of cloud Platform