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

Multitenancy - Security Risks and Countermeasures

Security within the cloud is of paramount importance as the interest and indeed utilization of cloud computing increase. Multitenancy in particular introduces unique security risks to cloud computing as a result of more than one tenant utilizing the same physical computer hardware and sharing the same software and data. The purpose of this paper is to explore the specific risks in cloud computing due to Multitenancy and the measures that can be taken to mitigate those risks.Security within the cloud is of paramount importance as the interest and indeed utilization of cloud computing increase. Multitenancy in particular introduces unique security risks to cloud computing as a result of more than one tenant utilizing the same physical computer hardware and sharing the same software and data. The purpose of this paper is to explore the specific risks in cloud computing due to Multitenancy and the measures that can be taken to mitigate those risks

Evaluating degrees of tenant isolation in multitenancy patterns : a case study of cloud-hosted Version Control System (VCS)

One of the key concerns of implementing multitenancy (i.e., serving multiple tenants with a single instance of an application) on the cloud is how to enable the required degree of isolation between tenants, so that the required performance of one tenant does not affect other tenants. There is little research which provides empirical evidence on the required degree of isolation between tenants under different cloud deployment conditions. 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 revealed 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 of errors with unacceptably slow response times) and throughput. 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 some recommendations to guide an architect in implementing multitenancy isolation on similar VCS tools like Subversion and CVS

Evaluating degrees of multitenancy isolation: a case study of cloud-hosted GSD tools.

Multitenancy is an essential cloud computing property where a single instance of an application serves multiple tenants. Multitenancy introduces significant challenges when deploying application components to the cloud due to the demand for different degrees of isolation between tenants. At the very basic degree of isolation, tenants still share application components as much as possible. However, while some components may benefit from low degree of isolation between tenants, others may need a higher degree of isolation, for instance, in a situation where a component is too critical to be shared, or needs to be configured specifically for individual tenants. This paper describes COMITRE (COmponent-based approach to Multitenancy Isolation Through request RE-routing) to empirically evaluate the degree of isolation between tenants enabled by three multitenancy patterns (i.e., shared component, tenant-isolated component, and dedicated component) for cloud-hosted Global Software Development (GSD) tools. We developed a multitenant component for each multitenancy pattern, integrated it within Hudson, and then compared their impact on different tenants. The study revealed among other things that a component deployed based on shared component offers a lower degree of tenant isolation (than tenant-isolated component and dedicated component) when one of the tenants is exposed to a demanding deployment condition (e.g, large instant loads). We also provide some recommendations to guide an architect in implementing multitenancy isolation on a set of GSD tools: Hudson, Subversion and Bugzilla

Migrasi Aplikasi Multitenancy Pada Layanan Komputasi Awan

Membangun infrastruktur teknologi informasi merupakan pekerjaan yang besar dan membutuhkan banyak sumber daya baik berupa biaya maupun sumber daya manusia. Biaya yang dibutuhkan meliputi biaya pengadaan perangkat keras, lisensi perangkat lunak, biaya pemantauan, pengaturan, dan perawatan infrastruktur. Solusi layanan komputasi awan hadir untuk menjawab masalah tersebut dengan menawarkan berbagai layanan yang dapat digunakan sesuai kebutuhan. Proses migrasi dari aplikasi on-premis kedalam layanan komputasi awan menjadi satu masalah yang sering dihadapi oleh pengembang aplikasi. Banyaknya pilihan desain arsitektur multitenancy yang dapat diimplementasikan membuat pengembang menjadi bingung untuk memilih desain arsitektur dan layanan komputasi awan yang tepat. Pada penelitian ini akan dievaluasi berbagai penerapan arsitektur multitenancy dan layanan komputasi awan dengan mempertimbangkan faktor kemudahan dalam hal migrasi aplikasi. Diharapkan hasil dari penelitian ini dapat digunakan oleh pengembang aplikasi ataupun Perusahaan/instansi yang akan membangun aplikasi multitenancy berbasis layanan komputasi awa

Implementing the required degree of multitenancy isolation : a case study of cloud-hosted bug tracking system

Implementing the required degree of isolation between tenants is one of the significant challenges for deploying a multitenant application on the cloud. In this paper, we applied COMITRE (COmponent-based approach to Multitenancy Isolation Through request RE-routing) to empirically evaluate the degree of isolation between tenants enabled by three multitenancy patterns (i.e., shared component, tenant-isolated component, and dedicated component) for a cloud-hosted Bug tracking system using Bugzilla. The study revealed among other things that a component deployed based on dedicated component offers the highest degree of isolation (especially for database transactions where support for locking is enabled). Tenant isolation based on performance (e.g., response time) favoured shared component (compared to resource consumption (e.g., CPU and memory) which favoured dedicated component). We also discuss key challenges and recommendations for implementing multitenancy for application components in cloud-hosted bug tracking systems with guarantees for isolation between multiple tenants

Multitenant Containers as a Service (CaaS) for Clouds and Edge Clouds

Cloud computing, offering on-demand access to computing resources through the Internet and the pay-as-you-go model, has marked the last decade with its three main service models; Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). The lightweight nature of containers compared to virtual machines has led to the rapid uptake of another in recent years, called Containers as a Service (CaaS), which falls between IaaS and PaaS regarding control abstraction. However, when CaaS is offered to multiple independent users, or tenants, a multi-instance approach is used, in which each tenant receives its own separate cluster, which reimposes significant overhead due to employing virtual machines for isolation. If CaaS is to be offered not just at the cloud, but also at the edge cloud, where resources are limited, another solution is required. We introduce a native CaaS multitenancy framework, meaning that tenants share a cluster, which is more efficient than the one tenant per cluster model. Whenever there are shared resources, isolation of multitenant workloads is an issue. Such workloads can be isolated by Kata Containers today. Besides, our framework esteems the application requirements that compel complete isolation and a fully customized environment. Node-level slicing empowers tenants to programmatically reserve isolated subclusters where they can choose the container runtime that suits application needs. The framework is publicly available as liberally-licensed, free, open-source software that extends Kubernetes, the de facto standard container orchestration system. It is in production use within the EdgeNet testbed for researchers

Rancang Bangun Sistem Enterprise Resource Planning pada Modul Procurement Process (Purchasing) Berorientasikan Multi-Tenancy dengan Sistem Basis Data Terdistribusi

Enterprise Resource Planning adalah sebuah sistem aplikasi yang digunakan untuk mengelola sebuah Perusahaan besar yang dirancang untuk mengkoordinasikan semua sumber daya, informasi, dan aktifitas yang diperlukan untuk proses bisnis lengkap. ERP memiliki beberapa modul, salah satu modul yang penting dan yang telah dikerjakan pada tugas akhir ini yaitu Procurement Process atau Purchasing. Purchasing adalah suatu proses pengadaan barang pada Perusahaan, Purchasing bertanggung jawab terutama pada pengurusan permintaan barang, pembelian barang, memonitor pembelian barang, dan pemilihan supplier. Pada modul Procurement Process dibuat sistem pembelian barang mulai dari permintaan pembelian barang (purchase requisition) sampai melakukan pembelian secara resmi (purchase order), dan menggunakan metode TOPSIS untuk menentukan supplier terbaik saat ingin membeli barang atau raw material berdasarkan dari transaksi pembelian yang telah terjadi sebelumnya. Hasil implementasi menunjukkan bahwa proses pembelian barang berhasil berjalan dengan baik dan benar. Untuk pemilihan supplier atau supplier analysis berhasil me-ranking supplier terbaik agar pembelian barang bisa berjalan dengan lanca