by IBM Developer Staff | Updated July 4, 2011 - Published July 5, 2011
Cloud computing multi-tenancy is used for most if not all Software as a Service (SaaS) applications, because compute resources are scalable and allocation of these resources is defined by actual usage. Having said that, there are multiple types of SaaS applications that users can access through the Internet, from small Internet-based widgets to large enterprise software applications that have increased security requirements based on the type of data being stored on the software vendor’s infrastructure outside the corporate network. These application requests require multi-tenancy for many reasons, the most obvious of which is cost: Adding a single stack of application servers and a database for each customer would not be sufficient in most cases, although it makes sense when there are higher security requirements.
This overview investigates and describes the types of multi-tenancy available and provides implementation use cases.
The concepts of multi-tenancy include three levels of consumer integration:
The latest additions to cloud computing topology design are infrastructure and application-layer customer integration for multi-tenancy. This integration is specifically geared toward cost savings and developing highly scalable SaaS applications, accomplished by compromising on security and customer segregation requirements. Such designs are useful in many situations, although they may not be suitable for financial applications.
Renting space in a data center and supplying servers, routers, and cables that support multiple customer software requests have been around since Silicon Valley was in its infancy, so data-center-layer multi-tenancy is well known. This configuration provides the highest level of security requirements, if implemented correctly, with firewalls and access controls to meet business requirements and defined security access to the physical location of the infrastructure that provides the SaaS. In most cases, data-center-layer multi-tenancy is a service provider that rents cages to companies that host their hardware, network, and software in the same building.
Multi-tenancy at the infrastructure layer is commonly thought of in software stacks, where one stack is dedicated to a specific customer. This configuration saves costs compared to data-center-layer multi-tenancy, because stacks are deployed based on actual customer accounts. In this case, you can grow hardware requirements based on actual service use. In addition, high-availability may be an option for each customer at the infrastructure layer. Because the stack is known for each consumer, software, and hardware best practices provide options for implementation.
Application-layer multi-tenancy requires architectural implementations at both the software layer and the infrastructure layer. Modifications are required for the existing software architecture, including multi-tenant patterns in the application layer. For example, multi-tenant applications require both application methods and database tables to access and store data from different user accounts, which compromises on security. If done accurately, however, the benefit is cost savings. For widgets and simple web applications, application-layer multi-tenancy can be a solution, because one developer can create software faster and scale more affordably. Disadvantages include more complex application architecture and implementation. Rather than the infrastructure dealing with multi-tenancy, the application teams and architects need to keep these programming patterns scalable, reliable, and future-proof in case the infrastructure architecture changes.
Multi-tenant services specify access through HTTP Representational State Transfer (REST)ful interfaces or WSDL web service endpoints constructed into software applications and accessed directly. These services are critical to building service-oriented applications for multi-tenant patterns, because they can be reused for many transaction types. For example, the consumer of a multi-tenant application-layer service can call the servers by invoking a URL that in return produces XML as the response code:
< Report >
<Title >Online Shoes Inc Report</Title>
The most critical part for multi-tenancy is that the account is specified in the URL as a parameter so that the infrastructure is aware which customer is requesting access to its data. This is the routing mechanism for multi-tenancy at the service level.
The application server is a critical component in multi-tenancy at the application and infrastructure layer, because multi-tenancy affects installation, configuration, and application code. For the infrastructure layer, multi-tenancy for application servers means scaling fast and wide, with additional servers provisioned with an application server installation and configuration and application code. This layer of multi-tenancy does not require code changes unless specific requirements are set with the application. Therefore, scaling is simple and done mostly by the IT operations organizations rather than developers re-engineering application source code. Typically, if new customers are added, you can add a stack with the same configuration, meeting security requirements more easily.
One example is a stack that has the web layer (HTTP server), application layer (application server), and database layer (database server) preconfigured for deployment to either physical hardware or virtualized instances of operation systems. This approach is a typical way to plan for growth for web-based applications, because demand can be high one day and low another. These instances can be scaled back during low-volume periods and scaled up as needed. The turnaround for these infrastructures, from growth requirements-gathering to running real customer transactions, is in most cases immediate, because stacks are preconfigured and automated for deployment.
At the application layer, multi-tenancy for application servers requires application code changes, because multiple customers are sharing the same application server. Response times may be affected regardless of whether the customer is running one transaction or a thousand at the same time, because other customers are running not only on the same server hardware but also within the same logical system memory. Depending on the application, there can be additional security requirements.
Multi-tenant infrastructures and applications require transactions to authenticate each customer on submission of a request. This process helps authenticate and authorize the types of transaction resources a user can access.
The extraction of authentication and authorization services out of the application layer can help with scalability, maintainability, and re-usability for multi-tenant transactions. Most application services added to infrastructures require authorization. A segregated subnet, cloud, or cluster of application servers specifically for authentication meets the requirement for scalability, maintainability, and re-usability. The same goes for authorization services, because this architecture can be reused and scaled within a cloud or subnet based on transaction growth.
As the core component of most applications, the database is critical for multi-tenancy in terms of scalability. Because scalability databases require extended planning for the infrastructure and application layers, you need to understand the requirements of the application as well as best practices for scalable database infrastructures. If the infrastructure stack requires a single database for each customer account, scalability is straightforward, as these best practices have been established for single databases with failover. Also consider cost, because most commercial databases may have exponential license cost associated with adding to a per-account model.
If the multi-tenancy architecture is an application-layer implementation, you must understand the application well enough for database planning. Specific database schemata patterns apply to multi-tenant architectures, and these must be planned for accordingly. One common application design approach for saving cost and scaling on single licenses is to have the customer account name in the table name—for example, customer123_payment, where customer123 is a unique identifier for the user account. This design increases the number of tables significantly over adding a database instance per customer or creating a column in each table to validate whether the customer is accessing the proper data.
Consider the following rrequirements for building multi-tenant services:
The network topology shown in Figure 1 describes how services are deployed and accessed through the network using cloud-scalable resources. Other services can be added to the application layer where the servers are running as necessary. In Figure 1, Cluster A and Cluster B are exactly the same and distributed across two data centers or cloud providers. Each cluster has the same services deployed across all nodes for high availability and scalability.
The deployment topology is required to identify the resources services required for the hardware and operating systems. Because each service will likely require JDBC, reference libraries, systems users, and messaging functionality, you add these requirements to the deployment topology. Cloud infrastructures can become large, so it’s best to prepare in advance. For example, if a service calls to a specific data source or database, add that source to the deployment topology as shown in Figure 2. In this figure, cloud_server1 is the data source defined in the sample deployment topology.
Multiple customers accessing the same hardware, application servers, and databases might affect response times and performance for other customers. For application-layer multi-tenancy specifically, resources are shared at each infrastructure layer and have valid security and performance concerns that you must plan for. For example, multiple service requests accessing resources at the same time increase wait times but not necessarily CPU time. Thenumber of connections to an HTTP server might be exhausted, and the service must wait until it can use an available connection or—in a worst-case scenario—drops the service request.
Consider the following requirements for building multi-tenant application servers:
Similar to the network topology for services, the network topology for multi-tenant application servers describes how application servers are shared across transaction consumers. In this example, you scale by adding a transaction path and cluster. All transactions, regardless of the consumer, are distributed across clusters A, B, and C.
Because most application server deployments for enterprise infrastructures require complex installations and configurations, automation of this process is paramount. Scalability and newer on-boarding depends on provisioning application server resources and the guaranteed replication of infrastructure stacks and application-layer infrastructure. For example, operating system scripts for the automated installation of application servers are required to shorten the mean time to deployment for new accounts and services being added to the infrastructure.
These application server configurations can be extremely complex. In most cases they align with development-created resources, for example, database connection source names and other Java™ Naming and Directory Interface (JNDI) resource names. If the resources that developers are required to subscribe to are defined in advance, the automation is simplified for scalability.
Consider the following requirements for building multi-tenant transactions:
Similar to application server multi-tenancy, transaction multi-tenancy can be configured and programmed to leverage a nonsegregated or segregated approach. As shown in Figure 3, the clusters A, B, and C can be configured to process transactions per customer and customers if the right load-balancing infrastructure is in place. Also, there is a requirement to write application code to process all transactions, if necessary, for multi-tenancy. For example, cluster A could be configured to process one customer, and clusters B and C could be configured in a similar fashion or programmed to process multiple customers based on planning configurations. The configurations could also depend on service levels defined in the service agreements.
Because the customers are sending transactions that consist of multiple services to create the end-to-end transaction, there are a few challenges. If these transactions and individual services are not sized appropriately, it might affect performance and response times for all transactions. For example, consider transactions that use fraud services and transactions that do not: Without the right sizing, it’s difficult to determine in advance whether load requirements are met. The exponential use of the authentication service is problematic, particularly if used multiple times per transaction. A cap on service use per transaction ensures the ability to size appropriately and provides a measure to reuse for capacity planning.
Consider the following requirements for building a multi-tenant database:
The multi-tenant database delivers new types of challenges at the application layer by adding many tables per customer to scale based on single-database licenses. The number of tables increases, affecting the disk space use that is assigned to a specific table, also known as table space. Because customers use different and unexpected amounts of data, table space sizes can vary significantly, affecting database sizing and planning considerations.
Keep in mind that auto-sizing options are available for database table spaces and detailed monitoring configurations that notify you if specific table spaces are full and need resizing. To prevent these problems, size based on the average amount of data you expect a user to store, then add a buffer to ensure that in exceptional cases transactions and services can still be processed until table spaces have been modified to support customer-specific growth.
For the small start up or a single developer creating applications quickly at an affordable price and creating proofs of concept and widgets for web applications, cloud computing multi-tenancy is appropriate and cannot be avoided going forward. Scalability and time to market are often at an even higher priority for widget and web application consumers. For example, applications for mobile or personal use and even small business applications with fewer security requirements are used based on innovation, response time, and ease of use rather than security and high availability.
In the case of enterprise applications, additional measures must be taken to ensure that security and high availability are addressed and implemented. All of these measures affect time to market and innovation. In the end, if cloud computing multi-tenancy applications are more secure and have improved response times, the organizations can deliver enterprise solutions that meet larger organizational requirements. For example, if you implement the approaches described in this article, create multi-tenancy, and integrate it into an enterprise organization, segregation is required. You must resolve security concerns for the availability of each type of service to prevent denial of service issues and service-specific requirements. Using a multi-tenancy approach prevents services from falling between the cracks for future end-to-end transactions that were not planned for.
Back to top