Multi-tenancy Pattern Research Articles

Degrees of tenant isolation for cloud-hosted software services: a cross-case analysis

A challenge, when implementing multi-tenancy in a cloud-hosted software service, is how to ensure that the performance and resource consumption of one tenant does not adversely affect other tenants. Software designers and architects must achieve an optimal degree of tenant isolation for their chosen application requirements. The objective of this research is to reveal the trade-offs, commonalities, and differences to be considered when implementing the required degree of tenant isolation. This research uses a cross-case analysis of selected open source cloud-hosted software engineering tools to empirically evaluate varying degrees of isolation between tenants. Our research reveals five commonalities across the case studies: disk space reduction, use of locking, low cloud resource consumption, customization and use of plug-in architecture, and choice of multi-tenancy pattern. Two of these common factors compromise tenant isolation. The degree of isolation is reduced when there is no strategy to reduce disk space and customization and plug-in architecture is not adopted. In contrast, the degree of isolation improves when careful consideration is given to how to handle a high workload, locking of data and processes is used to prevent clashes between multiple tenants and selection of appropriate multi-tenancy pattern. The research also revealed five case study differences: size of generated data, cloud resource consumption, sensitivity to workload changes, the effect of the software process, client latency and bandwidth, and type of software process. The degree of isolation is impaired, in our results, by the large size of generated data, high resource consumption by certain software processes, high or fluctuating workload, low client latency, and bandwidth when transferring multiple files between repositories. Additionally, this research provides a novel explanatory framework for (i) mapping tenant isolation to different software development processes, cloud resources and layers of the cloud stack; and (ii) explaining the different trade-offs to consider affecting tenant isolation (i.e. resource sharing, the number of users/requests, customizability, the size of generated data, the scope of control of the cloud application stack and business constraints) when implementing multi-tenant cloud-hosted software services. This research suggests that software architects have to pay attention to the trade-offs, commonalities, and differences we identify to achieve their degree of tenant isolation requirements.

A new usage control protocol for data protection of cloud environment

With the rapid development of the cloud computing service, utilizing traditional access control models was difficult to meet the complex requirements of data protection in cloud environment. In cloud environment, the definition of data and its protection are gradually varied when contents shifting from one virtual machine to another; in these new scenarios, the multi-tenancy pattern has been taken as a core attribute. For this reason, many users need to change their roles according to different situations; certifications has impact much more complicated challenges in cloud environment while access control was suitable for the static status but no longer for the changing situation. In this paper, a new usage control protocol model--multi-UCON (MUCON) based on usage control (UCON), combined with encryption technology and the digital watermarking technology, is proposed with the characteristics of flexible accrediting, feature binding, and off-line controlling. The analysis and simulation experiments indicate that the proposed protocol model is secure, reliable, and easy to be implemented, which can be deployed in cloud computing environments for data protection.

Evaluating Degrees of Isolation between Tenants enabled by Multitenancy Patterns for Cloud-hosted Version Control Systems (VCS)

When implementing multitenancy for cloud-hosted applications, one of the main challenges to overcome is how to enable the required degree of isolation between tenants so that the required performance, resource utilization, and access privileges of one tenant does not affect other tenants. This paper applies COMITRE (COmponent-based approach to Multitenancy Isolation Through request RE-routing) to empirically evaluate the degree of isolation between tenants enabled by multitenancy patterns for cloud-hosted Version Control System (VCS). We implemented three multitenancy patterns (i.e., shared component, tenant-isolated component, and dedicated component) by developing a multitenant component using the FileSystem SCM plugin integrated within Hudson. The study confirmed that dedicated component provides the highest degree of isolation between tenants (compared to shared component and tenant-isolated component) in terms of error% (i.e., the percentage oferrors with unacceptably slow response times) and throughput. The system load of tenants showed no variability, and hence did not influence the degree of tenant isolation for all the three multitenancy patterns. We also provide a summary of recommended multitenancy patterns for optimizing performance and utilization of resources for cloud-hosted software services, as well as recommendations to guide an architect in implementing multitenancy isolation on similar VCS tools like Subversion and CVS.

Horizontal and vertical combination of multi-tenancy patterns in service-oriented applications

Software as a service (SaaS) providers exploit economies of scale by offering the same instance of an application to multiple customers typically in a single-instance multi-tenant architecture model. Therefore the applications must be scalable, multi-tenant aware and configurable. In this article, we show how the services in a service-oriented SaaS application can be deployed using different multi-tenancy patterns. We describe how services in different multi-tenancy patterns can be composed on the application level. In addition to that, we also describe how these multi-tenancy patterns can be applied to middleware and hardware components. We then show with some real world examples how the different multi-tenancy patterns can be combined.