How do I build scalable and usable cloud computing multi-tenant architectures?

Cloud computing multi-tenant is used for almost all software as a service (Software as a Service,saas) application because computing resources are scalable and the allocation of these resources is determined by actual usage. That said, users can access multiple types of SaaS applications over the Internet, from small internet-based widgets to large enterprise software applications. Security requirements are growing, depending on the data on the infrastructure of software vendors that are stored outside the corporate network. There are many reasons why applications require multiple tenants, the most obvious of which is cost: In most cases, it is not enough to add several servers and a database for each customer, although it is useful to do so with a high security requirement.

This article is an overview article that investigates and describes the types of available multi-tenant and provides implementation use cases.

Multi-Tenant concept

The concept of multi-tenant includes three-tier user integration:

Data center Layer

Infrastructure Layer

Application Layer

An important aspect of cloud computing technology design is multi-tenant infrastructure and application layer integration. This integration has been specifically tuned to cost savings and to develop highly scalable SaaS applications at the expense of security and customer isolation requirements (segregation requirement). In many cases, such designs are effective, although they may not be appropriate for financial applications.

Renting space in a data center and providing servers, routers, and cables to support multiple client software has been in place since the early days of Silicon Valley, so users should be familiar with the data center tier of tenants. If this configuration is implemented correctly, this configuration provides the highest level of security requirements, it uses firewalls and access control to meet business requirements, and also defines security controls for the physical location of the infrastructure that provides the sass. In most cases, you can use a data center layer tenant as a service provider, providing a site for the company to place hardware, network, and software.

Multi-tenant of the infrastructure layer is the simplest software stack concept, a stack dedicated to a specific customer. This configuration is more cost effective than the data center layer tenant because the stack is deployed based on the actual customer account. In this case, you can use the actual service to increase the hardware requirements. In addition, each user of the infrastructure layer can choose high availability. Every customer knows the stack, so software and hardware best practices provide some implementation options.

The application-tier multi-tenant needs to be architected on a software-tier and infrastructure-level basis. The existing software architecture needs to be modified, including the multi-tenant mode of the application layer. For example, multi-tenant applications require some application methods and data tables to access and store data for different user accounts, which at the expense of security. But if you do this correctly, you can save costs. For widgets and simple Web applications, the application layer multi-tenant is a viable solution because a single developer can develop software faster and also afford to scale. The disadvantage lies in more complex application architectures and implementations; Unlike infrastructure-handling multi-tenant, the application team needs to maintain the scalability and reliability of the programming model and be available in the future if the infrastructure changes.

Service

The Multi-Tenant service specifies access from HTTP restful interfaces or WSDL Web service terminals that are built and accessed directly from the software application. These services are the key to building a multi-tenant-oriented application for services, because they can be used for multiple transaction types. For example, a customer of a multi-tenant application layer service can invoke a service by invoking a URL, and its return result produces XML as the response code:

The following is a reference fragment:


Https://visa.com/services/paymentOverview?account=OnlineShoesInc&pass=1234&range=1_month


<response >


< >


<title >online Shoes Inc report</title>


<Data><x>01/01/2011</x><y>20.11</y></Data>


<Data><x>02/01/2011</x><y>22.24</y></Data>


<Data><x>03/01/2011</x><y>20.21</y></Data>


</Report>


</Response>

The most critical part of a multi-tenant is to set account parameters in the URL so that the infrastructure knows which customer is requesting access to the data. This is a multi-tenant routing mechanism for the service layer.

Application Server

Application servers are a critical part of many tenants in the application and infrastructure tiers, because multiple tenants affect installation, configuration, and application code. For the infrastructure layer, the multi-tenant of the application server means a faster and broader adjustment, with additional servers configured, including application server installation, configuration, and application code. The multi-tenant layer does not need to change the code (unless the application sets a particular requirement), and the adjustment is simple, typically done by the IT operations organization, rather than by the developer redesigning the application source code. Typically, if you add new customers, you need to add a stack of the same configuration to meet security requirements more easily.

Take a stack for example, assuming that the stack has a pre-configured Web layer (HTTP server), Application layer (application server), and database tier (database server) that can be deployed either to physical hardware or to virtual instances of the operating system. This is a typical way to plan for web-based application growth, because the user needs for the application may be today's high and tomorrow's low. You can lower these instances when the capacity is small, and then add the instances as needed. During the preventive maintenance of the infrastructure, from increased requirements collection to running actual customer transactions, adjustments are almost immediately completed in most cases, as these stacks are preconfigured and automatically deployed.

At the application level, multiple tenants of the application server need to change the application code because multiple customers share the same application server. Response times are affected whether a user runs a transaction or 1000 transactions at a time, because other customers are not only running on the same server hardware, but also in the same logical system memory. Depending on your application, there may be additional security requirements.

Affairs

Multi-Tenant infrastructure and applications need transactions to authenticate each customer's request. This process helps verify and authorize the types of transaction resources that users can access.

Extracting authentication and authorization services from the application layer helps improve scalability, maintainability, and reusability of multi-tenant transactions. Most application services added to the infrastructure require authorization, while stand-alone subnets, cloud, or application server clusters dedicated to authorization can meet scalability, maintainability, and reusability requirements. The same is true for licensing services, because this schema can be reused and adjusted based on transaction growth in the cloud or subnet.

Database

As the core part of many applications, databases are critical to the scalability of multi-tenant. Because a scalable database requires further planning for the infrastructure and application tiers, you need to understand the requirements of the application and best practices for scalable database infrastructures. If the infrastructure has a separate database for each customer account, scalability is simple because there is already a best practice for failover to a single database. Cost is also to be considered, since most commercial databases have to be authorized each time they increase their customer accounts, so the cost increases exponentially.

If the multi-tenant architecture is an application-tier implementation, you must be knowledgeable about the application before you can plan your database. The database schema applied to the Multi-Tenant schema may be different, so you must plan accordingly. A common application design method for saving costs and resizing on a single license is to place the customer account in the table name, for example, Customer123_payment, where the customer123 is the unique identifier for the user account. This design greatly increases the number of tables when you add a database instance to each customer, or when you create a data column in each table to verify that the customer accesses the appropriate data.

Building a multi-tenant service

Requirements for building a multi-tenant service include:

Defines a service based on RESTFU or WSDL.

Define response time and performance objectives.

Identify scalability and high availability requirements.

Define the services that are required for each transaction.

Determine the amount of service load based on the transaction customer.

Create a deployment and network topology for the service.

Create deployment Automation scripts to implement configuration and installation.

Create a unified Modeling Language (UML) sequence diagram for implementation development.

(Responsible editor: Lu Guang)