ArticlePDF Available

Multi-tenancy Design Patterns in SaaS Applications: A Performance Evaluation Case Study


Abstract and Figures

Utility-like computing has emerged as the future of computing for many organizations seeking to remain competitive in today's business environment. Promising features such as rapid elasticity, low cost provisioning, pay-as-use model, layered security, measured service, resource pooling, are the reasons companies are opting for this technology. Cloud technologies are provided as services ranging from Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS) and Data as a Service (DaaS). SaaS has become one of de facto approach for deploying cloud base services or applications for many businesses. At the core of SaaS is Multi-tenancy; multi-tenancy gives customers (i.e. tenants) and providers vast opportunities to leverage the power of cloud infrastructure by consolidating operational entities. The drive toward multi-tenancy in SaaS application is a result of the economic benefit derived by shared development and maintenance cost. This paper presents different multi-tenancy models at the data layer as dedicated, isolated and shared. The paper further empirically evaluates the performance of these models in a containerized environment. Our results show that under a containerized environment dedicated and isolated schema performed reasonably well in terms of latency when compared to shared model. Although the shared model proved to more resource efficient, it performance is greatly affected by finite resources shared by many concurrent tenants.
Content may be subject to copyright.
Multi-tenancy Design Patterns in SaaS Applications: A Performance
Evaluation Case Study
Adeniyi O. Abdul1, Julian Bass1, Hossein Ghavimi2, Natalie MacRae2 and Peter Adam2
1School of Computing, Science and Engineering, University of Salford
2Add Energy Ltd.
Utility-like computing has emerged as the future
of computing for many organizations seeking to
remain competitive in today's business environment.
Promising features such as rapid elasticity, low cost
provisioning, pay-as-use model, layered security,
measured service, resource pooling, are the reasons
companies are opting for this technology. Cloud
technologies are provided as services ranging from
Infrastructure as a Service (IaaS), Platform as a
Service (PaaS), Software as a Service (SaaS) and
Data as a Service (DaaS). SaaS has become one of
de facto approach for deploying cloud base services
or applications for many businesses. At the core of
SaaS is Multi-tenancy; multi-tenancy gives
customers (i.e. tenants) and providers vast
opportunities to leverage the power of cloud
infrastructure by consolidating operational entities.
The drive toward multi-tenancy in SaaS application
is a result of the economic benefit derived by shared
development and maintenance cost. This paper
presents different multi-tenancy models at the data
layer as dedicated, isolated and shared. The paper
further empirically evaluates the performance of
these models in a containerized environment. Our
results show that under a containerized environment
dedicated and isolated schema performed reasonably
well in terms of latency when compared to shared
model. Although the shared model proved to more
resource efficient, it performance is greatly affected
by finite resources shared by many concurrent
1. Introduction
Many businesses today are looking for economic
viable approach to scale their information
management system and manage the current
explosion of business data. Building a system of data
analytical application with a scalable and elastic
environment such as cloud will bring maximum
return on investment for enterprise. Cloud
Computing offers business on-demand, utility-like
computing provisioning with minimal start-up cost
and operating cost. One of the bedrocks of cloud
environment is resource sharing. Resource sharing,
at different software levels, helps businesses to take
advantage of the benefits of cloud with minimal cost
burden. Multi-tenancy has emerge as a technology
that can help businesses effectively share cloud
resources while maximizing their sales profit and
reducing the cost of application hosting, software
development and maintenance. On this premise,
multi-tenancy in a SaaS application is a architectural
pattern that entails several tenants (customers) to
share resources at different tiers of an application.
This might range from tenants sharing the same user
interface components, business logic right down to
data layer, however each tenant only access
functions or components and data belonging to their
business entity. In contrast to multi-user model
(traditional), where an application is designed and
developed with the same functionalities but with
limited configuration and hosted in a single instance.
The advantage of multi-tenant application is its
ability to support multi-faceted functionalities which
maybe similar or varying and has the capability to
scale horizontally.
A similar architecture to multi-tenant is Multi-
instance, this leverage the power of virtualization
technology to host the same application code on
many different instances to accommodate spike in
demand for resources. These instances are pooled
such that it acts as a single resource server to handle
increasing users work loads. [8] Argued that multi-
instance architecture can be used to deploy multi-
tenant application where the number of tenants is
remain relatively low.
According to Antonio [14], a tenant in a multi-
tenant environment subscribes or pays to use the
SaaS application however a tenant comprises many
end-users. In other words, a tenant represents a group
of users of an organization that employs a set of
SaaS customized functionalities in multi-tenant
environment to achieve organizational goals. The
business requirements, configurability, scalability,
security requirements and the costing model, among
others, will determine which multi-tenancy model
will be employed when implementing SaaS
application. SaaS applications architect must be able
to determine which multi-tenancy model will best
serve different business requirements without
compromising on performance and security of each
tenant. [18] Stated that multi-tenancy can be realized
at the application level, the business logic
International Journal of Digital Society (IJDS), Volume 9, Issue 1, March 2018
Copyright © 2018, Infonomics Society
(middleware), virtualization layer and data layer. The
next section presents multi-tenancy at the data layer.
2. Multi-Tenancy Model
2.1. Dedicated Model
In a dedicated model, the tenant applications and
database are isolated at the instance level or database
level. Each instance or database instance entirely
host different tenant application and nothing is
shared among tenants. This scenario can be
employed when each client is perceived as entity
without any related business logic or where the data
privacy and regulations are of most concerns.
Dedicated model gives the highest level of isolation
compared to others, however hosting large number
of databases can be costly and practically impossible
for many SaaS providers because of the number of
customers they aim to serve.
In dedicated mode, extending or restoring
individual tenant database instance can be easily
achieved without any disruption to other tenants.
However extra costs such as software licensing,
hardware and development cost will be per tenant
and considerably high because of strong data
isolation and extra security and customization put in
place. Please see Figure 1.
Figure 1. Dedicated database
2.2. Isolated Schema Model
In an Isolated Schema, the tenant tables or
database components are group under a logical
schema or name-space and separated from other
tenant schemas, however the schema are hosted in
the same database instance. Though there is some
level of logical isolation however it’s not instance
level isolation, this might cause some down time for
tenants when migrating or during maintenance for
other tenant schema. This is very suitable where the
schema of each tenant is different and changes often.
It mitigates the cost of dedicated model and the
security limitation of shared model.
A significant drawback of this model is that
extending or restoring a database instance might
disrupt some tenants’ with data co-hosted on the
same database and the limit of number tables
permitted by the database. However having a
scalable database with robust redundancy can help
mitigated and reduce the down time. The model is
appropriate for tenants with few numbers of tables
because of the limitation on the number of tables that
a database instance can accommodate. Please see
Figure 2.
Figure 2. Tenant Isolated
2.3. Shared Schema Model
In a shared schema, the tenant shared common
components of the application especially at the data
layer with the degree of isolation provided at row
level. Sets of tables are used to store all the data
belonging to all the tenants of the application.
Developers must architect their database access
security such that tenant cannot access other tenant
data. Same tables are used to store tenant related data
with tenant identifier to differential tenant data. This
model is commonly used in applications where the
client data are closely related or using meta-data
architecture for data remodeling. Data extensibility is
a great challenge with Shared model compared to
isolated schema.
Figure 3. Shared Model
Shared schema model [14] provides data
extensibility using multi-tenant metadata and
multitenant indexes. This type of design requires
complex schema and creation of pre-allocated fields
(dummy columns) violating relational database
normalization rules [1]. However, it offers the lowest
cost in terms of hardware, software licensing,
development and backup cost. This model is
appropriate when the application is design to
accommodate large number of tenants willing to
International Journal of Digital Society (IJDS), Volume 9, Issue 1, March 2018
Copyright © 2018, Infonomics Society
forfeit strong level of isolation for lower cost of
usage. Please see Figure 3 above.
2.4. Partially Isolated Component / Hybrid
This is a bridge between shared model and tenant
isolated schema model. In this model, components
that have common functionalities are shared among
tenants while components with unique or unrelated
functions are isolated. At the data layer, common
data such as data that identify tenants are grouped or
kept in single table while tenant specific data are
isolated at table or instance layer.
Figure 4. Partial Isolated
The contribution of this paper is to empirically
detailed the performance of each multi-tenancy
model using a real life example and bridge the
knowledge gaps relating to architecting a multi-
tenancy application and show how he choice of
multi- tenancy model can affect the performance of
SaaS application. The case study chosen for this
evaluation is a multi-tenancy solution for asset and
integrity management application designed to
optimized maintenance strategies for various clients
in oil and energy sector. To properly carry out this
evaluation, an in-house application has been
developed to address each multi- tenancy model and
deployed using a containerized platform for
experimental repeatability.
This paper aims to address this research question
- ”How does multi-tenancy models affect the
performance of cloud-hosted asset integrity
application”. Providing empirical answers to this
question will elucidate how each multi-tenancy
model can affect the design of this application in
terms of latency and throughput.
The rest of the paper is organized as follow -
section 2 presents related works in the field of cloud
application, SaaS application, and multi-tenancy and
software containerization. Section 3 introduce the
research methodology and expatiate on the case
study employed for the empirical evaluation. Section
4 presents experimental and results of our study.
Section 5 presents the conclusion of our work.
3. Related Work
In this section, we present previous research,
models and deployment patterns related to cloud
computing, SaaS application and multi-tenancy. Also
we reviewed deployment pattern using
containerization approach to further understand how
this approach can be deployed in repeatable multi-
tenant environment. This will give us insight into
how researchers and software engineers have tried to
proffer solutions to some of the challenges and
difficulties of resource sharing using multi-tenancy
and containerization.
In today’s business climate, cloud offering
promises cost-effective realization for many
businesses striving to remain competitive in their
industries. Promising features, such as
interoperability, scalability, on-demand resource
provisioning, pay-as-use model, central resource
management, resource sharing etc., have changed
how information technology (IT) solutions are
consumed by many business [16]. Prior to cloud
computing, businesses have to provision software
applications that meet their needs and also provision
in house hardware to support these legacy
applications. This mode of IT provisioning has its
own pros and cons, but in this ever-changing
environment couple with data explosion and severe
business competition, businesses are turning to cloud
computing for IT solutions.
Different models of cloud computing have
emerged as services to cater for different business
needs. The emerging models are Infrastructure as a
Service (IaaS), Platform as a Service (PaaS),
Software as a Service (SaaS), Data as a Service
(DaaS) [2]. Software as a Service has gained wider
attentions because this directly relates to end-users.
[18] Stated many limitations of legacy software
application can be addressed by distributed software
services with real time configuration and
provisioning. SaaS becomes economic viable for
cloud providers and affordable for SaaS consumer
through resource sharing. Resource sharing is
achieved in SaaS via multi-tenancy. The idea of
multi-tenancy started as a result of the success
achieved through the use of virtualization
technologies in (aaS architecture. The advent of
cloud computing and desire to maximize server
utilization and minimize provisioning cost, led to
multi-instances which gave birth to multi-tenancy.
SaaS providers want solutions that can handle many
tenants with similar or disparate business
requirements with minimum code maintenance and
high degree of configurability.
[4] And [3] highlighted some of the challenges
and concerns of multi-tenancy are conceptual
framework, configuration and customization, data
separation, security, performance, deployment, zero-
downtime, maintenance and metering. Due to
International Journal of Digital Society (IJDS), Volume 9, Issue 1, March 2018
Copyright © 2018, Infonomics Society
resource sharing, multi-tenant application must
tackle interference and ensure security isolation
among tenants. [19] argued that multi-tenant
isolation, configuration and customization increase
the engineering complexity of SaaS application.
Multitenant configuration support pre-defined
parameters that users can set on the data model,
interface and the business level of the application
while customization according to [19] is
implementing variations of software that meet
specific tenant requirements and deployed at the run-
time. The authors proposed customization of multi-
tenant application using dependency injection for
injecting different software variations at the middle
layer. [19] Discussed how ontology can be used to
create multi-layered customization for tenant across
[12] Evaluates the degree of isolation between
tenants and proposed component-based approach to
multi-tenancy isolation through request re-routing.
This research highlights an interesting result in
response time between shared component and the
two other models (tenant isolated and dedicated
component). Principle of improving isolation of
security, performance at the application-level was
presented by [9].
[10] States that one of the major obstacles to
cloud adoption is lack of performance benchmarking
especially in multi-tenant applications. The proposed
a benchmark to evaluate the maximum throughput
and the amount of tenants a multi-tenant can
accommodate. This work motivate our research to
evaluate the performance in terms of latency for a
containerized multi-tenant application using different
multi-tenancy models
4. Methods
Our research employs the use of case studies
approach to methodically evaluate the performance
of multi-tenancy model. Case study has shown it best
suitable for conducting empirical investigation into
contemporary phenomenon within its real-life
context [20]. A business application (AimHi)
developed to be used by multiple tenants in cloud-
based environment was selected as our case study.
The application is engineered to optimize
maintenance management and improve asset
integrity in the field of oil and energy. This will
enable tenants and application users to improve
maintenance planning and reduce cost of
maintenance. This application is chosen because of it
requirements as a multi-tenant application and the
data size that needs to be processed to perform its
functionalities. Tenants of our application share
requirements of high similarity (common functions)
and requirements that are distinctive to each tenant.
In this case, a tenant is a group of users representing
an organization that utilize the application to
actualize the business goals of the organization.
AimHi is developed to interface with CMMS system
such as SAP used across oil and gas field. After
many years of consultations and development,
AimHi is a fully functional application deployed on
Amazon web service.
The case study application is a cloud-based
application called AimHi that gather and transform
maintenance data into comprehensive rich visuals to
better provide insight into maintenance strategy
employed by our clients. These needs arise mainly
for managements and stakeholders to be informed on
what maintenance is been carried out, what its
benefit for the business in terms of cost and
resources saving and providing insight into how
operational performance can be improved. Currently
the application is been used by an energy company
(named withheld for confidentiality) to monitor and
improve their power generation plants. This
application is selected as a case study because of its
multi-tenant capabilities to serve organizations with
multi-faceted requirements in the field of gas and
The first version of AimHi was released in July
2015 and deployed on Amazon elastic beanstalk with
load balancer and Amazon RDS (MySQL) as the
back end. Stress and Integration test were carried out
to ascertain its behaviour under different load
behaviour. JMeter and Amazon cloud watch were
used to monitor the latency, throughput and
utilization of the application. This preliminary test
gave insight into the performance of the chosen
multi-tenancy architecture, which led to
reimplementation of some of the data component of
the application. This research work will expose how
the application will perform under different
architectures and properly lead to a robust
implementation of the application.
Case studies are suitable for exploratory research
in which a hypothesis describing some phenomena is
developed [28]. The longitudinal embedded case
study approach was employed in order to provide a
holistic, in-depth, analysis of one setting and are
characterized by production of rich and detailed
descriptions [29].
4.1. Experimental Setup
As discussed in the case study section, our
application (AimHi) is a SaaS web-based application
for asset and integrity management deployed on
Amazon cloud. In order to ensure experimental
repeatability, the application is developed,
containerized and deployed using docker. The
objective of our performance test is to evaluate the
performance of three variants of multi-tenancy
model using Aimhi as the case study. These are the
scopes of testing:
1) The testing is carried to evaluate the
latency when processing asset integrity key
International Journal of Digital Society (IJDS), Volume 9, Issue 1, March 2018
Copyright © 2018, Infonomics Society
performance indicators (KPI) such as preventive,
corrective maintenance.
2) Performance test does not include the front or GUI
part of the application; instead performance latency
will be evaluated by conducting restful calls to the
endpoints provided by the application. This will help
evaluate multi-tenant model and eliminate the
processing time used to render the application in the
3) This test evaluates the multi-tenancy at the data
tier level therefore the same application calculations
or algorithm were used with only changes carried out
at the data access level (Hibernate) and database.
4) The test carried out on incremental concurrent
users while the data size remains constant. This helps
to evaluate the performance behaviour as the
concurrent user base increases.
5) The test carried also evaluate the incremental data
size while the number of concurrent users is set
constant. This helps to evaluate the performance
behaviour as the data size increases. This is
important because the application was designed to be
used by tenants with varying data size.
Three variants of the same application were
designed and implemented to address each multi-
tenancy model. Each variant is hosted in docker
container running on a machine with 16GB memory,
3.1 GHz Intel core i7 and mac0S Sierra. Inside each
is an Apache web server connecting to java servlets
container running the AimHi application and
connected to MySQL relational database system as
the database system. The application is developed
using a restful technology exposing endpoints
returning JSON data, which are consumed by
JavaScript front-end code (angularjs). Please see the
Figure 4 below of architecture of the system:
Figure 4. Aimhi Test Architectural Diagram
The implementation of multi-tenancy in each of the
variant has been done at the data tier layer. Each data
layer variant implementation corresponds to each
multi-tenancy model.
Each data layer variant implementation
corresponds to each multi-tenancy model. In the
separated database model, each tenant set of tables is
created in a separate database hosted in their own
docker container instance.
In the tenant isolated, each tenant set of tables is
created separately (group in name-space) but resides
in the same database hosted in a single container
instance. While in shared a set of tables are created
that stores all the data related to all the tenants, for
example a table storing maintenance details contains
all the maintenance data for all the tenants of the
application. Lastly, in the partially isolated model,
data that highly related such as authentication and
authorization for each users are stored in a single
table while data that highly disparate in
representation, meaning and requirements are store
in tables associate to that tenant only. The last model
might helps cater for tenants that require data
isolation as a result of data protection law for
example EU data protection law. The
containerisation of the data instance for this model is
highly dependent on the requirement and size of the
tenants and data. See section I-A for each diagram of
multi-tenancy model.
Our goal in this research paper is to test the
performance of each of the variant of multi-tenancy
model in a containerised environment. In order to do
this, Apache JMeter application is used to conduct
load testing and measure performance in terms of
response time. Apache JMeter is open source
software written in Java for conducting load test to
evaluate functional behaviour and measure
performance. Our choice of load testing software is
influenced because of its multi-threading
capabilities, high extensibility and ability to test
many different application and protocol. The Apache
JMeter tool was used to simulate heavy concurrent
workload usage against Tomcat environment housing
our multi-tenant application in a cloud environment.
Table 1. Test For Each Variant of Multi-tenancy
Test For Each Variant of Multi-tenancy Model
Concurrent Users
per min
Total table records
International Journal of Digital Society (IJDS), Volume 9, Issue 1, March 2018
Copyright © 2018, Infonomics Society
Figure 5. Latency across all endpoints
Figure. 6. Performance latency below 200 Users
Figure 7. Performance latency above 200 Concurrent users
International Journal of Digital Society (IJDS), Volume 9, Issue 1, March 2018
Copyright © 2018, Infonomics Society
These tests were carried out to perform the base
test on the restful endpoints provided by our case
study application (AimHi). One variable is varied
while the other was held constant to further
understand how this variable affects the behaviour of
the system. The number of tenants used in this test is
three and the number of restful endpoints tested is
ten. The test only covered a read operation both at
the application level and data level, other types of
operations such as delete, write /put will be carried
out in our further research which is not covered in
this paper.
5. Results
As stated in the last section, the application is
configured to handle three tenants with varying
number of concurrent users targeting various restful
endpoints. The first set of tests for three models were
performed using the same number of endpoints and
dataset. Please see the results as shown in Figure 5.
The diagram above shows comparison between the
shared component, isolated schema and dedicated
component. The result shows that across all the
endpoints tested, the shared model experience high
latency compared to the isolated schema and
dedicated. In some endpoints where calculations over
large dataset are required, for example weekly fetch
trends, the difference in latency is in magnitude of 2.
However, the behaviour of the three models are
consistent across all the endpoints as seen in the
Figure 5.
The dedicated latency was lower compared to
isolated schema model, the difference is not
noticeable in this test however as the number of
tenants and processing increases, dedicated will tend
to perform better in terms of latency because of
dedicated resources without any interference from
other tenants. Figure 6 shows tests across the same
number of endpoints using the three models when
the user base is varied.
The figure shows up to 200 concurrent users, the
dedicated and isolated schema performed reasonable
well compared to shared component. This might be
due to the records/rows selection process at the data
layer when retrieving records belonging to a tenant
or context switch between tenants in the shared
component. However, there is a big leap in the
latency when the number of user base hit 200 for the
shared model. This occurs as more requests were
queued and this causes delay in the processing.
6. Discussion
Another interesting result emerged when the
three models were processed over increasing number
of users as seen in figure 7. It was observed that
although shared model is resource efficient, it
reaches is maximum capacity around 200 concurrent
users while isolated shared component reaches its
maximum capacity at about 300 concurrent users,
and dedicated was able to process the same dataset
without any delay or errors. As the number of
concurrent users increases in shared and isolated,
there is exponential increase in latency across all
Our presumption about the exponential increase
in the two models might be as a result of saturated
connection pooling size, which was set to 2000 and
has to be shared among many tenants. Please note in
this test, all form of data caching was disabled in
order to show the models behaviour with any
enhance algorithms.
Our empirical results are in consonant with the
assertion made by [12] that there is a specific
fraction of concurrent users a system can handle
before the system starts queuing request or, in
extreme cases, request can be dropped. Universal
Scalability law introduced by [9] and Amdahl’s law
introduced by [6] both detailed functions to
determine capacity of a system in terms of user load.
[12] Asserted that resident time (latency time) of a
system will start growing exponentially when the
capacity is less than the concurrent users it can
handle which is what is observed in both cases of
multi- tenancy models experimented.
7. Conclusion
This research work systematically evaluates the
performance of different multi-tenancy models at the
data tier layer. Three (shared, isolated schema, and
dedicated component) types of multi-tenancy models
were presented. A case study approach was adopted
to examine the performance of two the listed multi-
tenancy models. The empirical experiments
compared shared model against isolated schema
using the same case study scenario and under the
same circumstance. Our results show that the
performance in terms of latency of isolated schema is
better than the shared model. However, both models
reach their full capacity at different concurrent
number of users.
Shared model reaches maximum capacity under a
lower concurrent user loads compared to isolated
schema model. However when designing SaaS
application such as relational database service where
the number of tenants are considerable large, the use
of partial isolated schema that creates a meta table
that describe each tenant data structure and store
shared data together for all the tenants data might be
best options for ease of maintainability and economic
standpoint. In conclusion, the number of concurrent
user loads, the size of tenants, the duration of queries
performed and the size of data store should be
critical element when choosing which multi-tenancy
model to adopt when designing an application. Our
research has shown insight how the performance of
International Journal of Digital Society (IJDS), Volume 9, Issue 1, March 2018
Copyright © 2018, Infonomics Society
SaaS application can be impacted by the choice of
the multi-tenancy model employed at the data tier
layer. Our future works will explore how to best
configure a multi-tenant application using Meta data
pattern such as to increase isolation and
8. Future Works
This research work has open up further works to
better capture the performance of multi-tenancy
under different scenario. Our future works will look
into performance and interference that may occur
when writing and deleting tenant records in a shared
model. Another interesting area is hierarchical multi-
tenancy; many organisations are structured in
hierarchical way with various business rules and data
governance. Our next work will study how multi-
tenancy can implemented in this kind of organisation
and provide challenges when developing hierarchical
multi-tenant application. This will be extended into
containerized technologies for portability across
various platforms.
9. References
[1] Mohemed Almorsy and John Grundy. “SMURF:
Supporting Multi-tenancy Using Re-Aspect
Framework”. In: 17th IEEE International Conference
on Engineering of Complex Computer Systems
(ICECCS 2012) (2012).
[2] Michael Armbrust et al. Above the Clouds: A
Berkeley View of Cloud Computing. Tech. rep.
[3] Cor-Paul Bezemer and Andy Zaidman. “Multi-
Tenant SaaS Applications: Maintenance Dream or
Nightmare?” In: In Proceeding of 4th International
Join ERCIM/IWPSE Symposium on Software
Evolution (IWPSE-EVOL) (2010), pp. 8892.
[4] Ngo Huy Bien and Tran Dan Thu. “Hierarchical
Multi- Tenant Pattern”. In: 2014 International
Conference on Computing, Management and
Telecommunications (ComMan Tel) (2014), pp. 88
[5] Christoph Alexander Fehling et al. Cloud
Computing Patterns: Fundamentals to Design, Build,
and Manage Cloud. The Science of Microfabrication.
Springer, 2014.
[6] Eduardo B. Fernandez. “Patterns for operating
system access control”. In: In Proc. of PLoP 2002
[7] Amdahl G.M. “Validity of the single processor
approach to achieving large scale computing
capabilities”. In: In American Federation of
Information Processing societies: Proceedings of the
AFIP ’67 Spring joint Computer Conference (1967).
[8] Chang Jie Guo et al. “A framework for native
multitenancy application development and
management”. In: In Proc. Int. Conf. on E-
Commerce Technology (CEC) and Int. Conf. on
Enterprise Computing (2007), pp. 551 558.
[9] Changjie Guo et al. “A Framework for Native
Multi- Tenancy Application Development and
Management.” In: CEC/EEE. IEEE Computer
Society, 2007, pp. 551 558. ISBN: 0-7695-2913-5.
URL: http://dblp.uni- trier.
[10] Rouven krebs, Alexander Wert, and Samuel
Kounev. “Multi-tenancy performance benchmark for
web application platforms”. In: ICWE 13
Proceedings of the 13th International conference on
web Engineering 7977 (3 2013), pp. 424438.
[11] Guthaus M.R et al. “Mibench: a free,
commercially representative embedded benchmark
suite”. In: In Proceeding of International Workshop
on Workload Characterization (2001), pp. 314.
[12] Laud Charles Ochei, Andrei Petrovski, and
Julian M. Bass. “Degree of Multitenancy Isolation
for Cloudhosted Software Services: Synthesis of
findings from three Case Studies”. In: International
Journal of Intelligent Computing Research (IJIR) 6
(3 2015).
[13] Laud Charles Ochei, Andrei Petrovski, and
Julian M. Bass. “Evaluating degrees of tenant
isolation in multitenancy patterns: a case study of
cloud-hosted version control system (VCS)”. In:
International conference on information society (i-
society) (2015), pp. 5966.
[14] Davy Preuveneers et al. “Systemic scalability
assessment for feature oriented multi-tenant
services”. In: The Journal of Systems and Software
116 (2016), pp. 162 176.
[15] Antonio Rico et al. “Extending multi-tenant
architectures: a database model for a multi-target
support in SaaS applications”. In: Enterprise
Information Systems 10.4 (2016), pp. 400421.
[16] Bhaskar Prasad Rimal, Eunmi Choi, and Ian
Lumb. “A Taxonomy and Survey of Cloud
Computing Systems”. In: Proceedings of the 2009
Fifth International Joint Conference on INC, IMS
and IDC. NCM ’09. Washington, DC, USA: IEEE
Computer Society, 2009, pp. 4451. ISBN: 978-0-
7695-3769-6. DOI: 10. 1109 / NCM.2009.218. URL: 2009.218.
[17] The Multitenant
Architecture Understanding the Design of Internet Application Development
Platform. White Paper., 2001.
International Journal of Digital Society (IJDS), Volume 9, Issue 1, March 2018
Copyright © 2018, Infonomics Society
[18] Mark Turner, David Budgen, and Pearl
Brereton. “Turning Software into a Service”. In:
Computer 36.10 (Oct. 2003), pp. 3844. ISSN: 0018-
9162. DOI: 10.1109/MC. 2003.1236470. URL: 2003.1236470.
[19] Stefan Walraven, Eddy Truyen, and Wouter
Joosen. “A Middleware Layer for Flexible and Cost-
efficient Multi-tenant Applications”. In: Proceedings
of the 12th ACM/IFIP/USENIX International
Conference on Middleware. Middleware’11. Lisbon,
Portugal: Springer- Verlag, 2011, pp. 370389.
ISBN: 978-3-642-25820-6. DOI: 10. 1007 / 978 - 3 -
642 - 25821 - 3 19. URL: http:
// 19.
[20] R.K. Yin. “Case Study Research: Design and
Methods”. In: 3rd edition. SAGE Publications
International Journal of Digital Society (IJDS), Volume 9, Issue 1, March 2018
Copyright © 2018, Infonomics Society
... Unlike multi-users and multi-instances, multi-tenants are able to share one application for several tenants with different locations. Abdul et al. [21] they can provide great opportunities to harness the power of cloud infrastructure enabling the tenants to increase the consolidation of data layer operational entities to be dedicated, isolated, and shared. The use of infrastructure can also be done in other ways by applying a multitenant management pattern [22], [23] such as the model-view-controller (MVC), model-view-presenter (MVP), and model-view-view-model (MVVM). ...
Full-text available
In the new-normal era, public services must make various adjustments to keep the community safe during the COVID-19 pandemic. The Public Service Mall is an initiative to put several public services offices in a centralized location. However, it will create a crowd of people who want access to public service. This paper evaluates multi-tenant models with the rapid adaptation of cloud computing technology for all organizations' shapes and sizes, focusing on multi-tenants and multi-services, where each tenant might have multiple services to offer. We also proposed a multi-tenant architecture that can serve queues in several places to prevent the spread of COVID-19 due to the crowd of people in public places. The design of multi-tenants and multi-services applications should consider various aspects such as security, database, data communication, and user interface. We designed and built the "QuAntri'' business logic to simplify the process for multi-services in each tenant. The developed system is expected to improve tenants' performance and reduce the crowd in the public service. We compared our agile method for system development with some of the previous multi-tenant architectures. Our experiments showed that our method overall is better than the referenced model-view-controller (MVC), model-view-presenter (MVP), and model-model-view-presenter (M-MVP).
Cloud computing is a highly popular computing technique. Cloud combined with IoT, fog, edge, and mist computing in 5G networks gives us realtime and highly predictive responses leading to a better and smart life. It requires a highly robust and integrated cloud administration, especially cloud resource allocation. Artificial intelligence and machine learning can be easily implemented along cloud design patterns for efficient resource allocation. In this paper we discuss multi-tenant cloud resource allocation problem. We propose to use a rule-based analysis pattern to dynamically reconfigure resource allocation processes. The pattern uses various attributes of clouds, resources, subscribers and requests along with heuristic data like configurations, policies, strategies, and methods to efficiently identify and apply rule of allocation. We implemented a decision tree to assist pattern to have automated decisions, which rule to follow. The pattern caters for multi-objectivity, simplifies architecture, enables the extension of the cloud framework and makes it possible to interact easily with cloud. This paper describes the architectural framework pattern, which learns from itself. This paper presents CK’s object-oriented metrics comparisons of pattern-based object-oriented code. The comparison shows that object-oriented code improves code quality, making pattern-based code more maintainable, flexible, extendable and secure.KeywordsCloud design patternDecision treeMulti objective approachDynamic resource allocationStrategic behavior
Conference Paper
Full-text available
Conference Paper
Full-text available
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.
Conference Paper
Full-text available
Application-level multi-tenancy is an architectural design principle for Software-as-a-Service applications to enable the hosting of multiple customers (or tenants) by a single application instance. Despite the operational cost and maintenance benefits of application-level multi-tenancy, the current middleware component models for multi-tenant application design are inflexible with respect to providing different software variations to different customers. In this paper we show that this limitation can be solved by a multi-tenancy support layer that combines dependency injection with middleware support for tenant data isolation. Dependency injection enables injecting different software variations on a per tenant basis, while dedicated middleware support facilitates the separation of data and configuration metadata between tenants. We implemented a prototype on top of Google App Engine and we evaluated by means of a case study that the improved flexibility of our approach has little impact on operational costs and upfront application engineering costs.
Recent software engineering paradigms such as software product lines, supporting development techniques like feature modeling, and cloud provisioning models such as platform and infrastructure as a service, allow for great flexibility during both software design and deployment, resulting in potentially large cost savings. However, all this flexibility comes with a catch: as the combinatorial complexity of optional design features and deployment variability increases, the difficulty of assessing system qualities such as scalability and quality of service increases too. And if the software itself is not scalable (for instance, because of a specific set of selected features), deploying additional service instances is a futile endeavor. Clearly there is a need to systematically measure the impact of feature selection on scalability, as the potential cost savings can be completely mitigated by the risk of having a system that is unable to meet service demand.
Multi-tenant architectures (MTAs) are considered a cornerstone in the success of Software as a Service as a new application distribution formula. Multi-tenancy allows multiple customers (i.e. tenants) to be consolidated into the same operational system. This way, tenants run and share the same application instance as well as costs, which are significantly reduced. Functional needs vary from one tenant to another; either companies from different sectors run different types of applications or, although deploying the same functionality, they do differ in the extent of their complexity. In any case, MTA leaves one major concern regarding the companies’ data, their privacy and security, which requires special attention to the data layer. In this article, we propose an extended data model that enhances traditional MTAs in respect of this concern. This extension – called multi-target – allows MT applications to host, manage and serve multiple functionalities within the same multi-tenant (MT) environment. The practical deployment of this approach will allow SaaS vendors to target multiple markets or address different levels of functional complexity and yet commercialise just one single MT application. The applicability of the approach is demonstrated via a case study of a real multi-tenancy multi-target (MT2) implementation, called Globalgest. Up to 50 free copies available at
personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. Acknowledgement The RAD Lab's existence is due to the generous support of the founding members Google, Microsoft, and Sun Microsystems and of the affiliate members Amazon Web Services, Cisco Systems, Facebook, Hewlett-
Conference Paper
Cloud environments reduce data center operating costs through resource sharing and economies of scale. Infrastructure-as-a-Service is one example that leverages virtualization to share infrastructure resources. However, virtualization is often insufficient to provide Software-as-a-Service applications due to the need to replicate the operating system, middleware and application components for each customer. To overcome this problem, multi-tenancy has emerged as an architectural style that allows to share a single Web application instance among multiple independent customers, thereby significantly improving the efficiency of Software-as-a-Service offerings. A number of platforms are available today that support the development and hosting of multi-tenant applications by encapsulating multi-tenancy specific functionality. Although a lack of performance guarantees is one of the major obstacles to the adoption of cloud computing, in general, and multi-tenant applications, in particular, these kinds of applications and platforms have so far not been in the focus of the performance and benchmarking community. In this paper, we present an extended version of an existing and widely accepted application benchmark adding support for multi-tenant platform features. The benchmark is focused on evaluating the maximum throughput and the amount of tenants that can be served by a platform. We present a case study comparing virtualization and multi-tenancy. The results demonstrate the practical usability of the proposed benchmark in evaluating multi-tenant platforms and gives insights that help to decide for one sharing approach.
Conference Paper
Software-as-a-service multi-tenancy helps service providers to cut cost, improve resource utilization, and reduce service customization and maintenance time as the tenants share the same service instance. However, existing large-scale business applications inherently do not support multi-tenancy. This hinders these applications' vendors from adopting the cloud model. Thus reengineering such applications to support multi-tenancy has become a key requirement. Reengineering such applications to support multi-tenancy is a complex and challenging task as it requires a deep understanding of the given application and almost all system modules need to be revisited. In this paper we introduce SMURF, Supporting Multi-tenancy Using Reengineering Aspects "Re-Aspect" Framework, to help service providers reengineering their legacy applications to support multi-tenancy. SMURF is based on our new re-aspects concept where a given system modification to disable, modify, replace or inject code is encapsulated in a re-aspect. SMURF realizes given system modifications (captured as re-aspects) by automating both change impact analysis and change propagation processes. We analyze the SaaS multi-tenancy pattern, discuss the set of requirements to migrate a single-tenant application to support multi-tenancy, describe SMURF approach, architecture and implementation details, and present our experimental results of SMURF on a set of open source web applications.
Conference Paper
The computational world is becoming very large and complex. Cloud Computing has emerged as a popular computing model to support processing large volumetric data using clusters of commodity computers. According to J.Dean and S. Ghemawat [1], Google currently processes over 20 terabytes of raw Web data. It's some fascinating, large-scale processing of data that makes your head spin and appreciate the years of distributed computing fine-tuning applied to today's large problems. The evolution of cloud computing can handle such massive data as per on demand service. Nowadays the computational world is opting for pay-for-use models and Hype and discussion aside, there remains no concrete definition of cloud computing. In this paper, we first develop a comprehensive taxonomy for describing cloud computing architecture. Then we use this taxonomy to survey several existing cloud computing services developed by various projects world-wide such as Google,, Amazon. We use the taxonomy and survey results not only to identify similarities and differences of the architectural approaches of cloud computing, but also to identify areas requiring further research.
Conference Paper
We present architectural patterns for access control in operating systems. These complement the patterns that we introduced in a previous paper. The patterns control access to resources represented as objects and include patterns for authentication, process creation, object creation, and object access.