Transform your Web application into a multi-tenant SaaS Solution

Transform your Web application into a multi-tenant SaaS Solution https://www.ibm.com/developerworks/cn/cloud/library/cl-multitenantsaas/index.html

Imagine that you have a Web application that has been sold on the market. You know that software as a service (SaaS) in the cloud infrastructure is the future of the industry. You realize you need it, and your customers are asking you to provide a SaaS version of the product.

The problem is that you need to quickly and efficiently convert to SaaS, and it's best to maintain or enhance your profitability.

There are many differences between SaaS applications and regular Web applications that need to be considered. Some technology-related, while others are related to changes in the business model, companies must be able to adapt to this change when delivering SaaS.

Typical Web applications and SaaS

The main feature that SaaS distinguishes from other applications is the ability to pay customers to use the application when they use it. They do not need to purchase licenses for the software, nor do they need to install, host, and manage it. All this is done by the organization that provides the SaaS software.

Multi-tenancy is the key to achieving a successful SaaS

Although the ability to subscribe to an application has minimally met the basic conditions of SaaS, it still does not meet the requirements in practice. In fact, the SaaS application must also be a multi-tenant application.

In the final analysis, it is related to economic factors. The CEOs of major SaaS companies agree that without multi-tenancy, it is impossible to develop a SaaS business. (see sidebar).

一致意见：SaaS 需要使用多租户多租户是 SaaS 供应商获得成功的关键因素。— Marc Benioff，Salesforce 的 CEO如果没有多租户的话，SaaS 不可能取得成功。— Treb Ryan，OpSource 的 CEO我们实现了超低的计算成本 ... 我们在 SaaS 行业内拥有最低的成本（这是使用多租户的结果）。— Lars Dalgaard，SuccessFactors 的 CEO如今，ASP 试图东山再起。然而，云数据中心方法仍然使用单租户模型来隔离用户，这意味着它的运营成本将很高，因此价格也会很贵— Zach Neson，NetSuite 的 CEO — 我们的毛利润超过 70%（因为使用了多租户）。多租户对于我们来说真的非常重要 ... 它实现了一个非常高效的模型 — Tim Wallace，iPipeline 的 CEO在 SaaS 这场竞赛中，多租户就是赢得这场胜利的筹码。— Henry Olson，Edge Dynamics 的前 CEO多租户为整个订阅模型提供支持...— Jeff Kaplan，THINKStrategies 的 CEO

Multi-tenancy reflects the efficiency level of SaaS

The main factor affecting efficiency comes from multi-tenancy, which is the ability to accommodate different users of the application, while the user feels that the application is fully serving them. We are used to this concept because it is applied to individual users in the system, but there are still some subtle differences with the SaaS environment. In a typical enterprise SaaS environment, a user is a group of employees of a particular organization that is called a tenant. This is similar to what you see in a normal Web application, if the organization buys the application, and the organization's employees are the users of the application, and that organization is the owner. In the SaaS model, the organization is a tenant, not an owner, but the employee of the organization is still the user's identity. Each user is specifically linked to a specific tenant (organization), and SaaS provides each tenant with a copy of the application for use by their users.

Virtualization in the cloud impacts SaaS

The difference between a simple Web application and a cloud-enabled SaaS application involves the two most significant capacity utilization features currently in the IT industry:

Multi-tenancy (previously introduced)
Hardware virtualization.
While the efficiency of an application depends primarily on the multitenant architecture of the application, the second factor that affects efficiency is hardware virtualization. By leveraging virtualization technology to reduce unused capacity generated when using a common data center physical machine approach, the cloud environment greatly improves the utilization of a given number of hardware.

In addition, the cloud provides the potential to dynamically reallocate hardware to applications based on resource requirements. In a short time (a few minutes) or in the long run (months), this flexibility helps separate hardware from a single application and then spreads them out into a large number of applications, eliminating differences and making hardware investments easier to predict and manage.

Now, let's take a look at what steps you typically need to take to convert a more traditional Web application into a SaaS-enabled application.
Converting a Web application to a SaaS application
To convert your Web application to a SaaS application, you need to meet the following 7 conditions:

Applications must support multi-tenancy
The application must have some level of self-service registration capability.
Must have a subscription/bookkeeping mechanism.
The application must be able to scale effectively.
You must be able to monitor, configure, and manage applications and tenants.
There must be a mechanism to support unique user identities and authentication.
There must be a mechanism to support some degree of customization for each tenant.
Let's look at each of these 7 conditions in detail.

Multi-tenancy support
Multi-tenancy is a key factor in determining SaaS efficiency. Typically, an application supports multiple users, but only if it believes that all users are from the same organization. This model is suitable for an era when SaaS is not present, and organizations purchase a software application for their own members to use. But in a world of SaaS and cloud, many organizations will use the same application, and they must be able to allow their own users to access the application, but the application must allow only the members of each organization to access their organization's data.

The ability to have multiple organizations (terms called Tenants in SaaS) coexist in the same application without disrupting the security of data for those organizations, which can be called multi-tenant applications.

Multi-tenancy can be divided into several different categories (as shown in the figure below the list):

Simple virtualization in the cloud, where only hardware is shared.
Share the application and use a different database for each tenant.
Share applications and databases (most efficient, real multi-tenancy).
Multi-tenancy model
Multi-tenancy model
It can be argued that the first model is not really a multi-tenancy at all, but in a cloud environment, it is often used in conjunction with virtualized servers and is considered a multi-tenant form. In practice, this model does not meet the requirements and is only slightly more useful than the older ASP models that use specialized hardware.

The most efficient model is for applications to fully share the business logic of databases and applications. Implementing this model is difficult because you need to modify the database schema, add a tenant identifier to each table and view, and override each SQL access to add tenant filters to the filter. If any necessary parts of the code are missing this logic, the data security of the application is compromised.

In addition to the data access instances that appear in the application, there are other applications, such as report writers and tool applications, that must be modified to include the necessary tenant filtering capabilities to ensure that the data for individual tenants is accessible only to those specific tenants. If the type of access does not come directly from the application itself, then there is a problem and this type of problem must be controlled. If any authorized user can write a report, they must be prevented from accessing data that is not part of the tenant to which they belong.

Self-Registration
An application must have some level of self-service registration, even if it is just a request mechanism, which produces a business process that adds a tenant to the application.

Subscription and Bookkeeping
Subscription and accounting mechanisms must be provided. Because SaaS applications are designed to pay based on a variety of factors, such as the number of users per tenant, application selection, and possibly usage time, there must be some way to track and manage the use of the application, and then generate accounting information that can be accessed by tenant managers.

Extending and managing applications
Must be able to scale as the subscription grows. The cloud infrastructure is a logical way to achieve this, because it embeds many features that enable you to achieve effective, efficient scaling.

Similarly, governance and application management capabilities must be provided to monitor, configure, and manage applications and all tenants.

User ID and authentication
You need to provide a mechanism to support user identity and authentication, allowing the user to have a unique identity. Because multi-tenancy requires identification of all users registered with the system to determine which tenant they belong to, there must be a clear relationship to identify the user as belonging to a particular tenant. This relationship between the user and the tenant is very important information that restricts the data that the user can access.

e-mail addresses are a typical way to achieve this by ensuring uniqueness and that each user can be identified and identified as belonging to a particular tenant.

There are multiple authentication mechanisms and integration methods, so there must be a flexible mechanism to identify users. Typically, a particular tenant needs to be able to leverage its existing LDAP or other directory services or authentication mechanisms to support single sign-on for SaaS applications. Although this external user authentication is important, it is up to the SaaS application to determine that the identified users belong to the tenants they claim to be members of.

Customize for each tenant
You must provide a mechanism to support a certain level of basic customization for each tenant, so that they have a unique URL, login page, identity, color scheme, font, and even language.

The basic configuration for each tenant is expected, but to truly meet the needs of multi-tenancy, you must achieve a certain level of customization for each tenant on a basic configuration basis.

The typical customizations required are similar to the customizations made by the tenant to the internal application version. This includes adding fields or even tables, setting up special business logic, or integrating another application. This type of customization can be done on a per-tenant basis without having to create a separate instance (otherwise reducing the efficiency of a multitenant design), which is a typical feature of a high-performance SaaS architecture.

Performance issues to consider
The performance issues for multi-tenant SaaS applications are typically the same as those encountered with Web applications that hold the same number of users and have the same level of activity. There are a number of good ways to address the growing capacity requirements of Web applications, and these methods are generally applicable to multi-tenant SaaS applications. These techniques typically include horizontal/vertical scaling and load balancing across a set of servers.

Horizontal/Vertical expansion
Cloud infrastructure provides many opportunities to achieve this scalability in a dynamic, automated way, providing resources when needed, and reducing resources accordingly, with fewer resources to meet performance service-level agreements (SLAs). This flexibility can be adjusted to allow for the provision of services while avoiding the waste of resources:

Scale-out is typically used for application server tiers.
Vertical scaling is typically used for database tiers.
Clustering of databases
For SaaS applications, the total number of users for a successful product can be very high, and in some cases it may not be a good way to scale a database vertically. Many database technologies provide a clustered database model that allows more capacity to be provided for the same database. DB2? Some of the options provided can be applied well to this model and can be used to create a DB cluster.

Geography, partitioning, and synchronization
However, depending on the SaaS application and its user base, some other technologies may be more appropriate. Because SaaS can be accessed from anywhere in the world, its user base may be located very far away, which can degrade performance due to a longer network topology.

For such cases, it may be better to use a cloud that is distributed across different regions, partition the data, or use synchronization to maintain consistency. Which method to choose depends on the nature of the specific application. Some users may not be able to accept long-distance synchronizations.

Stand-alone Database
Of course, the most fundamental approach, at least for SaaS applications, is to establish a separate database when the database capacity does not meet the requirements. Anyone who wants to get a multi-tenant SaaS application must take into account that this approach leads to less reliable solutions that require database support for each tenant, which leads directly to inefficiencies that are the problem that multi-tenancy is trying to avoid.

If you have to split the application server to serve only one database, the efficiency features of the multi-tenancy will be further impaired. In highly competitive markets, these high-efficiency features of multi-tenancy are critical to the success of SaaS companies.

Using load balancing in your design
One way to stay as efficient as possible in the case of having to use a stand-alone database (for whatever reason) is to use a special multitenant design that allows any application server in a load-balanced cluster to access the most appropriate database in multiple databases. In this way, the efficiency of a load-balanced cluster can be maintained, and all application servers can connect to any database to complete the user sessions they support. This allows for maximum efficiency under multiple database constraints.

Capacity is not the only requirement
In addition to meeting capacity requirements, the use of multiple databases is justified, such as requiring the use of encrypted databases for certain highly secure tenants. Capacity is not an issue, so it is important to adopt a design that maximizes efficiency, even if it requires a relatively inefficient model of its own.

Security issues to consider
A large number of surveys show that users of SaaS applications typically prioritize security, or at least very close to the first place. No SaaS provider can ignore security. However, the concept of data security is often confined within the context of the SaaS application itself.

Most SaaS application architectures take some measures to protect data security, which prevents one tenant from viewing another tenant's data as a basic requirement. But:

One of the capabilities that SaaS applications must have is to integrate and interact with other applications.
Some of these so-called other applications may be located outside the application (not controlled by the SaaS provider).
Not all SaaS applications are designed to be accessible to external applications.
These other applications can be internal applications that require access to or share data, or data mining for trending analysis or report authoring tools. Even the utilities that are used by the database administrator can cause security problems if they are accessible to tenants, or worse, by manipulating data that does not belong to them.

The best practice architecture for SaaS must take into account that not all data access is under the control of the application; There must be mechanisms to ensure that data protection is provided to each tenant, whether through SaaS applications or through some external applications.

Select the technology stack
Some tradeoffs are often required when choosing the technology stack, especially for SaaS applications, because decisions are made for all tenants. Let's look at some of the issues that need to be considered in this process.

Operating system considerations
The operating system in a Web application may be the most irrelevant to the user because the user interacts with the browser. However, some economic and technical factors may have some impact:

If you need to rely on specific code that relies on the operating system, you need to consider this constraint when making your choice.
If there is a general need to integrate external applications, and it is better to do this integration on one operating system than on another, consider the choice.
Given the economic benefits of the cloud, people tend to be prone to operating systems that perform well and have lower licensing fees. The main way to extend a Web application is scale-out, which means that as the SaaS application grows, the total number of Web application server instances will also increase, resulting in direct operational costs.

Database considerations
A database in a Web application may not be a critical consideration for end users because their interactions are done through a browser, and as long as the application is able to store and retrieve its data, the database does not have much to do with them.

Economic and technical factors once again have an impact on application developers. If your application needs to rely on some special features of the database, you will be constrained in making your choice.

Database selection is important for many design applications, and the special requirements for the SaaS environment can also affect the database selection.

In a SaaS application, the database is more demanding because of the number of end users, so the scalability of the database is very important. Database extensibility is typically implemented on a separate instance, while using increasingly powerful database servers to meet more demanding applications. But the scalability requirements of SaaS applications may exceed the limits of vertical scalability, so the next step in database extensibility is to take the clustering feature.

The ability to implement this clustering in a cloud environment can affect the choice of databases. For example, DB2 may be chosen because it can run on a wide range of operating systems, provide vertical scalability, and it has the flexibility to choose between multi-instance clustering and redundancy for scalability. For example, a DB2 HADR (High Availability disaster recovery) cluster can be established in the cloud.

Application Server Considerations
As with other technology stacks, choosing an application server is also a decision for SaaS application developers, because end-user interaction is done only through the browser. However, for many application design considerations, there are important differences in the choice of application servers, and the special requirements for the SaaS environment will also affect its choice.

Using special features or WebSphere? Applications such as application server plug-in (add-on) components will need to use this application server in the cloud.

The basic principles of choosing an application server are often made early in the application life cycle, because applications may benefit from certain features, or some third-party plug-ins or integration features are important to the application. In some cases, it may only be because the organization's know-how and internal standards require specific components to be used in the technology stack.

When selecting and configuring the technology stack for saas/cloud environments, decision points include balancing technical and economic forces to achieve a better result.

Flexibility is the key to technological evolution
In the SaaS architecture, the ability to make decisions and tradeoffs about the technology stack that will be used, and the ability to revisit these decisions at a later stage, is invaluable. As technology continues to evolve, leading cloud providers will incorporate new middleware applications and features, and the ability to adopt these applications and capabilities for your SaaS applications is also an advantage.

Forcing you to make a choice and lock you into a particular technology stack, this SaaS application architecture will be detrimental to the future evolution and adaptability of SaaS applications. The core concept of service-oriented architecture is well suited to providing the agility and flexibility required for SaaS applications. Reducing the degree of coupling will provide flexibility, and this flexibility makes it possible to achieve strategic and tactical evolution.

In the remainder of this article, we will use the Corent multi-tenant server (multi-tenant server?) to provide an example of how to take a Java with minimal steps? The Open source billing Web application translates to a multi-tenant SaaS application.

Auto-Convert to SaaS application using Corent's multi-tenant server
Cloud providers offer a wide range of features that can accommodate almost any Web application. To completely transform this application into a multi-tenant SaaS application, it is often necessary to make extensive modifications to the application code and redesign and configure the database.

Corent's multitenant server enables ISVs to adopt a different approach, using the middleware layer to provide key multi-tenancy features (thereby protecting investment in existing code). I'll describe how to convert a typical single-tenant application into a multi-tenant SaaS application in 4 steps. The application we are going to convert is jBilling, a popular open source Java Web application.

Step 1. Converting a database schema to an abstract model
The typical stack of Web applications is 1, and the application communicates with the database, usually through a data persistence layer such as Hibernate.

Figure 1. Typical Web application stacks in the cloud
Typical Web application stacks in the cloud
To convert an application to a multitenant application, you must redesign the database to add more fields to manage tenant identification data, which is needed when filtering data based on the tenant.

Saas-factory? The schema that the application uses to read the existing application database. It then creates a model for the database, which is later used to generate a new database in MySQL, which adds the TenantID field to the table. At this point, several additional tables for the Multitenant server, including the Tenant information table, are created.

Figure 2. Create Metamodel Database Schema
Create Metamodel Database Schema
Because the Metamodel database looks exactly the same as the original application, with the same tables and fields, the original application can continue to interact with the Metamodel database as if it had interacted with the previous MySQL database. The real database hidden under the model can be generated with the TenantID fields required by the multi-tenant application.

The Metamodel database is simply an abstraction and does not actually hold any data: it is just a model. Therefore, there is no reason why you cannot build in any supported relational database management system (RDBMS) when you build a real database. This abstraction can be useful when ISVs want to modify the technology stack by selecting different RDBMS (such as DB2) to take advantage of certain features or to achieve better performance for the application.

Step 2. Extending the user authentication process
Any multi-tenant SaaS application must be able to manage the necessary session information for authenticated users to establish the tenant to which the user belongs. Applications can authenticate in a variety of ways, so for any application that is being transformed, it must be parsed and understood by the authentication method.

Corent Multi-Tenant server
Corent's multi-tenant server enables our customers to quickly transform existing single-tenant Web applications into full multi-tenant SaaS solutions that are cloud-compatible and do not need to rewrite applications. Corent provides the most efficient and cost-effective multi-tenancy approach. This plug-in middleware solution, which enables multi-tenancy, is secure and scalable, and can significantly reduce the cost of service delivery.

You have the flexibility to choose your favorite technology stack and choose the operating system, database, and application you want to use. With a flexible architecture for multi-tenant servers, you can decide how to deploy your SaaS applications, build them yourself, or build them in any cloud. This allows the SaaS application to be deployed as a public service or as a private SaaS, which serves a limited group of people, such as a large enterprise, where the various departments are tenants.

Saas-cockpit is included with multi-tenant servers, enabling you to configure, manage, and monitor your SaaS users, as well as saas-factory, which enables tenant-based customization and enhancement of SaaS applications. By using Corent's complete set of solutions, the speed of converting applications to SaaS is greatly improved.

Corent and IBM? There are currently limited, compliant products available, offering free, proof-of-concept conversions that will transform ISVs ' Web applications into a multi-tenant SaaS solution running in the IBM SBDT Cloud and allow ISVs to try and run the final SaaS solution.

Step 1 shows you how to build a multi-tenant table and add a user table to maintain this relationship in your application data. Our goal is to implement a way to extend the user authentication process for the application so that the user can match the corresponding tenant after logging in, and TenantID becomes part of the session information.

This can be done in a number of ways, depending on the implementation of the application. If you use Tomcat as the application servlet container, you can use container-managed authentication to initiate a business rule that runs on a multitenant server to find the TenantID associated with the user. Alternatively, use a servlet filter to detect and set the thread local variable TenantID. For the jBilling in this example, the application validates its user table directly to complete authentication. Therefore, to provide enhanced authentication, you need to make some simple modifications to the authentication code and add some processes to find tenant information for the users who are stored in the new table.

The user is authenticated and knows the TenantID they belong to, and now has enough information to filter the data so that the user can access only the data of the tenant to which they belong.

Step 3. Configure Database connections
The Corent multi-tenant server is built on a service-oriented architecture and uses a Metamodel database (as described in step 1). The metamodel is used as an abstraction layer to model the original database of the application, while the application's database communication is redirected to the Metamodel abstraction rather than the actual database implementation. The method is to reconfigure the jBilling JDBC connection to access the Metamodel database instead of the actual MySQL database. For applications that use Hibernate, configure Hibernate's Corent dialect (dialect).

After making these modifications, the application database call is now directed to the Metamodel database. Are these SQL events Corent Agile controllers? Intercept and be passed to Corent's ADBC? (Agile Database Connector, nimble DB Connector). ADBC obtains the SQL statement that the application submits to the Metamodel database and parses it, and then adds a filter condition (for example, TenantID =) for the TenantID of the user who submitted the SQL in the session . This ensures that the data security in the shared database is maintained consistently and strictly. Even if an external application such as Reportwriter is connected to a database, the data it sees is still strictly limited to the data that corresponds to the tenant. Because we already know the identity of the logged-on user, we know which tenant it belongs to regardless of the user's application, so we apply the filter accordingly.

Because processing of SQL statements is done after they are submitted to the Metamodel database, and the tenant to which the user belongs is known, the Corent Agile Controller intercepts and performs more complex operations, including finding tenant-specific processes and configurations. Therefore, you can perform specific actions for each tenant, or even replace different database connections, so that a tenant can use the DB2 database, even if all other tenants use a MySQL database. Alternatively, a tenant can perform additional SQL operations to limit the data they can retrieve to records entered within the last 90 days. All of these customizations based on each tenant can be made through the Agile Rules Engine built into the multitenant server. Implementation and does not require any modifications to the original application code.

Figure 3. A custom structure based on each tenant
A custom structure based on each tenant
Complete transformations of the jBilling application require only minor modifications to the application, the most important of which is to include tenant information in the session information, and to modify the database connection to point to the Multitenant server. You can see that the changes to JBilling are summarized in the following few:

Original application
Number of source files: 897 (Java and JSP)
Total number of code lines: 76,621
The converted Application
Increased number of source files: 2 (Standard template)
Number of lines of code modified: less than 100
Application business logic modification: 0
including all the analysis and preparation work (judging where the code needs to be modified), the conversion to jBilling takes less than a week. Many of the modifications are to repeatedly modify a row in a Java snippet for JDBC access, which can be omitted if a database persistence layer such as Hibernate is used.

Step 4. Deploy new multi-tenant SaaS applications to the cloud
You can now deploy SaaS applications to a specified server, including servers in the cloud, using Saas-factory.

After selecting a server for the application and the database, the target database is generated (for example, for our jBilling application, which is the Windows? The MySQL database is used on the server) and will be fully configured for the multi-tenant server application in a group. The WAR file is deployed to the selected application server. Multi-tenant servers can use any modern Java EE Servlet container and are also certified for WebSphere application servers.

The deployed application is now able to handle multiple tenants. However, the original application now lacks a governance or management interface to manage tenants or monitor multi-tenant applications.

Saas-factory can also generate and install a saas-cockpit called? Companion application that provides these basic multi-tenancy services. It accesses the Metamodel database as the main application and has a management screen that is used to refer to tenants, assign Tenant Administrator accounts, and set basic parameters for a variety of available per-tenant-based application configurations. Management tools are also available to monitor and report on tenants and their users. Because one of the typical characteristics of SaaS applications is the need to track tenant subscriptions and accounting, there will be some tools for bookkeeping or integration with external billing systems.

Figure 4. Deploy new SaaS applications to the fabric in the cloud
Deploy new SaaS applications to the fabric in the cloud
This level of deployment is fairly basic in terms of SaaS application deployment. The characteristics of the application remain unchanged after the conversion, and standard deployment scenarios, including the use of cloud management tools to create templates and propagate application instances, can be used to deploy operational architectures that meet the requirements of the application for scalability, flexibility, resiliency, and redundancy.

A typical SaaS application might allow a load balancer to access a set of application servers and connect to a database server. The database server itself can be deployed as a cluster while using multiple database servers to provide redundancy and scalability.

IBM DB2 offers a number of technologies and configurations that can be used to achieve resiliency and guaranteed recovery time, and to allow the allocation of load on the database:

By using Standby mode (secondary mode) as a read-only database, the DB2 HADR (High Availability disaster recovery) configuration can provide both resilient availability and some load balancing.
IBM PureScale Technology and the Tivoli system Automation (TSA) support a clustered database environment in which multiple nodes share processing load, but have more limited hardware and operating system configuration.
For SaaS applications, database availability and failover are becoming more complex because any outage will have a greater impact on the customer/tenant than the traditional client software (Figure 5).

Figure 5. SaaS deployment architecture for scalable, resilient cloud operations
SaaS deployment architecture for scalable, resilient cloud operations
Future trends will be those that enable applications to run continuously, even when data is offline reorganized, schema evolution, version upgrades, and high load changes. Is IBM's PureScale technology migrating from Z System to AIX? and Linux, and supports capacity processing and uptime previously dedicated to dedicated mainframe environments.

Conclusion
The information technology industry is evolving to SaaS, and as you have speculated, there have been some notable changes in the field. Cloud computing is booming and growing faster than any other it wave, and SaaS is the driving factor behind this growth. This shift requires companies to rethink their business organizations and to think of new ways of thinking about service delivery in the cloud-centric IT world. For software vendors, there is a need to understand, prepare, and implement this shift more urgently, otherwise they will be left far behind and their products will become obsolete and digital garbage.

SaaS in the cloud differs significantly from the traditional software vendor model in terms of both technical and business aspects. These differences increase the risk of ISV transitioning to SaaS. To mitigate this risk and shorten time-to-market, ISVs can leverage a number of reliable technologies, products, and partners to make this transition happen.

Transform your Web application into a multi-tenant SaaS Solution