Develop and deploy multitenant Web-delivered solutions using IBM middleware, Part 1: Challenges and architectural patterns

Germán Goldszmidt (gsg@us.ibm.com), Distinguished Engineer, IBM　

Dr. Germán Goldszmidt is a distinguished engineer working in the IBM Software Group, with a focus on architecture of an integrated platform to deliver, customize, and deploy Service-Oriented Architecture (SOA) composite business services (CBSs).

Indrajit Poddar (ipoddar@us.ibm.com), Senior Software Engineer, IBM

Indrajit Poddar (IP) is a member of the Strategy, Technology, Architecture and Incubation (STAI) team in the IBM Software Group, where he is architecting a number of PoCs for building SOA composite business services using IBM SOA Foundation products.

Summary: Web-delivered solutions that follow a Software as a Service (SaaS) delivery model—where customers subscribe to software and access it from a service provider site rather than get licenses and have software installed on their premises—can offer compelling business value for businesses of any size. Solution developers who develop new solutions or transform existing solutions and service providers who deploy these solutions are faced with several technical challenges. One example is multitenancy, where a single instance of the software, running on a service provider's premises, serves multiple organizations. This article series describes different patterns to address these challenges, often using Service-Oriented Architecture (SOA) techniques. Also learn how IBM® software products can help you build and deploy scalable, configurable, and cost-effective multitenant Web-delivered solutions.

Date: 24 Apr 2008
Level: Intermediate
PDF: A4 and Letter (150KB)Get Adobe® Reader®
Activity: 1678 views
Comments:

What is multitenancy, and what are its benefits and drawbacks?

The ability to deliver software to multiple client organizations (or tenants) from a single, shared instance of the software is an important requirement for Web-delivered solutions. For example, consider a simple banking application offered as a service by a banking service provider. Multitenancy in this context refers to the ability to offer the banking service to multiple banks from a single, shared instance of the banking application. Figure 1 illustrates a multitenant banking service offered to two banks—1st Bank N.A. and 2nd Canada Bank—from shared application servers, databases, operating systems, and physical servers.

Figure 1. Sample multitenant Web-delivered service for banking built using shared middleware and hardware
Sample multitenant Web-delivered service for banking built using shared middleware and hardware

The major benefit of multitenancy is cost effectiveness. Sharing software, hardware, application development, and maintenance costs between tenants can lower the costs for each tenant. Furthermore, sharing a single instance of an application between tenants can provide additional benefits, for example, all tenants can be simultaneously upgraded whenever the application is upgraded.

However, multitenancy also brings potential issues, such as:

Isolation: Because tenants share the same instance of the software and hardware, it's possible for one tenant to affect the availability and performance of the software for other tenants. For example, if the shared software doesn't have adequate safeguards, it might be possible for one tenant's user to bring down the shared software, thus denying service to all the tenants sharing that instance.
Security: If the shared software doesn't have adequate safeguards, it might be possible for users of one tenant to access data belonging to another tenant.
Customizability: Because the software is shared between tenants, it may not be possible to customize the software for each tenant. For example, without adequate extension points, it may not be possible for one tenant to provide its own implementation of a business process.
Application upgrades can cause problems for a tenant: Simultaneously upgrading the shared software may not be desirable for all tenants.
Recovery: Sharing the database amongst tenants makes it difficult to back up and restore data for each tenant separately.

While there are multiple approaches for building a multitenant architecture, this article focuses primarily on techniques that enable sharing a single instance of the middleware and database, and amongst multiple tenant applications.

Other approaches for multitenancy include operating system (OS)-level virtualization. For example, VMWare, Xen, or OpenVZ allow multiple virtual instances of the OS to run on a shared instance of hardware. Each virtual OS instance can execute software for a different tenant. Another approach can be establishing OS-level boundaries for each tenant. For example, each tenant's application could be running in a new instance (different OS process) of IBM WebSphere® Application Server.

Multitenancy technical challenges

The technical challenges of multitenant applications can be categorized in terms of the major organizations and roles facing these challenges: the solution developers and the service providers.

Technical challenges faced by solution developers include:

Access control: How can application resources—for example, virtual portals; database tables; workflows; Web services; Java™ 2 Platform, Enterprise Edition (J2EE) artifacts—be shared between tenants so that only users belonging to a tenant can access the instances belonging to that tenant? For example, how can you ensure that users of other banks (such as 1st Bank N.A.) aren't able to access the resources (such as the virtual portal) for 2nd Canada Bank?
Customizability:
- Database: How do you customize a shared database schema for one tenant without affecting others? For example, how can 2nd Canada Bank introduce a new data field into the shared database table for customer profiles without impacting the schema definition for 1st Bank N.A.?
- User interface: How can you enable customization of the Web site look through configuration only (that is, without code changes)? For example, how do you ensure that bank administrators for 1st bank N.A. and 2nd Canada Bank can configure different designs and show additional fields in their customer profile portlets?
- Business logic: How can you allow the business logic to be customized for each tenant without code changes? For example, how can 1st Bank N.A. use a minimum credit score for automatically rejecting loan applications, which is different from 2nd Canada Bank?
- Workflows: How do you let tenant banks customize the assignment of human tasks and other conditional tasks in shared workflows? For example, how can 1st Bank N.A. ensure that the loan approval tasks in shared workflows be assigned to employees of 1st Bank N.A. only?
Tenant provisioning: How can you automate the provisioning of a new tenant? For example, how can a new bank, 3rd Fairfield Trust for example, be brought on board with very few manual steps (that is, how can steps like creating a new LDAP subtree or database, creating a new virtual portal, deploying new instances of portlets, and registering new IBM DB2® XML schemas be automated)?
Usage-based metering: How do you record usage of a service so that each tenant can be charged only for the usage of a service? For example, how can the banking service provider administrator meter service usage for the tenants, 1st Bank N.A. and 2nd Canada Bank, for the number of times their customers have invoked the loan application service?

Technical challenges faced by service providers include:

Database sharing, customization, backup, and restore of tenant-specific data: How can service providers choose between different database partitioning schemes based on performance, management, and scalability criteria? For example, how can the service provider accommodate 2nd Canada Bank's disaster-recovery requirement of backing up only its data from tables shared between multiple tenants?
Rapid enablement of multitenancy for existing Web services: How can single-tenant Web services implementations be enabled for multitenancy with little or no code changes? For example, how can you enable multitenancy for a single-tenant credit-check service without making code changes to the Web service interface and implementation?
Managing connectivity between a large number of third-party service providers and departmental service consumers in a large enterprise: Lines of business (LOBs) within large enterprises demonstrate many characteristics of a tenant in a Web-delivered application. Different LOBs in the same enterprise may consume services from different third parties or from internal service providers. A large number of such service providers may lead to management problems for the central IT department in the enterprise. For example, different LOBs (such as line-of-credit and mortgage loan departments) in the banking service provider enterprise may use different credit-check service providers. How can the central IT department monitor, authorize, and meter the usage of the multiple credit-check services by different LOBs in the enterprise?
Scalability, improved hardware usage, and tenant-specific quality of service (QoS): How can service providers improve the usage of hardware that's shared between different tenants and provide scalability? How can service providers offer differentiated QoS for different tenants? For example, how would you accommodate differentiated QoS requirement from 2nd Canada Bank so that its services are hosted in dedicated hardware in return for higher service usage charges?

Patterns for addressing multitenancy technical challenges

You can apply several SOA techniques to address the technical challenges related to multitenancy.

Patterns for solution developers

Start small with standards-based entry-level middleware: An upcoming article in this series describes how you can develop a multitenant Web-delivered application using entry-level middleware from IBM. This entry-level middleware stack includes IBM WebSphere Application Server Community Edition, IBM DB2 Express-C, and OpenLDAP. Solutions developed for the entry-level stack can give service providers the option of purchasing support from IBM. Watch a demo and download sample code for an application built using the entry-level stack. Figure 2 depicts the different functional layers of the sample multitenant application. Future articles in this series will show how to combine the entry-level stack with some products in the enterprise-level stack, such as IBM Tivoli® Usage and Accounting Manager and WebSphere Application Server, Extended Edition to support metering, scalability, and isolation.

Figure 2. Functional layers in a sample multitenant application built using IBM middleware
Grow into enterprise-level middleware: While it may be easier to get started with an entry-level stack, often advanced features, scalability, performance, and integration concerns are inadequately addressed. Thus, to build mission-critical Web-delivered applications, it's better to use enterprise-level middleware. In a series of recorded demonstrations, which you can access from the SaaS demonstration series, we describe multiple features of an enterprise-level IBM middleware stack and techniques that can be used to develop multitenant Web-delivered solutions. Additional technical details for each demo are included in a set of articles listed in the Resources section. Topics presented in the demo series include:
- Introduction: How middleware features can be exploited to build a multitenant application.
- WebSphere Portal Server: A technique for supporting multitenancy using virtual portals in WebSphere Portal Server (note that there are different ways of supporting multitenancy; this shows one possible technique). Read technical details from "Building SOA composite business services, Part 7: Supporting multitenancy for composite business services" (developerWorks, May 2007).
- IBM WebSphere Portlet Factory: How can you compose a portlet-driven multitenant user interface using dynamic profiles in WebSphere Portlet Factory? Read technical details from "Building SOA composite business services, Part 8: Building multitenant portlets using WebSphere Portlet Factory dynamic profiles" (developerWorks, Jun 2007).
- IBM DB2 V9: Designing a multitenant data architecture that allows customizing the schema for each tenant using pureXML. Read technical details from "Data Integration and Composite Business Services, Part 3: Build a multi-tenant data tier with access control and security" (developerWorks, Dec 2007).
- IBM WebSphere Portal Server, IBM WebSphere Process Server, and IBM Tivoli Directory Server: Demos on building a multitenant user registry and on enforcing role-based access control using WebSphere Portal Server and Tivoli Directory Server, and a demo on building secure workflows with human tasks using WebSphere Process Server and Tivoli Directory Server. Read technical details from "Securing a composite business service delivered as a software-as-a-service: Part I, secure multi-tenancy with WebSphere Portal Server" (developerWorks, Sep 2007) and "Securing a composite business service delivered as a software-as-a-service: Part II, Supporting identity propagation (enterprise and federated SSO) and authorization" (developerWorks, Sep 2007).

Figure 3 shows how different IBM middleware products in the entry-level stack and in the enterprise-level stack address these functional layers.

Figure 3. IBM middleware products used to implement the functional layers in the sample multitenant application built using IBM middleware

This series of articles builds on the above articles and demos, and describes some advanced techniques for building multitenant applications using IBM middleware. For example, one article will demonstrate how to isolate human tasks in shared multitenant workflows in WebSphere Process Server. Another article will describe how to use Tivoli Usage and Accounting Manager to provide usage-based metering and billing solutions.

Patterns for the service provider

Choose the right level of data-tier isolation for customizability and ease of tenant data management: Service providers can choose to:
- Isolate the data for each tenant into different databases.
- Isolate the data for each tenant into separate tables and a schema.
- Share the same set of tables and a schema between all tenants.
When sharing the schema between tenants, customizing the data fields for each tenant is a challenge. An upcoming article in this series evaluates a set of patterns for addressing this challenge from many dimensions, including performance, management, and scalability. IT also demonstrates some techniques to improve manageability, for example, showing how to accommodate backup and restore of tenant-specific data when sharing the schema between all tenants.
Rapidly enable multitenancy for existing Web services using IBM WebSphere Enterprise Service Bus, IBM WebSphere Business Services Fabric or IBM WebSphere DataPower® SOA Appliances: Service providers may need to rapidly enable multitenancy for an existing Web service implementation. Making code changes in existing implementations to support multitenancy from the ground up may require a significant effort. Alternatively, it's possible to build a middleware-based mediation layer to enable different Web service endpoints to service requests for different tenants. In this case, the existing Web service implementation doesn't need to be modified. An upcoming article in this series illustrates how you can implement this pattern using WebSphere Business Services Fabric, WebSphere Enterprise Services Bus, and WebSphere DataPower SOA Appliances.
Route third-party SaaS service invocations in large enterprises through a central mediation layer: An enterprise IT department can use a central mediation layer to route all third-party service invocations from different departments in an organization. This type of mediation layer can provide additional functions, such as authorization, monitoring, and metering for service usage. An upcoming article in this series demonstrates how a mediation pattern based on an enterprise service bus (ESB) can support these types of requirements.
Scale with entry-level middleware, and improve usage of hardware using IBM WebSphere Application Server, Extended Edition: Scalability requirements are often not given adequate consideration at the onset. When these requirements become important, service providers often scale out with a larger number of low-cost small servers. However, scaling out might bring out other challenges. For example, this approach may either:
- Lead to overprovisioning of hardware to support infrequent peak loads for a few tenants.
- Increase the management complexity due to a large number of middleware instances.
Isolate applications for different tenants, and support tenant-specific QoS requirements with WebSphere Application Server, Extended Edition: Service providers can isolate a tenant's application into dedicated hardware, while running other tenants' applications in shared hardware by exploiting server isolation policies in IBM WebSphere Extended Deployment. In addition, solution developers can take advantage of the programming model of the WebSphere Partitioning Facility feature in WebSphere Extended Deployment to build multitenancy-enabled applications. An upcoming article demonstrates how you can use WebSphere Extended Deployment to support tenant-specific QoS requirements and partition applications for multitenancy.

Conclusion

Scalable multitenancy is an important requirement for Web-delivered (SaaS) solutions. However, building multitenant solutions requires addressing several technical challenges. Using IBM middleware, solution developers and service providers can build and deploy scalable, customizable, manageable, and cost-effective multitenant solutions. This series of articles presents a few relevant IBM middleware features and techniques, and describes how to apply them to address the above technical challenges. Stay tuned!

Resources

Learn