multitenancy - Develop and Deploy Multi-Tenant Web-delivered Solutions using IBM middleware

Cloud/Multitenancy 2013. 4. 26. 11:55


Develop and Deploy Multi-Tenant Web-delivered Solutions using IBM middleware: Part 1: Challenges and architectural patterns


Germán Goldszmidt (gsg@us.ibm.com), Distinguished Engineer, IBM, Software Group
Indrajit Poddar (ipoddar@us.ibm.com), Senior Software Engineer, IBM

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.

View more content in this series


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.

Back to top

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?

Back to top

Patterns for addressing multitenancy technical challenges

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

Patterns for solution developers

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
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.

Back to top

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

Get products and technologies

  • Innovate your next development project with IBM trial software, available for download or on DVD.

Discuss

About the authors

author photo

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 photo

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.



출처 - http://www.ibm.com/developerworks/webservices/library/ws-middleware/index.html




Develop and Deploy Multi-Tenant Web-delivered Solutions using IBM middleware: Part 2: Approaches for enabling multi-tenancy


Carl Osipov (osipov@us.ibm.com), Software Architect, IBM
Germán Goldszmidt (gsg@us.ibm.com), IBM Distinguished Engineer, IBM
Mary Taylor (marytaylor@us.ibm.com), Consulting IT Specialist, IBM
Indrajit Poddar (ipoddar@us.ibm.com), Software Architect, IBM

Summary:  Part 1 of this series describes what multi-tenancy is and presents several technical challenges for building and deploying multi-tenant web-delivered solutions. In this article, we identify five representative approaches for enabling multi-tenancy in web-delivered solutions (also known as software-as-a-service) and compare their costs and benefits.

View more content in this series



Introduction

Service providers contemplating web-delivery of existing or new multi-tenant services are often faced with a number of design choices. We have identified five major approaches as shown in Figure 1. Approach 1 is sharing a single application instance i.e. the same servers, middleware and applications, amongst all tenants. Approach 5 is having tenant specific application instances run on separate servers (which is what many Application Service Providers or ASPs do currently). In between, we have identified at least three other major approaches which require varying degrees of resource sharing and development complexity. Each approach provides different benefits due to scale and operational efficiencies and costs due to development complexities and time-to-market.


Figure 1. Five major approaches for enabling multi-tenancy
Five major approaches for enabling multi-tenancy 

In this article, there are a number of roles we will use to describe the different approaches for multi-tenancy:

  1. Service Provider: responsible for providing the services/solution in the web-delivery model
  2. Service Developer: developer of the services/solution being offered
  3. Tenant: Customers of the service provider
  4. End-users: A tenant may have one or more end-users of the service/solution

The five major approaches that service providers can use are:

  1. Shared middleware with a single application instance
  2. Shared middleware with multiple application instances and shared address spaces
  3. Shared middleware with multiple application instances and separate address spaces
  4. Virtualization with tenant specific virtual images
    a). Virtualization with a Mediation layer
  5. ASP model with multiple instances on separate servers

We will describe each of these five approaches in more detail in the following sections. When determining which of these approaches to adopt, it helps to understand the costs and benefits associated with each approach. We provide such a cost/benefit analysis in a following section.

Back to top

Shared middleware approaches

Approaches 1, 2 and 3 represent different degrees of sharing of the middleware and the application components between multiple tenants. In the following subsections, we show examples of each approach.

Approach 1: Shared middleware with a single application instance

All tenants share the operating system, servers, and a single instance of the middleware and application. This is accomplished by parameterizing a single instance of an application with a tenant identification parameter. For example, if the application has web service interfaces and implementations, then a tenant ID parameter is added to the operations and data objects in the interface. If the application uses database tables, then a new column designating the tenant ID is added to each table in the database. In this model, there are some configuration elements that are unique to each tenant. For example, a virtual portal is configured for each tenant with a different look-and-feel and unique database schema elements are offered to each tenant.


Figure 2. Topology example for Approach 1, sharing a single instance of the application and middleware between multiple tenants
An example topology for Approach 1, sharing a single instance of the application and middleware between multiple tenants 

In Figure 2 we show a sample topology using this approach. There are three tenants: A, B and C, which share the same code for Application 1. Application 1 uses Tomcat and DB2 running on Windows on a Blade server, and Apache HTTP server running on Linux on another physical server. The middleware, OS and Servers are shared amongst all of the tenants. Sample code for an example multi-tenant application using this approach can be downloaded from “Building Web delivered SaaS applications on open source and entry level IBM middleware”. When a tenant is on-boarded, tenant specific configurations (e.g., CSS files for each tenant) are created for that tenant, but there is only one instance of the application which is shared between all the tenants. Using this approach, the application must be designed to provide the capability to isolate each tenant’s data and customizations from the other tenants. Parts 3 and 4 of this series will present important architectural considerations for using this approach for enabling multi-tenancy with IBM WebSphere Application Server.

Approach 2: Shared middleware with multiple application instances in shared address space

Tenants use different instances of the application deployed on a single instance of the middleware which share a single operating system process (address space). Tenants share the operating system and servers. Figure 3 shows an example application shared by tenants A, B, and C using this approach.


Figure 3. Topology example for approach 2, running different instances of the application for different tenants in a single instance of the middleware
An example topology for approach 2 i.e. running different instances of the application for different tenants in a single instance of the middleware 

When a new tenant is on-boarded a separate copy of the application is created and given a name that includes a tenant identifier and deployed to a shared instance of the application server. For example, the ear file for Application App (App.ear) would be copied and named App1.ear and App2.ear respectively. Similarly, in the database tier, an application table called App_table would be copied into two tables App1_table and App2_table for tenants A and B respectively. Tenant specific customizations (e.g. CSS files and table schemas) are added to the tenant specific copy of the application and table. This model requires that tenant isolation be maintained at the middleware layer.

Approach 3: Shared middleware with multiple application instances in separate address space

Tenants use different instances of the application deployed on different instances of the middleware. Tenants share the operating system and servers. Since the middleware instance is different, each tenant is allocated its own set of operating system processes (i.e. address space). Thus this model requires that tenant isolation be maintained at the operating system layer. This approach supports fewer tenants than approaches 1 and 2 on the same physical server. This approach also offers more isolation amongst tenants within the three shared middleware approaches. But isolation concerns still exist at the OS and servers layers, e.g., it is possible for one tenant’s users to consume all the CPU or memory in the physical server.


Figure 4. Topology example for approach 3, running different instances of the application for different tenants in different instances of the middleware 
An example topology for approach 3, running different instances of the application for different tenants in different instances of the middleware  

In the example in Figure 4, we see that each tenant (A, B and C) is running its own physical copy of the same application (App1, App2 and App3 respectively), in its own physical copy of the middleware (M1, M2 and M3 respectively). Tenants A and B are running their applications on Windows, while Tenant C is running their application on Linux. Of the three shared middleware approaches, this approach requires the least amount of changes to an existing application, possibly enabling faster deployment. In an upcoming demo in the SaaS Blueprints series will show an example of this approach using WebSphere Smash and MySQL as the middleware running a multi-tenant phpBB bulletin board application.

Back to top

Virtualization approaches

Virtualization technology is used to run multiple operating system partitions with dedicated application and middleware instances for each tenant on shared servers.

Approach 4: Virtualization with multiple VM images

Tenants use different virtual images with different instances of application, middleware and operating system while sharing physical servers. In recent years, server virtualization has gained widespread adoption in x86 based servers and is rapidly becoming a low cost, commodity technology.

In contrast to the shared middleware approach, server virtualization does not require significant code development to enable multi-tenancy. Once server virtualization is installed on a physical server (host), a service provider provisions each additional tenant by instantiating a virtual server (guest) to host tenant specific software, including middleware and applications.

One of the technical challenges in multi-tenancy is provisioning new tenants. For provisioning new tenants service providers have to work with potentially lengthy and complex installation and configuration steps. Virtual appliances (e.g. VMWare Virtual Appliance for WebSphere Application Server Network Deployment V7.0 Open Beta) with pre-configured tenant specific operating system, middleware can help to address this challenge.

Figure 5 shows an example of this approach where a native hypervisor such as VMWare ESX™ or Xen is installed on physical servers. In this example, a 2 CPU, 2 Ghz physical blade server A in the green box at the bottom is partitioned into 2 single CPU 2 Ghz virtual blade servers: vBlade 1 and vBlade 2 in the black box. Virtual blade server: vBlade 3 is composed of a single 4 CPU 2Ghz server B. The virtual servers also share other resources of the physical server, such as memory, disk space and the network connection. Applications: App4, App5 for two different tenants are deployed in into vBlade 1 and vBlade 2 and App6 is deployed into vBlade 3. Note, that tenants are allowed to have different operating systems.


Figure 5. Native hypervisor based server virtualization for multi-tenancy
Native hypervisor based server virtualization for multi-tenancy 

Approach 4a: Virtualization with a Mediation layer

A service provider centralizes common multi-tenancy functions such as routing, access control and metering in a mediation proxy layer. A mediation layer can be used in conjunction with a virtualization approach by integrating it with tenant specific service instances running in separate virtual image partitions. The mediation proxy layer sits between the end user of the application and the services within the application and dynamically binds or routes service requests from a tenant’s users to tenant specific instances of the services as shown in Figure 6.

Figure 6 also describes an example of the mediation approach where the service provider uses a WebSphere DataPower SOA appliance (WDP) to implement a mediation proxy layer. In this example, routing rules are configured in a WDP web service proxy to route requests from users for two different tenants (A and B) to the respective tenant-specific instance of an application. In addition, multi-tenancy functions such as metering, access control and auditing are added by integrating other middleware components such as Tivoli Access Manager and Tivoli Usage and Accounting Manager.


Figure 6. Example of a mediation approach for multi-tenancy using WebSphere DataPower SOA appliances
Example of a mediation approach for multi-tenancy using WebSphere DataPower SOA appliances 

In parts 5, 6, 7 and 8 of this series, we will present three alternative options for implementing this approach using the following alternative combination of products:

  • WebSphere Business Services Fabric
  • WebSphere DataPower SOA appliances with Tivoli Access Manager
  • WebSphere Enterprise Services Bus with WebSphere Service Registry and Repository

Approach 5: ASP model with multiple instances on separate servers

Tenants share only the infrastructure of the data center e.g. power, cooling but use different instances of the application, middleware, operating system and servers. Figure 7 shows an example where tenants A, B and C have three different application instances AppA, AppB and AppC running on tenant specific middleware instances, operating system instances and physical servers. This approach is most suitable for workloads and scenarios where a high degree of isolation and customization is required for different tenants.


Figure 7. Example of an ASP model for enabling multi-tenancy with multiple instances on separate servers
Example of an ASP model for enabling multi-tenancy with multiple instances on separate servers 

Back to top

Cost-benefit comparison of the multi-tenancy approaches

The cost benefit analysis presented in this section is considered from the perspective of the service provider and the service developer.

Approach 5 (i.e. the ASP approach) is the most expensive for the service provider when scaling to large number of tenants. In the other four approaches there is a higher degree of sharing of resources which leads to improved cost efficiencies and economies of scale as shown in the two yellow arrows in Figure 1. The following types of tenant specific costs can be incurred:

  • Physical Server: Each tenant requires dedicated servers, disk space and ancillary equipment.
  • Administration: servers, and in particular software, requires continuous upkeep such as installation of security patches, upgrade of the OS and middleware, user account management and so on. These tasks have to be conducted separately on each tenant’s infrastructure.
  • Operation: running a data center requires electricity, cooling and many real estate related expenses which grow significantly when more tenants are added.

However, this approach is the least expensive approach for a service developer because no application changes are necessary to enable multi-tenancy. Also this approach offers the highest degree of isolation between and customizability for tenant specific instances.

Approaches 1 through 3 (i.e. the shared middleware approaches) have the lowest operational cost of the three sharing models because of increased sharing of resources (servers, middleware and OS) leading to a fewer number of components to manage. This approach also offers efficiencies of scale because of the highest density of tenants hosted on a single physical server. Approach 1 (i.e. the single application instance) could be the most expensive option for the service developer because it may require significant redesign of existing applications with high development time and costs. In addition, it requires knowledge of advanced application server features and techniques and skilled developers.

Approach 4 (i.e. multiple virtual images) is less expensive than the shared middleware approaches (approaches 1-3) for the service developer because little or no application changes are required. This allows for faster, more expedient time-to-market. Adding a mediation layer (approach 4a) in the virtualization approach also makes it less complex and time consuming to integrate other multi-tenancy enabling functions such as access control and metering.

Table 1 provides a summary of the cost benefit comparison between the shared middleware approaches (1-3) and the virtualization approach (4 and 4a).


Table 1. A cost-benefit comparison of three major multi-tenancy approaches
Shared Middleware approachesVirtualization and Virtualization with Mediation
Benefits
  • Ability to SCALE to additional tenants quickly
  • COST EFFECTIVE since the infrastructure is shared by all tenants
  • LESS OVERHEAD than a virtualized or mediated approach
  • No application RE-DESIGN is necessary
  • Some minor integration code changes may be necessary to efficiently enable ADDITIONAL COMMON MULTI-TENANCY FEATURES such as:
    - Access control
    - Metering
    - HETEROGENEITY and transformation in protocol & interfaces in tenant specific applications
  • FASTER time to market and LOWER up front cost
  • Isolation for better SECURITY and AVAILABILITY for tenants
  • Higher degree of HW and OS CUSTOMIZATION is provided than in a shared environment
    - Supports HETEROGENEITY (OS, HW) for tenant applications
  • Simpler to RELOCATE the application to another platform provider
  • Simpler BACKUP and DISASTER RECOVERY for each tenant
Costs
  • Requires application RE-DESIGN or CODE CHANGES of existing single tenant code in approach 1
  • TIME-TO-MARKET impact of re-architecting applications for multi-tenancy
  • HIGHER UPFRONT COST when code changes are necessary
  • SKILLED PROGRAMMERS REQUIRED to implement approach 1
  • ADDED COMPLEXITY in providing features such as backup and restore customized for each tenant
  • LOWER SCALABILITY in number of tenants per server
  • GREATER PERFORMANCE OVERHEADS
  • HIGHER OPERATIONAL COSTS and MANAGEMENT COSTSbecause of multiple instances of virtual machine images
  • HIGHER DEPLOYMENT COSTS when deploying to a mediation layer

Back to top

Conclusion

The journey from a traditional application service provider model to a web delivery model has many entry points/approaches with differing costs and benefits for the service provider and the service developer. We have presented five such entry points which differ in the degree of resource sharing and development complexity. The goals of this journey are to keep improving cost efficiencies and keep lowering total cost of ownership. This article offers various pros and cons to help select the right entry point and prepare architectures suitable for incremental improvements towards these goals.

Back to top

Acknowledgements

The authors would like to acknowledge the contributions of Ajay Mohindra and Suresh N. Chari from IBM Research to Figure 1 describing the major multi-tenancy approaches.


Resources

About the authors

Carl

Carl Osipov is an experienced software architect with the Strategy and Technology organization in IBM Software Group. His skills are in the area of distributed computing, speech application development, and computational natural language understanding. He has published and presented on Service-Oriented Architecture and conversational dialog management to peers in the industry and academia. His current focus is on design of reuse techniques for composite business services.

Goldszmidt

Dr. Germán Goldszmidt is an IBM Distinguished Engineer working in Software Group, Technical Strategy. He is responsible for the SWG Advanced Technology program, including incubation projects and the cross Software Group Research Joint Program. He has lead multiple projects in the area of Composite Business Services and Software as a Service. Before 2003 he was a Research Staff Member and Manager at the IBM Research T.J. Watson labs. He led the team that developed the first compute provisioning e-utility that efficiently handles varying workloads and infrastructure changes by autonomically adjusting resource allocations. Earlier, he designed and developed Network Dispatcher, a high performance load balancer which provides reliability and scalability for multiple IBM products and deployments. He has published more than 50 papers in refereed journals and conference proceedings, and holds 15 patents.

Mary Taylor

Mary works in the SWG Technical Strategy and Incubation team and administers the SWG Incubation program. She is co-lead of a SaaS Community of Practice and is a contributor to the SaaS Blueprints. She is currently focused on the positioning of IBM middleware in the financial markets front office.

Indrajit Poddar

Indrajit Poddar (IP) is a member of the Strategy, Technology, Architecture, and Incubation team at IBM Software Group Strategy, where he leads several integration PoCs for building composite business services delivered in the Software-as-a-Service (SaaS) model.




출처 - http://www.ibm.com/developerworks/webservices/library/ws-multitenantpart2/





저작자표시

'Cloud > Multitenancy' 카테고리의 다른 글

multitenancy - Multi-Tenant Database Architecture  (0) 2013.04.27
Posted by linuxism
,

티스토리툴바