Project topics and materials
Get Complete Project Material File(s) Now! »
Technical Background
This chapter gives a theoretical background for this study. Section 2.1 presents a theoretical description of tenancy models and SaaS. Section 2.2 presents the tenancy model of single tenant application, single database. Section 2.3 presents the tenancy model of multi tenant application, database-per-tenant. Section 2.4 presents the tenancy model of multi tenant application, sharded database. In Section 2.5, the concept of elastic pools is described. eDTU is explained in Section 2.6. A comparison from Microsoft was helpful in this study, it is presented in Section 2.7 and is provided in Appendix A. Last in this chapter, Section 2.8 presents how all the other sections in this chapter are used in the rest of this study.
Introduction to Tenancy models & SaaS
SaaS is a way providing a complete software service over the Internet, that is rented by the customers from the SaaS provider. In the context of SaaS, the correct terminology of a customer is the word tenant 1. Hereinafter, we will refer to customer as a tenant. All of the underlying hardware, middleware, infrastructure, back-end software and application-data are located and pro-vided by the SaaS provider’s data center. [3][11] As shown in Figure 2, it describes how a SaaS-solution is used from a high level perspective, where tenants represent the organizations or private entities that are renting the SaaS. Users represents someone that is using the SaaS from inside a tenant, for example, employees from the organization that rents the SaaS.
With SaaS, you do not have to install and maintain the application by your-self as a customer, you let it over to the provider instead. This is putting less weight on the customer, since they do not have to manage complex software and hardware. The SaaS provider will manage access, security, availability and performance. The provider installs and maintain the SaaS-application while you access it over Internet. [11] The usage of a SaaS solution has ben-efits compared to applications installed on merely the customer’s own ma-chine:
• Access to advanced software. Instead of the customer is managing, buying and deploying the needed hardware and software; with SaaS applications it is not needed. With a SaaS application the customer do not need to update, install, maintain any software, hardware or mid-dleware, since it is already assured by the provider of the service.[3]
• Pay only for what you use. A SaaS application is automatically scaling up and down depending on the usage. [3]
• Use free client software. Almost all SaaS application’s parts that run on the client-side, are running directly in the browser. Therefore, there is no need of downloading and installing specific software to run the SaaS application. [3]
• Mobilize your workforce easily. A workforce will be mobilized effi-ciently, since it is possible for a user to access a SaaS application from anywhere, from any device that is connected to Internet. There is no need to worry to develop applications that runs on different Operating Systems, since it is already assured by the service provider.[3]
• Access application data from anywhere. Since the data that the SaaS
application uses is stored in the cloud2, it can be accessed from any ma-chine that has an Internet connection. This will also minimize the risk of data loss in case of broken machine, since it is stored in the cloud.[3]
As mentioned in Section 1.1, a tenancy model describes how a tenant’s data is mapped to the storage on the server-side of the SaaS application. The choice of tenancy model will not affect the functionality of the application, but it will affect other aspects of the application. Furthermore, the choice of a tenancy model is having a large impact on both design and management of a SaaS application. A decision of changing to a different tenancy model for a SaaS application can be costly in certain cases.[4] This study is focusing on three tenancy models, which are described below in Section 2.2, Section 2.3 and Section 2.4.
Single Tenant Application, Single Database
The single tenant application, single database is a tenancy model where each tenant gets a dedicated application installed on the SaaS provider’s server, look at Figure 3. All of the dedicated installations of the application have a standalone database connected, which no other installations can ac-cess. [4]
Since every database that belongs to a tenant is connected to the dedicated installation to the corresponding tenant, this model provides the greatest isolation.[4] The connection string to the database that belongs to a tenant is hard-coded in the setup in the corresponding application.
Multi tenant Application, Database-per-tenant
The multi tenant application, database-per-tenant is a tenancy model where one single application is installed at the SaaS provider’s server, look at Fig-ure 4. For each tenant, a dedicated database is connected to the application. A database belonging to a specific tenant can exclusively be accessed by that tenant. Furthermore, there is need for a Catalog Database in multi tenant application, database-per-tenant. The catalog database holds essential in-formation about each tenant, like connection string to database and display name.
Multi tenant Application, Sharded Database
The multi tenant application, sharded database is a tenancy model where one single application is installed at the SaaS provider’s server, like in multi tenant application, database-per-tenant, look at Figure 5. The difference between multi tenant application, database-per-tenant and multi tenant application, sharded database, is that an installation of a database can be shared among tenants.[4] A sharded database is when several physical dis-tributed databases is logically acting as one database with the same schema. A ”shard” is the physical database, which has the same schema as all of the other shards, but its own distinct subset of data. In multi tenant applica-tion, sharded database, one tenant’s data must be stored in the same shard. When working with shards, a shard key is used to determine which data that should be placed in each shard.[12] In our case, we will map data belonging to a tenant to the shard that holds the data of the tenant, therefore we use a tenant-id (which is unique) on the data as a shard key.
Elastic Pools
A common way of providing tenants with data-storage, is to give each ten-ant a dedicated database that has some resources allocated for utilization, for example: IO- and CPU-time. But every different tenant has a different unpredictable usage pattern. Hence it is hard to predict the resource require-ment for each tenant. One way to solve this problem is to use an elastic pool. Elastic pools gives the possibilities to group together databases into a ”pool”. Instead of giving each database a set of resources, you give the pool a set of resources that all the databases in the pool are sharing.
The usage of elastic pools can lower the cost on resources because the databases is sharing the resources and it is unlikely that several databases gets a heavy workload at the same time. [13]
eDTU
Elastic Database Transaction Unit (eDTU) is Microsoft Azure’s way of mea-suring the resources allocated for an elastic database-pool. eDTU is calcu-lated from a combination of hardware specific resources, more exactly: CPU, I/O and storage.[4].
Microsoft’s Comparison
Microsoft has created a comparison of tenancy models. This comparison is only a supplement in this study. The comparison from Microsoft are based on the following criteria: Scale, Tenant isolation, Database cost per tenant, Performance monitoring and management, Development complexity and Operational complexity. The table of the comparison from Microsoft is pro-vided in Appendix A.
Usage in Study
The concept tenancy models and SaaS are essential to be able to understand this study. The concepts of Section 2.1, Section 2.2, Section 2.3 and Section 2.4 are general for this study, and will be used extensively. All databases that are used in the implementation of the tenancy models, is grouped together in an elastic pool. Furthermore, the performance of an elastic pool is measured in eDTU. The concepts of Section 2.5 and Section 2.6 are factors that could affect the result of the performance tests in this study; hence, it is important to understand the concepts to be able to analyse and discuss the results. The comparison from Microsoft in Section 2.7 was used in our comparison of tenancy models.
Table of contents :
1 Introduction
1.1 Background
1.2 Problem
1.3 Research Question
1.4 Purpose
1.5 Goal
1.6 Methodology
1.7 Stakeholders
1.8 Scope and Limitations
1.9 Outline
2 Technical Background
2.1 Introduction to Tenancy models & SaaS
2.2 Single Tenant Application, Single Database
2.3 Multi tenant Application, Database-per-tenant
2.4 Multi tenant Application, Sharded Database
2.5 Elastic Pools
2.6 eDTU
2.7 Microsoft’s Comparison
2.8 Usage in Study
3 Research Strategy
3.1 Research Methods
3.2 Research Phases
3.3 Research Instruments
3.4 Quality Assurance
3.5 Sampling Method
3.6 Experiences Gained
4 Work Process
4.1 Creation of TMSG
4.2 Implementation of Tenancy Models
4.3 Single tenant Application, Single Database
4.4 Multi tenant application, database-per-tenant
4.5 Multi Tenant Application, Sharded Database
4.6 Comparison
4.7 Load Testing
4.8 Evaluation of TMSG
4.9 Refinement of TMSG
5 Comparison Results
5.1 Isolation
5.2 Tenancy-cost
5.3 Performance
5.4 Development
5.5 Maintainability
5.6 Summary of Comparison
6 Model Results
6.1 Interview Results
6.2 Evaluation of Result
7 Discussion
7.1 Create TMSG
7.2 Implementation
7.3 Comparison
7.4 Evaluation of TMSG
7.5 TMSG Results
7.6 Quality Assurance
8 Conclusion
8.1 Recommendations for CRM Treasury systems AB
8.2 Applications
8.3 Future Work
