Architectural Concerns in Multi-Tenant SaaS Applications Rouven Krebs 1 , Christof Momm 1 and Samuel Kounev 2 1 SAP AG, Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany 2 Karlsruhe Institute of Technology, Am Fasanengarten 5, 76131 Karlsruhe, Germany {rouven.krebs, christof.momm}@sap.com, kounev@kit.edu Keywords: Multi-tenancy; SaaS; Platform; Resource Sharing; Affinity; Performance Isolation Abstract: Multi-tenant applications serve different customers with one application instance. This architectural style leverages sharing and economies of scale to provide cost efficient hosting. As multi-tenancy is a new concept, a common definition of the word and related concepts is not yet established and the architectural concerns are not fully understood. This paper provides an overview of important architectural concerns and there mutual influences. Beside that, it defines multi-tenancy and differentiates it from several related concepts. 1 INTRODUCTION Software-as-a-Service (SaaS) is a cloud service offer- ing comprising a ready to run, hosted application like a CRM 1 or a Web mailer 2 . To reduce the total costs of ownership (TCO), some of these SaaS offerings allo- cate users of different customers to the same applica- tion instance. If the users of one customer represent a closed group, which is usually charged and handled as a single entity, they are referred as a tenant. Applica- tions designed to serve multiple tenants with a single runtime instance are referred as multi-tenant applica- tions (MTA). Sharing resources in general yields cost benefits in cloud environments (Schuller, 2009). This is most efficient on the level of application instances (Momm and Krebs, 2011), since in this case the general over- head is minimal and it is possible to perform a very fine grained workload and resource management (e.g. requests, threads). To still meet customers’ expectations regarding the service levels, systems have to ensure a functional and non-functional isolation of the tenants, which is a major challenge, especially when the application in- stance itself is shared. However, from a research point of view multi- tenancy is a field that still introduces many undefined concepts and acronyms. This causes confusion, not only because of different definitions of multi-tenancy but also because of various biased assumptions about 1 e.g. http://www.salesforce.com 2 e.g. http://www.googlemail.com its implementation. The major contribution of this paper is a dis- cussion of software architecturel concerns for im- plementing multi-tenant applications by pointing out characterizing features and differentiating aspects from other related concepts such as system virtual- ization. The remainder of the paper is structured as fol- lows. Section 2 provides a definition of multi-tenancy, including a discussion of related concepts. Section 3 points out the major architectural concerns when de- signing MTAs and section 4 discusses the relation- ships between these concerns. Section 5 presents the related work, while section 6 concludes this paper. 2 SHARING CONCEPTS AND MULTI-TENANCY This section introduces different approaches for shar- ing resources in cloud environments and concise def- initions for the terms tenant and multi-tenancy. The following section briefly explains different commonly used sharing mechanisms based on (Os- ipov et al., 2009) (Guo et al., 2007) and discuss their relationship to our notion of multi-tenancy. 2.1 Different Layers When a single code base is shared between differ- ent customers/tenants it comes up with some require- ments for the code. If one single code base is used