Composite SaaS Resource Management in Cloud Computing ... · Cloud computing is an emerging computing paradigm in which IT resources are provided over the Internet as a service to

Composite SaaS Resource Management

in Cloud Computing using

Evolutionary Computation

by

Zeratul Izzah Mohd Yusoh

MSc, University of Edinburgh

Supervisors:

Dr Maolin Tang (Principal)

Dr Ross Hayward (Associate)

A thesis submitted in partial fulfilment of the requirements

for the degree of

Doctor of Philosophy

Discipline of Electrical Engineering & Computer Science

Science and Engineering Faculty

Queensland University of Technology

Brisbane, Australia

April 2013

Keywords

Software as a Service, Cloud computing, evolutionary computation, geneticalgorithm, cooperative co-evolutionary algorithm, grouping genetic algorithm,optimisation, placement, clustering, scalability.

iii

Abstract

Cloud computing is an emerging computing paradigm in which IT resources

are provided over the Internet as a service to users. One such service o�ered

through the Cloud is Software as a Service or SaaS. SaaS can be delivered in

a composite form, consisting of a set of application and data components that

work together to deliver higher-level functional software.

SaaS is receiving substantial attention today from both software provi-

ders and users. It is also predicted to has positive future markets by analyst

�rms. This raises new challenges for SaaS providers managing SaaS, espe-

cially in large-scale data centres like Cloud. One of the challenges is providing

management of Cloud resources for SaaS which guarantees maintaining SaaS

performance while optimising resources use. Extensive research on the re-

source optimisation of Cloud service has not yet addressed the challenges of

managing resources for composite SaaS. This research addresses this gap by

focusing on three new problems of composite SaaS: placement, clustering and

scalability. The overall aim is to develop e�cient and scalable mechanisms

that facilitate the delivery of high performance composite SaaS for users while

optimising the resources used. All three problems are characterised as highly

constrained, large-scaled and complex combinatorial optimisation problems.

Therefore, evolutionary algorithms are adopted as the main technique in sol-

ving these problems.

The �rst research problem refers to how a composite SaaS is placed onto

Cloud servers to optimise its performance while satisfying the SaaS resource

and response time constraints. Existing research on this problem often ignores

the dependencies between components and considers placement of a homoge-

nous type of component only. A precise problem formulation of composite

SaaS placement problem is presented. A classical genetic algorithm and two

versions of cooperative co-evolutionary algorithms are designed to now manage

v

the placement of heterogeneous types of SaaS components together with their

dependencies, requirements and constraints. Experimental results demonstrate

the e�ciency and scalability of these new algorithms.

In the second problem, SaaS components are assumed to be already running

on Cloud virtual machines (VMs). However, due to the environment of a

Cloud, the current placement may need to be modi�ed. Existing techniques

focused mostly at the infrastructure level instead of the application level. This

research addressed the problem at the application level by clustering suitable

components to VMs to optimise the resource used and to maintain the SaaS

performance. Two versions of grouping genetic algorithms (GGAs) are de-

signed to cater for the structural group of a composite SaaS. The �rst GGA

used a repair-based method while the second used a penalty-based method

to handle the problem constraints. The experimental results con�rmed that

the GGAs always produced a better recon�guration placement plan compared

with a common heuristic for clustering problems.

The third research problem deals with the replication or deletion of SaaS

instances in coping with the SaaS workload. To determine a scaling plan that

can minimise the resource used and maintain the SaaS performance is a critical

task. Additionally, the problem consists of constraints and interdependency

between components, making solutions even more di�cult to �nd. A hybrid

genetic algorithm (HGA) was developed to solve this problem by exploring

the problem search space through its genetic operators and �tness function to

determine the SaaS scaling plan. The HGA also uses the problem's domain

knowledge to ensure that the solutions meet the problem's constraints and

achieve its objectives. The experimental results demonstrated that the HGA

constantly outperform a heuristic algorithm by achieving a low-cost scaling

and placement plan.

This research has identi�ed three signi�cant new problems for composite

SaaS in Cloud. Various types of evolutionary algorithms have also been deve-

loped in addressing the problems where these contribute to the evolutionary

computation �eld. The algorithms provide solutions for e�cient resource ma-

nagement of composite SaaS in Cloud that resulted to a low total cost of

ownership for users while guaranteeing the SaaS performance.

vi

Contents

Keywords iii

Abstract v

Contents vii

List of Tables xi

List of Figures xiii

List of Algorithms xvii

Nomenclature xix

Statement of Original Authorship xxi

Acknowledgements xxiii

1 Introduction 1

1.1 Research Background . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Research Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Motivating Example . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Research Problems . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.4.1 The Composite SaaS Placement Problem . . . . . . . . . 8

1.4.2 The Composite SaaS Clustering Problem . . . . . . . . . 9

1.4.3 The Composite SaaS Scalability Problem . . . . . . . . . 10

1.5 Research Contributions . . . . . . . . . . . . . . . . . . . . . . . 11

1.6 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

vii

CONTENTS

2 Background and Literature Review 15

2.1 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1 De�nition . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1.2 Service models . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.3 Deployment models . . . . . . . . . . . . . . . . . . . . . 21

2.1.4 Cloud Data Centre Model . . . . . . . . . . . . . . . . . 22

2.1.5 Cloud Virtualised Data Centre . . . . . . . . . . . . . . . 24

2.1.6 The Resource Management System in the Cloud . . . . . 26

2.2 Software as a Service . . . . . . . . . . . . . . . . . . . . . . . . 29

2.2.1 De�nition and characteristics . . . . . . . . . . . . . . . 29

2.2.2 Examples of SaaS . . . . . . . . . . . . . . . . . . . . . . 31

2.2.3 Composite SaaS . . . . . . . . . . . . . . . . . . . . . . . 36

2.2.4 Composite SaaS Application Model . . . . . . . . . . . . 38

2.3 Research Assumptions on Cloud and SaaS . . . . . . . . . . . . 41

2.4 Evolutionary Algorithms . . . . . . . . . . . . . . . . . . . . . . 42

2.4.1 Introduction of the Genetic Algorithm . . . . . . . . . . 42

2.4.2 Classical Genetic Algorithm Components . . . . . . . . . 44

2.4.3 Genetic Algorithm Variants . . . . . . . . . . . . . . . . 48

2.5 Summary & Conclusion . . . . . . . . . . . . . . . . . . . . . . 51

3 Evolutionary Algorithms for the Composite SaaS Placement

Problem 55

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.2 Problem Formulation . . . . . . . . . . . . . . . . . . . . . . . . 58

3.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.4 Evolutionary Algorithms . . . . . . . . . . . . . . . . . . . . . 65

3.4.1 Determining the SaaS Total Execution Time . . . . . . 65

3.4.2 A Classical Genetic Algorithm . . . . . . . . . . . . . . . 68

3.4.3 A Cooperative Co-evolutionary Algorithm . . . . . . . . 73

3.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.5.1 Test Problems . . . . . . . . . . . . . . . . . . . . . . . 82

3.5.2 A Hill Climbing Heuristic Algorithm . . . . . . . . . . . 84

3.5.3 Experimental Results . . . . . . . . . . . . . . . . . . . 85

3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

viii

CONTENTS

4 Grouping Genetic Algorithms for the Composite SaaS Clus-

tering Problem 95

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96


4.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4.4 Grouping Genetic Algorithms . . . . . . . . . . . . . . . . . . . 105

4.4.1 A Repair-based Grouping Genetic Algorithm . . . . . . 105

4.4.2 A Penalty-based Grouping Genetic Algorithm . . . . . . 112

4.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

4.5.1 Test Problems . . . . . . . . . . . . . . . . . . . . . . . 115

4.5.2 A First Fit Decreasing Algorithm . . . . . . . . . . . . . 116

4.5.3 Experimental Results . . . . . . . . . . . . . . . . . . . 118

4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

5 A Hybrid GA for the Composite SaaS Scalability Problem 129

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129


5.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

5.4 A Hybrid Genetic Algorithm . . . . . . . . . . . . . . . . . . . 142

5.4.1 Genetic Operators . . . . . . . . . . . . . . . . . . . . . 148

5.4.2 Fitness Function . . . . . . . . . . . . . . . . . . . . . . 149

5.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

5.5.1 Evaluation of methods in determining the upper boun-

dary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

5.5.2 Evaluation of the performance and the scalability of the

HGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

6 Conclusion 171

6.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

6.2 Major Contributions . . . . . . . . . . . . . . . . . . . . . . . . 173

6.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

A List of Publications 179

Bibliography 181

ix

List of Tables

2.1 Main services of Cloud computing . . . . . . . . . . . . . . . . . 19

2.2 Characteristics of conventional software, ASP and SaaS ap-

proaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3 Characteristics of conventional software, ASP and SaaS ap-

proaches (continue) . . . . . . . . . . . . . . . . . . . . . . . . 33

2.4 Advantages of SaaS . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1 Test problems with di�erent numbers of Cloud servers . . . . . . 83

3.2 Test problems with di�erent numbers of SaaS components . . . 84

3.3 Simulation parameters for the CGA, iterative CCEA and paral-

lel CCEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

3.4 Experimental results of the hill climbing (HC), classic GA (CGA),

iterative CCEA and parallel CCEA for test problems with dif-

ferent numbers of Cloud servers . . . . . . . . . . . . . . . . . . 87

3.5 Experimental results of the hill climbing (HC), classic GA (CGA),

iterative CCEA and parallel CCEA for test problems with dif-

ferent numbers of SaaS components . . . . . . . . . . . . . . . 90


4.2 Test problems with di�erent numbers of composite SaaS . . . . 117

4.3 Simulation parameters for the GGAs . . . . . . . . . . . . . . . 120

4.4 Experimental results of the PGGA, RGGA and FFD for test

problems with di�erent numbers of VMs . . . . . . . . . . . . . 121

4.5 Experimental results of the PGGA, RGGA and FFD for test

problems with di�erent numbers of composite SaaS . . . . . . . 124

5.1 Test problems and upper boundary values for HGA(F) and

HGA(R) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

xi

LIST OF TABLES

5.2 Comparison results of the HGA(F) and HGA(R) . . . . . . . . . 153


5.4 Test problems with di�erent numbers of tenants . . . . . . . . . 155

5.5 Test problems with di�erent numbers of application components 155

5.6 Simulation parameters for the experiments . . . . . . . . . . . . 157

5.7 Experimental results of the HGA and greedy algorithm for test

problems with di�erent numbers of Cloud servers . . . . . . . . 159


problems with di�erent numbers of tenants . . . . . . . . . . . 162


problems with di�erent numbers of SaaS application compo-

nents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

xii

List of Figures

1.1 Main roles in SaaS scenarios [108] . . . . . . . . . . . . . . . . . 2

1.2 An example of a simple Customer Relationship Management

(CRM) SaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 The research problems' tasks . . . . . . . . . . . . . . . . . . . . 9

2.1 Cloud service architecture layer . . . . . . . . . . . . . . . . . . 20

2.2 The high-level architecture of a Cloud data centre . . . . . . . . 26

2.3 Modules in Cloud resource management system . . . . . . . . . 27

2.4 Microsoft's SaaS maturity model . . . . . . . . . . . . . . . . . 38

2.5 A general SaaS maturity model [87] . . . . . . . . . . . . . . . . 39

2.6 Composite SaaS application model in Cloud infrastructure . . . 41

2.7 The basic processes of classical GA . . . . . . . . . . . . . . . . 44

2.8 Roulette wheel selection procedure . . . . . . . . . . . . . . . . 46

2.9 One-point crossover operation . . . . . . . . . . . . . . . . . . . 47

2.10 One-point mutation operation . . . . . . . . . . . . . . . . . . . 47

2.11 Coevolutionary model with three species [117] . . . . . . . . . . 49

3.1 An example of a composite SaaS with two work�ows . . . . . . 67

3.2 An example of a supergraph for a composite SaaS . . . . . . . . 68

3.3 An example of gene and chromosome encoding scheme . . . . . 70

3.4 An example of the crossover procedure . . . . . . . . . . . . . . 71

3.5 An example of the mutation procedure . . . . . . . . . . . . . . 72

3.6 An example of chromosome for subpopulation 1 and 2 . . . . . . 74

3.7 Parallel CCEA model . . . . . . . . . . . . . . . . . . . . . . . . 79

3.8 An example of composite SaaS with �ve application and data

components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

xiii

LIST OF FIGURES

3.9 Comparison of the total execution time (TET) of the SaaS with

di�erent numbers of Cloud servers for parallel CCEA, iterative

CCEA, CGA and hill climbing . . . . . . . . . . . . . . . . . . 88

3.10 The e�ect of the total number of Cloud servers on computation

time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

3.11 Comparison of the total execution time (TET) with di�erent

numbers of SaaS components for parallel CCEA, iterative CCEA,

CGA and hill climbing . . . . . . . . . . . . . . . . . . . . . . . 91

3.12 The e�ect of the number of SaaS components on computation

time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.1 A high level scenario of clustering SaaS components . . . . . . . 97

4.2 An example of RGGA chromosome encoding scheme with q

composite SaaS with a di�erent number of components. . . . . . 107

4.3 An example of inter-group crossover operation among composite

SaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

4.4 An example of inner-group mutation operation within a SaaS . . 109

4.5 An example of three composite SaaS with di�erent numbers of

application components and data components . . . . . . . . . . 117

4.6 Comparison of the VM cost of PGGA, RGGA and the FFD for

di�erent numbers of VMs . . . . . . . . . . . . . . . . . . . . . 122

4.7 Comparison of the migration cost of PGGA, RGGA and the

FFD for di�erent numbers of VMs . . . . . . . . . . . . . . . . 122

4.8 The e�ect of the number of VMs on computation time . . . . . 123

4.9 Comparison of the VM cost of PGGA, RGGA and the FFD for

di�erent numbers of composite SaaS . . . . . . . . . . . . . . . 125

4.10 Comparison of the migration cost of PGGA, RGGA and the

FFD for di�erent numbers of composite SaaS . . . . . . . . . . 126

4.11 The e�ect of the number of composite SaaS on computation time 126

5.1 An example of scalability rules at the application level [123] . . 132

5.2 An example of a chromosome representation . . . . . . . . . . . 143

5.3 An example of crossover procedure . . . . . . . . . . . . . . . . 149

5.4 An example of mutation procedure . . . . . . . . . . . . . . . . 149

5.5 The computation times for HGA(F) and HGA(R) . . . . . . . . 153

xiv

LIST OF FIGURES

5.6 A composite SaaS with ten application components and �ve

data components . . . . . . . . . . . . . . . . . . . . . . . . . . 156

5.7 Comparison of the overall objective function, F (X), of the HGA

and the greedy algorithm for di�erent numbers of Cloud com-

putation servers . . . . . . . . . . . . . . . . . . . . . . . . . . 160

5.8 Comparison of the computation time of the HGA and the greedy

algorithm for di�erent numbers of Cloud computation servers . 161


and the greedy algorithm for di�erent numbers of tenants . . . 163

5.10 Comparison of the number of replica created of the HGA and

the greedy algorithm for di�erent numbers of tenant . . . . . . 164

5.11 Comparison of the execution time of the HGA and the greedy

algorithm for di�erent numbers of tenant . . . . . . . . . . . . 164


and the greedy algorithm for di�erent numbers of SaaS appli-

cation components . . . . . . . . . . . . . . . . . . . . . . . . . 165

5.13 Comparison of the number of replica created of the HGA and

the greedy algorithm for di�erent numbers of SaaS application

components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

5.14 Comparison of the execution time of the HGA and the greedy

algorithm for di�erent numbers of SaaS application components 168

xv

List of Algorithms

1 The classical genetic algorithm (CGA) . . . . . . . . . . . . . . 69

2 The iterative CCEA . . . . . . . . . . . . . . . . . . . . . . . . . 78

3 The placement of the the application components subproblem in

parallel CCEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4 The placement of the data components subproblem in parallel

CCEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5 The parallel CCEA . . . . . . . . . . . . . . . . . . . . . . . . . 81

6 The hill climbing algorithm . . . . . . . . . . . . . . . . . . . . . 85

7 The repair-based grouping genetic algorithm (RGGA) . . . . . . 107

8 The repair procedure for RGGA . . . . . . . . . . . . . . . . . . 108

9 The penalty-based grouping genetic algorithm (PGGA) . . . . . 113

10 The �rst �t decreasing heuristic algorithm . . . . . . . . . . . . 119

11 The hybrid genetic algorithm (HGA) . . . . . . . . . . . . . . . 144

12 The random replication algorithm . . . . . . . . . . . . . . . . . 146

13 The initialisation procedure . . . . . . . . . . . . . . . . . . . . 146

14 The placement procedure . . . . . . . . . . . . . . . . . . . . . . 147

15 The greedy algorithm . . . . . . . . . . . . . . . . . . . . . . . . 157

xvii

Nomenclature

Abbreviations/Acronyms

ASP Application service provider

BPP Bin packing problem

CCEA Cooperative co-evolutionary algorithm

CGA Classical genetic algorithm

CPP Component placement problem

CRM Customer relationship management

CS Computation server

DE Di�erential evolution

EA Evolutionary algorithm

EP Evolutionary programming

FFD First �t decreasing

GA Genetic algorithm

HaaS Hardware as a Service

HGA Hybrid genetic algorithm

IaaS Infrastructure as a Service

IT Information technology

NAS Network-attached storage

NP Non-polynomial

PaaS Platform as a Service

PGGA Penalty-based grouping genetic algorithm

QoS Quality of services

RGGA Repair-based grouping genetic algorithm

RMS Resource management system

RWS Roulette wheel selection

xix

LIST OF ALGORITHMS

SaaS Software as a Service

SAN Storage-area network

SLA Service level agreement

SoA Service oriented architecture

SPP SaaS placement problem

SS Storage server

TAP Task assignment problem

VEE Virtual execution environment

VEEM Virtual execution environment manager

VM Virtual machine

xx

Acknowledgements

I would like to express my utmost appreciation to those who have helped

throughout the completion of this thesis.

To my supervisor, Dr Maolin Tang, I would like to express my profound

gratitude for his invaluable support, continuous supervision, and greatly ap-

preciated motivation during my Doctoral study. I am really grateful for his

patience and encouragement. His guidance has played a vital role in my acade-

mic, professional and personal development and I am very lucky to have had

the opportunity to work with him. I would also like to thank my associate

supervisor, Dr Ross Hayward, for his guidance and support throughout my

PhD study.

I sincerely acknowledge the PhD scholarship from the Ministry of Higher

Education of Malaysia and Universiti Teknikal Malaysia Melaka, and also the

funding from CRC Smart Services, Australia.

Special thanks go to my parents and family members, who have been my

source of motivation. This achievement would never have been possible wi-

thout their love and support. Last but not least, I would like to thank all my

friends, who have stood by me through thick and thin over the years.

Thank you.

xxiii

Chapter 1

Introduction

This chapter contains a brief background of the research, the motivation, the

research problems, and the major contributions made. The chapter ends with

the organisation of the thesis.

1.1 Research Background

Nowadays, the demand for computation technologies or `computer utilities'

has increased to the point where it has resulted in the transformation of the

computation industry in the twenty-�rst century. As a result, Cloud computing

[47] has emerged, o�ering users o�-premises high performance IT facilities,

including applications, data and computation resources. Cloud computing

services can be categorised into three main categories: 1) Infrastructure as a

Service (IaaS), which o�ers computing infrastructure as a solution to users'

computing and storage problems [47], 2) Platform as a Service (PaaS), which

is targeted at application developers for their applications, thereby allowing

them to design, develop, deploy and test activities in Cloud platforms [112],

and 3) Software as a Service (SaaS), which o�ers an alternative for locally

installed software [137]. This research focuses on SaaS as the problem domain.

SaaS has received considerable attention from software providers as well

as from software users. Users' demand for SaaS is increasing each year [22]:

Dubey and Wagle [37] reported that within three years companies that have

provided SaaS could generate up to an 18% increase in revenue. Other analyst

�rms have also reported the positive growth of SaaS, including the IDC, which

stated that the worldwide revenue for SaaS was $13.1 billion in 2009, and

1

CHAPTER 1. INTRODUCTION

Figure 1.1: Main roles in SaaS scenarios [108]

that it would reach $40.5 billion in 2014 [32], and Gartner forecast that the

revenue would reach $22 billion by 2015 [68]. These reports are evidence

that SaaS has become a signi�cant service to users, leading to challenges in

providing a better SaaS to meet these demands. In addition, advances in Cloud

computing infrastructure have provided an e�cient means for SaaS hosting,

thereby making SaaS more accessible to a wide range of software users.

Gartner [67] de�ned �ve main roles in a SaaS environment: 1) SaaS plat-

form provider, 2) SaaS application vendor, 3) SaaS infrastructure provider,

4) SaaS users (organisations), and 5) SaaS user (individual). Mietzner and

Leymann [108] simpli�ed these roles by combining the SaaS platform and

SaaS infrastructure provider as the SaaS provider, and the two user cate-

gories mentioned by Gartner as the SaaS user. Figure 1.1 shows the roles in

a SaaS scenario according to Mietzner and Leymann who further stated that

the SaaS application vendor and SaaS provider can be included in the same

entity. Based on these de�ned roles, it can be seen that the task of managing

the SaaS comes under the responsibility of SaaS providers: they o�er facilities

to host and manage the SaaS platform as well as o�ering the SaaS itself. As

SaaS is predicted to have a high demand in the future, there is a range of chal-

lenges for SaaS providers to deliver their SaaS reliably and e�ciently. One of

the challenges is the management of Cloud resources for SaaS use [19][42][47],

which needs to be done e�ciently to guarantee that the performance of the

SaaS is maintained while keeping a low total cost of ownership for users. This

is achieved by optimisation of the resources used for the SaaS through the

management of SaaS resources. In a Cloud data centre, this process is often

automated and handled by a resource management system (RMS).

A RMS can be referred to as a common management layer that �exibly

controls the deployment and maintenance of the Cloud services in the sha-

2

1.2. Research Motivation

red resources. The main responsibility of the RMS is to provide automated

management of the Cloud resources based on the objectives set by the pro-

viders [48]. For SaaS management, the RMS has to handle the life cycle of

the SaaS for hundreds or thousands of users: this includes automating the

placement of a SaaS, managing the resource in the dynamic environment of a

Cloud and providing continuous optimisation of the resources. These activities

can be carried out during the maintenance phase of the RMS, which occurs at

di�erent timescales, from seconds to days, in which the timescales are based

on the maintenance activities. In general, there are three maintenance time

scales in the RMS [25][146]: 1) the long time scale (hours to day) for place-

ment, migration and upgrading activities, 2) the medium time scale (minutes),

for adjustment of workloads or placement of the service, and 3) the short time

scale (seconds) to dynamically adjust the workloads or placement to satisfy the

increasing requests of the service. The long and medium timescales are usually

done as an o�ine maintenance task, while the short timescale is conducted as

an online maintenance task.

This research aims to address the SaaS provider's challenges in delivering

SaaS by developing an e�cient SaaS resource management system that can

handle activities relating to the life cycle of the SaaS. The overall goal of

this research is to optimise the resources used by the SaaS in a Cloud without

comprising the SaaS performance. The optimisation process focuses on several

identi�ed problems in the maintenance activities of the SaaS life cycle where

these activities are carried out in o�ine maintenance phases of SaaS targeting

at medium to long maintenance timescales. Since these activities deal with

large data centres with a variety of service applications, a set of evolutionary

algorithms is proposed to tackle the problems. The next section will further

elaborate on the research motivation and gap, as well as on the problems of

this research.

1.2 Research Motivation

A SaaS can be delivered as a composite application in which the software is

composed from a group of loosely coupled individual applications that com-

municate with each other in order to form a higher-level functional system or

application [65]. An example of a composite SaaS is the Fujitsu's SaaS [127].

3


Fujitsu is a provider of ICT-based business solutions with branches in more

than 70 countries and its headquarters in Japan. There are two types of SaaS

for the company's private use: a general SaaS for customer relationship ma-

nagement (CRM) task, and business SaaS for the administrative tasks. Both

SaaS consist of several modules that have interdependency with one another.

These modules share data components too. Another example is a commer-

cial composite SaaS � Salesforce Customer Relationship Management (CRM)

[126]. The SaaS is o�ered to user in �ve incremental levels. The �rst level

consists of basic functions of the software, while the highest level consist of

higher functionalities of the SaaS. Users can select and customise the levels

based on their needs.

Delivering the SaaS in such an approach allows �exibility of the SaaS func-

tionalities, where components can be combined and recombined as needed. In

addition, SaaS providers can gain a number of bene�ts including reduced deli-

very cost, �exible o�ers of the SaaS functions and decreased cost of subscrip-

tion for users. However, this type of delivery also raises several new challenges

concerning the management of resources in a Cloud data centre. First, the

performance of a composite SaaS is greatly in�uenced by how its components

work with each other. This is especially true in a large-scale distributed data

centre like a Cloud data centre, in which the communications between com-

ponents need to be handled e�ciently for delivering a high-quality composite

SaaS application. Second, a composite SaaS may consist of di�erent types of

component (i.e. application and data components) where these components

have di�erent resource requirements and constraints of their own. The compo-

nents' competing requirements, as well as their constraints, need to be handled

e�ciently to avoid poor performance of the SaaS and resource wastage. Third,

the service level agreement (SLA) of a composite SaaS is achieved based on a

set of components rather than on a single atomic component. As such, each

of the components involved needs to be managed correctly to ensure the �nal

result meets the agreed SLA. Therefore, the main issue is how to manage

a composite SaaS in a Cloud, in terms of the interdependency between the

components as well as its constraints, such that the delivered functionality

of the SaaS not only meets its performance requirement, but also optimises

the resources of the infrastructure providers which in turn can lower the total

resource usage of the SaaS as well as the total cost of ownership for the users.

4

1.3. Motivating Example

A considerable amount of literature has been published that addresses the

challenges of resource management in a Cloud. However, most works proposed

solutions catering for an atomic SaaS, thus ignoring the new challenges noted

above. In addition, the solutions are mainly developed at the infrastructure

level for IaaS management, whilst this research focuses on solutions at the

application level to handle the composite SaaS. Among the many management

processes that are handled in the resource management system, this research

focuses on three speci�c problems that are chosen based on their impact on

the overall performance of a composite SaaS in a Cloud. The problems are 1)

the SaaS initial placement problem, 2) the clustering of the SaaS components

problem, and 3) the scaling of the SaaS components problem. Section 1.3

provides a motivating example for the problems. The overall aim is to develop

e�cient and scalable mechanisms to facilitate the delivery of high performance

composite SaaS for users while optimising the resources used.

From the computational point of view, the above problems can be trans-

formed into diverse optimisation problems. This is due to the size of the

problem, its constraints, and its optimisation objectives. It is conjectured that

all the problems above are NP-hard [83][84][91][102], requiring an e�cient me-

chanism to obtain satisfactory or sub-optimal solutions. This research explores

the use of the evolutionary algorithm (EA) to address the problems' challenges.

EA is a stochastic search method that applies the process of biological evo-

lution in producing the solutions [51]. EAs have been successfully applied in

many problems characterised as complex, large-scale, constrained and opti-

misational in many domains including business, engineering and science [23].

This is the main reason EA was chosen to solve the problems.

1.3 Motivating Example

This section presents a motivating example for the three research problems out-

lined above. A simple example of a composite SaaS based on Salesforce CRM

[126] is considered. Figure 1.2 illustrates the composite SaaS for this example,

in which the SaaS is composed of three application components labelled as ac1

to ac3, and three data components labelled as dc1 to dc3.

A component is a processing entity that encapsulates a set of application

functionality or data [65][97] in which the former is referred as an application

5


Figure 1.2: An example of a simple Customer Relationship Management (CRM)SaaS

component, while the latter as a data component. Based on the Figure 1.2,

application components are represented in circles � the Sales & Marketing

module, Sales Forecasting module and Business Analysis Tools module. The

data components are in squares � Clients data, Sales data and Results data.

Each of the SaaS components has its own resource requirements, including

resources for processing, memory and storage. These components present the

elasticity of a composite SaaS in which the SaaS providers can o�er the SaaS

based on these modules and users can subscribe to as much or as little of the

service as they need. In the above example, a user can either subscribe to the

Sales & Marketing module only (with its corresponding data components) in

order to have a basic SaaS CRM, or subscribe to all the components to have

SaaS functions at a higher-level.

The components in a SaaS may have interdependencies with each other

in order to form a higher-level SaaS functions. These interdependencies are

depicted using a directed link from one component to another in which the

link indicates the inter-component communications. These links also represent

the work�ow of the SaaS. The work�ow shows an execution �ow of the SaaS

components in response to the user's subscription. For example, in response

to users that subscribe to all components, the execution work�ow for the SaaS

above consists of two paths: ac1 → ac2 and ac1 → ac3. Further elaboration of

the work�ow of the SaaS can be found in Chapter 3.

This research considered the problems represented in three scenarios of

composite SaaS management in Cloud. The �rst scenario considered is the

placement problem of a composite SaaS. At the initial deployment of SaaS

onto Cloud infrastructure, the application and data components have to be

placed onto the Cloud computation servers and storage servers respectively.

6

1.3. Motivating Example

The placement is done automatically, initiated by the Cloud provider through

the Cloud resource management system. The placement decision is subject

to the resource capacity of particular servers and the resource requirements of

the components, in such a way that the total execution time of the composite

SaaS is minimised. Based on the example above, all application components

are to be placed onto Cloud computation servers, and the data components

onto the storage servers. The estimated total execution time of the composite

SaaS is calculated based on the execution time of a single component and the

communication time between the components.

The second scenario under consideration occurs after the SaaS has been

executed for a period of time. As the workload of each component of the SaaS

and the resource capacities of the servers keep changing over time, the current

placement of the components may need to be recon�gured. This is to ensure

that the resources used are optimised while maintaining the performance of the

SaaS. Lets consider ac1 has a higher request compared to other components as

it is the basic component of the SaaS. Therefore, a server with a high resource

capacity might be needed in hosting the component. Additionally, especially

for composite SaaS, components with dense communication should be clustered

together in order to save the communication cost as well as to improve the SaaS

overall performance. This research studies this clustering approach in order to

recon�gure the current placement of the SaaS components.

Apart from the placement recon�guration, to cope with the dynamic load

of the SaaS, components may need to be replicated or deleted. More spe-

ci�cally, the following scenario is considered. Each of the SaaS components

serves a number of users, with Sales & Marketing module (ac1) and the Sales

Forecasting (ac2) having the same number of users, and the Business Analysis

Tools (ac3) module having less users than the other two. It is assumed that

all components have only one instance deployed in the Cloud during its initial

placement. To maintain the performance of SaaS, these components may need

to be replicated such that the workload of the component can be distributed.

Although ac1 and ac2 has the same number of users, replication may not be

necessary for both components as other factors should be also considered in

the replication decision, including the interdependencies between components,

the total resource requirements, the server's capacities and the components'

constraints. These factors contribute to the complexity of the replication deci-

7


sion. On the other hand, when the number of users is decreasing, the replicas

may need to be deleted as well. This is referred to as the scalability problem

of the SaaS. This research studies this problem to determine which component

should be scaled and where to place the new replica.

All management processes to address the scenarios above are conducted in

an o�ine mode in which the processes will be triggered during a maintenance

phase scheduled by the Cloud provider. The whole Cloud data centre is consi-

dered which includes all the computation servers with its virtual machines,

the storage servers and the network link between the servers. The following

section describes each of these problems in details.

1.4 Research Problems

As mentioned in the previous section, this research focuses on three problems

of composite SaaS resource management in a Cloud. In each problem, a set

of tasks will be carried out that will change the current status of the SaaS.

Figure 1.3 shows the order and dependencies of the tasks. The arrows indicate

that the output of a task is used as input for the receiving task.

In a SaaS lifecycle, the placement task will occur �rst. This activity is

carried out during the initial phase of the SaaS deployment onto the Cloud.

Then, based on this placement, the performance of the SaaS, as well as the

data centre's need, the clustering tasks and the scaling process, are triggered

to optimise the Cloud resources. Either of these two tasks can occur �rst, and

the outcome of the other tasks will be used as the input for another.

1.4.1 The Composite SaaS Placement Problem

A composite SaaS deployed in a Cloud is composed of several application com-

ponents and data components, each of which represents a business function of

the SaaS that is being delivered [93]. For SaaS placement in the Cloud, the

problem relates to where a composite SaaS should be placed in a Cloud data

centre, such that its performance is optimal based on its estimated execution

time. The challenges in the SaaS placement process rely on several factors,

including SaaS interactions between its components, SaaS competing resource

requirements, and the overall evaluation of the SaaS. Existing application pla-

8

1.4. Research Problems

Figure 1.3: The research problems' tasks

cement methods were not designed for the placement of composite applications.

The methods focus mostly on the resource consumption by the components

and are not concerned with the placement of the di�erent types of components

or their dependency. A formal problem statement of the problem is presented:

Given a set of computation servers with their capacities and virtual

machines, storage servers with their storage capacities, the Cloud

communication network, and the composite SaaS with its requi-

rements and work�ows, how to determine the placement of each

SaaS application components onto the servers (virtual machines)

and each SaaS data components onto the storage servers such that

the performance of the SaaS is optimal based on its total execution

time while satisfying the resource requirement and response time

constraints.

The placement problem is proven to be an NP problem [84][91]. This research

investigates how to apply evolutionary algorithms to address the problem.

A special characteristic of this problem is that it consists of two types of

interconnected placement process. Therefore, special emphasis will be given

to designing algorithms that can handle multi-computation sub-problems and

their connection, and at the same time satisfy the problem's constraints.

1.4.2 The Composite SaaS Clustering Problem

Due to the dynamic environment of a Cloud data centre, where the workload

of applications and resource capacities keep changing over time, resources that

have been initially allocated to SaaS components may be overloaded or under-

utilised. A typical data centre usually schedules a placement recon�guration

of the components to optimise the resources used. The placement recon�-

guration for composite SaaS can be done by clustering suitable components

9


together and modifying the component's initial location such that the new

placement can minimise the resources used while satisfying the SaaS SLA.

This activity occurs at a certain period of time based on the data centre's

needs. Di�erent approaches can be taken at di�erent periods of time, and it

can be done either dynamically or statically. The approach proposed in this

research is to deal with the dynamic environment at a static point in time,

where all composite SaaS deployed in the data centre will be considered. A

formal problem statement of the problem is presented as:

Given a set of computation servers with virtual machines and their

capacities, storage servers with their storage capacities, the Cloud

communication network, and all composite SaaS that are deployed

in the Cloud data centre with their requirements, constraints and

current placements, how to recon�gure the current placement of

the SaaS application component using clustering approach, such

that the cluster and the new placement will minimise the cost of

resources used while maintaining the SaaS performance and com-

plying with its resource requirements, placement and response time

constraints.

The problem is de�ned as a large-scale and combinatorial optimisation prob-

lem with constraints. In addition, the main approach of the problem is to

cluster the SaaS components. Based on these criteria, grouping genetic algo-

rithms with constraints-handling techniques are proposed. The algorithms are

designed to explore the possible combinations of cluster within groups of SaaS,

while complying with the constraints of the SaaS and the VMs.

1.4.3 The Composite SaaS Scalability Problem

A composite SaaS may have multiple instances if a single instance cannot

accommodate the user's load. The process of generating a new instance is

referred to as SaaS replication. In replicating a composite SaaS, it may not be

necessary to replicate all components of the SaaS, as some components might

have lower loads and can be shared by other copies. On the other hand, when

the load is low, some of the SaaS instances may need to be deleted to avoid

resource underutilisation. Thus, it is important to determine which component

is to be replicated and where it is to be placed it such that the performance of

10

1.5. Research Contributions

the SaaS is maintained while the resource used is minimised. A formal problem

statement of the problem is presented as:

Given the Cloud servers with their capacities, Cloud network, SaaS

current placement, and the current load of SaaS in term of its re-

quirements and tenants, how to determine the minimum number

of replica for each components as well as the placement of the new

replicas, such that the overall performance of SaaS complies with

its constraints, whilst the overall resources used by the SaaS is mi-

nimised.

The above problem have been proven as an NP-hard [83][102]. In addition, for

a composite SaaS, the complex constraints on interdependencies between the

components may make �nding the solutions even more di�cult. Therefore,

a hybrid genetic algorithm is proposed in order to �nd feasible replication

solutions. The algorithm is designed to utilise the problem domain knowledge

in determining the number of replicas and the placement. In addition, the

algorithm is also designed to explore the best combination of replication plan

for each component, without having to rely on the trigger rules, such that the

overall performance of the SaaS can be maintained.

1.5 Research Contributions

The original contributions of this research lie in the area of evolutionary com-

putation for solving optimisation problems for composite SaaS and in that of

the advancement of SaaS resource management system in Cloud computing.

The major contributions are outlined as follows:

1. The �rst contribution of this thesis is the identi�cation of three new

signi�cant problems of composite SaaS resource management. As SaaS

is predicted to have increasing demands each year, it is an important task

for the providers to deliver the service e�ciently with a low total cost

of ownership to users. However, existing research has not addressed the

challenges arising from the management of composite SaaS. This research

de�ned three important resource management problems of composite

SaaS in Cloud as listed below:

11


• The composite SaaS placement problem � this problem consists of

two new criteria that existing research did not address: 1) the place-

ment of di�erent types of component onto heterogeneous servers,

and 2) the interdependencies between the components that contri-

buted to the overall performance of the SaaS. These criteria have

been precisely formulated and presented in this thesis.

• The composite SaaS clustering problem � the clustering of SaaS

components has to consider the SaaS constraints at the infrastruc-

ture level as well as application level. The latter is often ignored by

existing research. This study provides a new problem model that

addresses this gap.

• The composite SaaS scalability problem � a comprehensive problem

formulation that de�nes scalability process tailored to a composite

SaaS is presented. This formulation includes three new important

elements in the composite SaaS application scalability problem: 1)

the scale granularity in component-based application, 2) the se-

lection of the component for scale, and 3) the placement of the

components' replicas.

2. The second contribution is the applicability of di�erent kinds of evo-

lutionary algorithms to new problems, characterised as large-scale and

complex combinatorial optimisation problems. The contribution is ela-

borated based on the research problems, as follows:

• The contribution from the algorithms in the �rst problem is in the

area of large-scale problems with multiple numbers of design va-

riables. A classical genetic algorithm (CGA) is developed which

exhibits slow convergence and long computation time. To deal with

this problem, a cooperative co-evolutionary algorithm (CCEA) is

proposed. The CCEA divided the problem into a number of sub-

problems based on the variables. Two versions of CCEA are de-

veloped: iterative and parallel. These two versions demonstrated

that di�erent behaviours of the algorithm produce di�erent perfor-

mances. Based on the experimental results, the parallel CCEA

shows outstanding results for solving large-scale problems, com-

pared to the iterative CCEA, the CGA and the heuristic algorithm.

12

1.6. Thesis Outline

• In the second problem, the main contribution is towards developing

a suitable constraint handling method for the composite SaaS clus-

tering problem. Two constraint handling methods are proposed �

the repair-based method and the penalty-based method. The proce-

dures of each method are discussed and their abilities are explored.

Both methods are implemented separately in two grouping genetic

algorithms (GGA) where the GGA is chosen because of its ability

to handle the structure of composite SaaS.

• The contribution in the third problem is a development of a hybrid

genetic algorithm (GA) for solving the composite SaaS scalability

problem. The ability of the classical GA is enhanced by manipu-

lating the problem-domain knowledge in the scaling process. It is

shown that the modi�ed algorithm not only performs well in terms

of achieving optimal solutions, but also demonstrates good scalabi-

lity.

3. The outcomes of this research can bene�t entities that are involved in

composite SaaS resource management, including Cloud providers, SaaS

vendors and SaaS users. The algorithm can be implemented in the Cloud

resource management system to provide e�cient management of compo-

site SaaS. Through the proposed algorithms, the resource usage for the

SaaS is optimised without comprising its performance. This leads to

lower running costs of the SaaS as well as to a low total cost of owner-

ship for the users.

4. Finally, this research enriched the knowledge-base of Cloud by providing

comprehensive explanation and discussion of the composite SaaS.

1.6 Thesis Outline

This thesis is organised as follows:

• Chapter 2 describes the background information necessary to provide

the context for the subsequent chapters. The information includes the

foundation of Cloud computing, SaaS, and evolutionary algorithms. This

chapter also presents the assumption of the research.

13


• Chapter 3 studies the composite SaaS placement onto a Cloud data

centre. This chapter introduces a formal description of this new problem.

Two evolutionary algorithms are then proposed to address the problem: a

classical genetic algorithm and a cooperative co-evolutionary algorithm.

The major feature of both algorithms is the way they handle the pla-

cement of heterogeneous types of component. In addition, the coope-

rative co-evolutionary algorithm is developed in two models � iterative

and parallel. The experimental results show that the parallel model has

produced impressive solutions with good scalability.

• Chapter 4 investigates the composite SaaS clustering problem in order

to optimise the resources in a dynamic Cloud environment. The objec-

tive of the problem in this chapter is to minimise the current resource

usage by the SaaS components by recon�guring their original placement

using the clustering approach. The problem has a number of constraints

that the solutions need to comply with. Two grouping genetic algorithms

(GGAs) that apply di�erent constraint handling techniques are presen-

ted. The �rst GGA uses a repair-based approach, while the second one

uses a penalty-based approach. Both algorithms are compared with a

�rst-�t decreasing heuristic in order to evaluate their performance and

scalability.

• Chapter 5 proposes a hybrid genetic algorithm for the composite SaaS

scalability problem. The chapter begins with an introduction of Cloud

scalability features, and is followed by a review of existing work in re-

lated areas. The problem is formulated and described. The solution is

presented as an algorithm that handles the scaling and placement pro-

cess speci�c to composite SaaS features and needs. In order to evaluate

the performance of the proposed algorithm, it is compared with a greedy

algorithm.

• Chapter 6 presents conclusions about the work presented in this thesis.

In addition, some future directions for the research are proposed.

14

Chapter 2

Background and Literature

Review

This chapter provides the background information necessary as the founda-

tion for subsequent chapters and the research assumptions used in this thesis.

Section 2.1 discusses the fundamental concepts of Cloud computing, Section

2.2 describes the Software as a Service in details and Section 2.4 present the

evolutionary algorithm concept. Section 2.3 discusses the assumptions made

in this research and Section 2.5 provides the summary and concluding remarks

of the chapter.

2.1 Cloud Computing

Cloud computing is becoming increasingly popular among Information Tech-

nology (IT) practitioners and IT providers. The term was coined by Google

CEO Eric Schmidt, who in late 2006 used the term to describe the Google

approach for Software as a Service [8]. A study by International Data Cor-

poration, a leading IT analysis �rm, identi�ed Cloud computing as one of the

prevailing technology trends in the new decade [17]. Other research by Merrill

Lynch, a global �nancial services �rm, predicted that Cloud providers would

gain huge revenues from the Cloud's services and advertising [19]. In addi-

tion, research conducted in the United Kingdom (UK) indicates that there is a

high interest in Cloud-based services usage in public and private organisations

in the UK [31]. These predictions and demands have led to many studies of

15

CHAPTER 2. BACKGROUND AND LITERATURE REVIEW

Cloud computing. The following sections will discuss the fundamental concept

of Cloud computing relevant to this research.

2.1.1 De�nition

Since the emergence of Cloud computing, many de�nitions of the term have

been published. Although there is no exact or standard de�nition for the

term, most of the de�nitions share some similar characteristics that describe

the Cloud computing concept. These can be used as a basis from which to

de�ne Cloud computing in this research context.

Foster et al. [47] de�ned Cloud computing as a specialised distributed

computing infrastructure with four main characteristics: 1) it is massively sca-

lable, 2) it is an abstract entity that delivers di�erent levels of services to users,

3) it is driven by economies of scale, and 4) its services can be dynamically

con�gured. Cloud services outlined in Foster et al.'s work include computing

infrastructure, platform for development as well as software and application.

These services will be discussed further in the next section. McEvoy and

Schulze [105] support Foster et al.'s abstraction feature in Cloud, stating that

the abstraction occurs at the implementation level, where the Cloud's users are

hidden from the Cloud's services details, such as the location of their services,

the types of hardware used, the con�guration issues and many more services'

details.

Vaquero et al. [137] discussed more than 21 de�nitions of a Cloud and

proposed their own de�nition. According to Vaquero et al., the characteristics

of Cloud computing infrastructure are 1) a large pool of virtualised resources,

2) the potential for dynamically con�gured resources, 3) a pay per use model

as basis, and 4) an infrastructure provider o�ering users' Service Level Agree-

ments (SLAs). It can be seen that these characteristics support the fourth

characteristic in Foster et al.'s de�nition [47], the Cloud dynamic scalability.

Another important element of a Cloud highlighted by these authors is the vir-

tualisation technology of a Cloud's resources, which can be considered as an

abstraction feature of a Cloud. Virtualisation technology refers to a variety

of mechanisms and techniques used to decouple the architecture of hardware

and software resources from its physical implementation [2]. Vaquero et al.'s

de�nition also emphasises the pay-per-use scheme as the business model of a

16

2.1. Cloud Computing

Cloud. This is supported by the de�nition of a market-oriented Cloud from

Buyya [19], who stated that Cloud resources are provisioned based on the

users' SLAs and users are charged based on their usage.

A more recent de�nition can be found in a special publication on Cloud

computing by the National Institute of Standards and Technology1, or NIST, of

America. NIST de�ned Cloud computing as a model that enables ubiquitous,

convenient and on-demand access to a shared pool of computing resources that

can be dynamically provisioned and managed with minimal management e�ort

from the Cloud providers [106]. NIST further listed �ve essential characteristics

of a Cloud: 1) on-demand self-service, 2) broad network access, 3) resource

pooling, 4) rapid elasticity, and 5) measured service. The de�nitions and

characteristics provided by NIST are mostly in line with the previous published

de�nitions of a Cloud discussed above. Two new elements are added by NIST:

1) the automation of Cloud management, and 2) the broad network access �

the accessibility of a Cloud to any client platforms, including mobile phones,

tablet, laptops or workstation.

Based on these de�nitions, in this context of research, Cloud computing

will be referred to as:

A large-scale computing infrastructure that o�ers on-demand sca-

lable services (i.e., computation power, storage, platform and ap-

plication) to users over the Internet. The services are managed by

the Cloud provider via an automated Cloud management mecha-

nism. For market-oriented Cloud, the business model is based on a

pay-per-use model or on subscription for a certain period of time.

All the services are subject to certain SLA with the users.

2.1.2 Service models

Based on the de�nition of Cloud computing in the previous section, resources

in the Cloud refer to the computation power, storage servers, platforms and

applications. These resources can be classi�ed into three services: 1) Infra-

structure as a Service (IaaS), 2) Platform as a Service (PaaS), and 3) Software

as a Service (SaaS) [8][137]. Other services have been mentioned in the existing

literature, such as Hardware as a Service (HaaS) [8] and Shared Application

1National Institute of Standards and Technology, http://www.nist.gov

17


Infrastructure as a Service [67]. However, since these services have not been

completely de�ned, this research considers only the three main services.

Infrastructure as a Service (IaaS) o�ers customers fundamental computing

resources, such as computation capacity, storage and network [106]. IaaS pro-

viders usually deliver the service in the unit of virtual machine (VM) instances,

where a VM is an abstraction of the hardware resources of physical servers in-

cluding the CPU, memory and disk drives [128]. The service is aimed at users

who want to have IT infrastructure without having to buy their own servers

or network equipment. Users can deploy and run their own software on their

VMs. Through virtualisation, these resources are able to be dynamically re-

sized based on the user's needs. Charges are based on the total amount of

resources used. As an example for this category, Amazon Web Services2 o�ers

two IaaS services, Amazon EC2 for computation resources and Amazon S3 for

storage.

Platform as a Service (PaaS) provides a high-level integrated environment

for developers to design, develop, implement, test, and deploy their application

on the Cloud [112]. PaaS providers o�er programming languages, libraries, re-

lated services and tools for developers' use in implementing their applications.

Developing applications through PaaS brings a number of bene�ts to the de-

velopers. One bene�t is that PaaS is a suitable way to apply agile software

development methodology. The development method is based on iterative and

incremental development, which aims to evolve the application through colla-

boration of di�erent teams, including the developers and the clients. Through

PaaS, developers can roll out their application into Cloud test environments

that can be accessed by targeted Cloud users. PaaS can also help to reduce

the total cost of ownership (TCO) of the application, since developers can

rent the tools and kits needed for the development, without having to buy

the whole set. Some examples of PaaS providers are GoogleApps Engine3 and

Force.com4. Each PaaS provider usually has some restrictions on the type of

languages and software that the developers can use. For example, GoogleApp

Engine uses Python as their programming language while Force.com uses Apex

Code.

2www.aws.amazon.com3https://developers.google.com/appengine/4http://www.salesforce.com/au/platform/

18


Table 2.1: Main services of Cloud computing

Service Type Service Focus Existing CloudProvider

Infrastructure asa Service (IaaS)

Computation, Storage,network

Amazon S3, AmazonEC2, Nirvanix StorageDelivery, NetworkMicrosoft LiveMesh

Platform as aService (PaaS)

High level integratedenvironment fordeveloping, testing anddeploying customapplications

Google App Engine

Software as aService (SaaS)

Software Salesforce, Foresoft

The third Cloud service, SaaS, is the most common service used by Cloud

users. SaaS refers to applications that are hosted by Cloud providers, rather

than the software packages that are usually installed locally in user's ma-

chines. Through SaaS, users can access the application remotely and can

expect frequent updates from the providers as well. User's data that is related

to their SaaS is usually stored in a Cloud. SaaS in a Cloud can be divided into

two main categories, open source SaaS like GoogleDocs5 and commercial SaaS

like Salesforce.com6. The main focus of this research is on SaaS. This service

will be further discussed in Section 2.2.

Table 2.1 depicts the characteristics of these main services, in terms of the

service focus and some examples of existing providers. These three services of

a Cloud can also be considered as services-by-layer, which refers to the layers

of Cloud computing service architecture, as illustrated in Figure 2.1.

Apart from being the services stack, the layers also indicate the roles and

responsibilities of the users and the Cloud providers. As the layers height in-

creases, the responsibilities of management are shifted from the users to the

Cloud providers. In the bottom layer, IaaS o�ers services, which are the phy-

5http://www.google.com/apps/index1.html6http://www.salesforce.com

19


�

Figure 2.1: Cloud service architecture layer

sical servers and network of a Cloud with virtualisation. In this layer, users

deploy their own software onto IaaS, including the operating system and appli-

cations, while the Cloud provider will manage the underlying infrastructure of

the service. PaaS is built upon IaaS: here, a Cloud adds a layer of middleware

and an integrated environment for developers to build and deploy their Cloud

application. The software used for the development environment, such as the

operating system, programming language or databases, is usually controlled by

the providers. In this layer, users are responsible for designing and developing

their Cloud applications. The top layer of the services is SaaS, built on the

underlying IaaS and PaaS layers, and o�ering users software or applications

over the Cloud. In this service, everything is managed by the Cloud provider,

from the resource pooling in the infrastructure layer, the application con�gu-

ration in the PaaS layer, up to the management of application in the SaaS

layer. The users have only to select and customise their application based on

their requirement and also based on what the SaaS o�ers. Management by the

Cloud provider will be discussed further in Section 2.3, Research Assumptions.

20


2.1.3 Deployment models

Cloud deployment models can generally be divided into three types: 1) public

Cloud, 2) private Cloud, and 3) hybrid Cloud [24]. These Clouds share common

characteristics that are de�ned in a previous section; however, they di�er in

some areas, such as their business model, as well as the way the services are

o�ered. These di�erences are mainly because of the di�erent groups of users

for whom the Cloud is built.

A public Cloud refers to a Cloud that o�ers its services for public use; it

is owned and operated by an entity that is referred to as the Cloud provider

[106]. The data centre of the Cloud is on the premise of the provider. Most of

the public Clouds are usually market-oriented in which the services are o�ered

based on pay-per-use or the subscription model. Users will be charged solely on

their service usage. SLAs are usually established between the Cloud providers

and the users to provide Quality of Service (QoS) guarantees. Services o�ered

through the public Cloud are on a self-service basis where users can select and,

to some extent, customise the services they need through the Cloud provider's

interfaces. As the services are fully managed by the Cloud providers, the details

of the services, such as the service's exact location, implementation or service

allocations are kept hidden from the users. The services are usually scalable

and highly available due to the powerful data centre of the Cloud provider.

Among examples of a public Cloud are Amazon EC2 [64], GoogleApp [70] and

SalesForce [126], o�ering IaaS, PaaS and SaaS, respectively.

Private Cloud, sometimes known as enterprise Cloud, refers to a Cloud in

which its services are exclusive to a single organisation [71]. The data centre is

owned by the organisation and is usually located on the premises. All services

are tailored to the organisation's uses and managed within the organisation.

The services will be o�ered internally as needed. This deployment model is sui-

table for organisations that require a high level of privacy restrictions since all

the management and control of the resources are done by the organisation it-

self. However, this may require a large investment for the Cloud infrastructure

at the initial stage. An example of a private Cloud is Westpac, an Australian

bank company that has invested billions in building the company's private

Cloud infrastructure [96]. The need for such a Cloud is mainly because of

security reasons, as well as their requirements for higher processing capacity

for their internal services. Another example of a private Cloud is Fujitsu, a

21


provider for ICT-based solutions with its headquarters in Japan. Fujitsu has

built its private Cloud mainly to o�er SaaS tailored for the company's use

[127].

The hybrid Cloud, as the name suggests, represents a combination of both

public and private Clouds [106]. In this model, the public Cloud acts as a

supplement for the private Cloud, providing services that the latter does not

have. For example, the private Cloud can subscribe services that do not need

much security but require higher processing capacity from the public Cloud,

which is known for its scalable resources. Private Cloud providers can also

save some costs by designing their Cloud such that it caters only for services

that really need to be provided within the internal Cloud and subscribe to

everything else from the public Cloud. However, although this model sounds

most bene�cial, it has several drawbacks. The main issue is that this model

introduces complexity in managing and monitoring the services, due to the

di�erent standards that are applied in both Clouds, as well as to the proprie-

tary technology in the public Cloud. In addition, most details of the public

Cloud services are hidden from users, resulting in less control when combining

it with private Cloud services.

All types of Cloud providers usually have massive data centres to provide

the services to users. The number of servers involved is up to thousands in

a particular data centre [20][47]. A report by The Economist [1] stated that

Google has more than a million servers in over 30 data centres across its global

network. The report further stated that Microsoft upgraded their physical

infrastructure, adding 20,000 servers a month to their data centres.

2.1.4 Cloud Data Centre Model

Google Inc7 and Microsoft8 are examples of companies that have massive data

centres to support their Cloud operations. Both companies have always treated

their data centre details as proprietary; however, some general information has

been released for public knowledge [69][109]. It has been revealed that Google

data centre design their own computation and storage servers, and the servers

are installed in racks. Each rack is populated with a certain number of servers,

7http://www.google.com/about/company/8http://www.microsoft.com

22


and these racks are stored in a shipping container. The containers are housed

in a large building, which serves as indoor parking lots for the containers. The

servers in the Microsoft data centre are installed in a very similar fashion to

that of the Google data centre. The Microsoft data centre is reported to be

a two-storey building in which the ground �oor is for the containers and the

upper �oor is a normal data centre with racks of servers on a raised �oor. Both

companies have a number of data centres located all around the world. For

instance, as of today, Google has six data centres located in America, two in

Europe and three in Asia.

In contrast with the proprietary data centres mentioned above, Facebook

Inc9 has an ongoing project named Open Compute Project (OCP), an open

project for designing a data centre that aims to have high e�ciency with lower

cost [66]. In order to do that, they designed and customised their own com-

putation servers and storage servers, as well as server racks, and these techno-

logies are released as open hardware. The mission of this project concerns the

machine management: it aims to provide uniform management of �rmware,

focusing on process automation and scalability by leveraging existing open

standards. The general design of OCP is still consistent with the `container-

data-centre' design of Google and Microsoft Data Centre. Through the OCP

documentation, it is stated that the servers are clustered based on zones, re-

ferred to as the power zone. Each zone comprises computation servers, storage

servers and power equipment. Ethernet switches are installed for either each

rack or each zone. The racks are then clustered in a container, and clusters of

containers represent a data centre.

Based on all three data centre models used/proposed by these main compa-

nies in the Cloud sector, it can be summarised that the main entities in a Cloud

data centre are its servers, including the computation and storage servers, as

well as the network devices that are responsible for creating the communica-

tion topology between the servers. Usually, the computation servers (CS) have

their own resources, including processing capacity, memory capacity and secon-

dary storage. Three types of storage server can be applied in the data centre

infrastructure: 1) Network-attached storage (NAS), 2) Storage-area network

(SAN), and 3) Direct-attached storage [80][138]. These types are not mutually

exclusive, and can be combined as a hybrid type of storage. The network-

9http://www.about-facebook.com/

23


attached storage is a storage server with a simpli�ed operating system that

provides �le-based data storage to other devices/servers in the network. The

storage area network is a dedicated network that consolidates storage devices

such as direct-attached storage and o�ers block-level access data storage to

other devices. Direct-attached storage is a storage device such as disk array or

any digital storage system that is attached to a server. In a Cloud data centre,

these storage types are usually interconnected with the computation servers

through the network. A data centre may have more than one storage type, and

may also have more than one cluster for each type. This means that the sto-

rage devices are located throughout the data centre and each cluster di�ers in

its storage capabilities as well as its connection bandwidth to the computation

server. As for the communication topology, the common network devices used

are switches and routers. However, details concerning the network devices in

the Cloud model are not further explored: it is assumed that all the servers

are interconnected and the communication cost between servers depends on

its geographical locations.

2.1.5 Cloud Virtualised Data Centre

In order to create a �exible and scalable Cloud, virtualisation technology is

applied for Cloud servers. Virtualisation technology is used to create logical

containers which are abstractions of a server's resources, including its proces-

sing capacity, memory capacity and disk drive, into several di�erent isolated

virtual execution environments (VEEs), as if the environment is running on

its own server [122]. The concept was originally introduced by IBM in 1972,

and it is widely used in Cloud data centres as the key technology to provide

e�cient Cloud services. Virtual machine [128] and JavaEE containers [75] are

some examples of concrete implementation for VEEs. There are several main

advantages of virtualisation technology. One of the main advantages of vir-

tualisation technology is the ability of Cloud providers to serve multi-users

with di�erent requirements at the same time with a single server� also re-

ferred to as server consolidation, where it can directly reduce the number of

physical servers required. Since VEEs create isolated execution environments,

each VEE can have a di�erent resource capacity, di�erent operating system

and di�erent applications even though they are running on the same physi-

24


cal machine. In addition, changes can be made to a VEE without a�ecting

others sharing the same server. Another major advantage of virtualisation is

the e�cient utilisation of the servers' resources. Workloads are assigned to

VEEs according to their resource capacity; however, virtualisation technology

provides load balancing, the ability for VEEs needing more resources to move

to an underutilised server. Virtualisation can o�er many more advantages, in-

cluding disaster recovery, rapid deployment for testing and development, and

improved system reliability.

To ensure that the advantages of virtualisation are fully utilised, an entity

controls the physical server's resources to the VEEs. The entity is located in

a server and is responsible for monitoring and enforcing policy on the VEEs of

the server [10]. In a virtualised Cloud data centre, Cloud providers usually ma-

nage these virtualised resources via another entity on a higher level, referred to

as the resource management system (RMS), responsible for overall execution

of all the VEEs. For this research, a high-level architecture of Cloud vir-

tualised data centres focusing on SaaS management is developed to represent

the virtualisation and resource management system in a Cloud. It is loosely

based on the Cloud architecture proposed in Reservoir, an international pro-

ject that developed a modular and extensible Cloud architecture focusing on

the federation of Clouds [122], the Cisco Cloud data centre framework [10]

and a high-level market-oriented Cloud architecture proposed by Buyya et al.

[19]. These references are chosen based on the clarity of the architecture pre-

sented and also because the architectures proposed are general enough to be

considered in this research.

Figure 2.2 shows the high-level architecture of the Cloud data centre un-

der study. The �gure depicts multiple data centres in di�erent geographical

locations. In each data centre, there is a set of computation servers (CS), as

well as storage servers (SS) with their resource capacities. The resources are

then partitioned among multiple heterogeneous VEEs, each running some ap-

plications. This is referred to as the virtualisation layer, in which the VEE is

controlled by host managers. A host manager operates similar to a hypervisor

(also known as a virtual machine monitor) and Dom0 in Xen virtualisation

architecture [10]. The host managers are responsible for monitoring the per-

formance of the virtual machines and for handling the basic operations of the

VEEs, including creating a VEE, executing resource allocation policies, and

25


Figure 2.2: The high-level architecture of a Cloud data centre

executing the migration of VEEs. The host manager has certain interfaces that

enable it to access the physical servers resources as well as receiving commands

from an upper-level VEE Manager. At an upper level from the virtualisation

layer is a resource management system (RMS) that consists of a VEE manager

(VEEM) and a SaaS manager (SM). For the sake of simplicity, a centralised

RMS is considered; however, this architecture can easily be extended to a

decentralised RMS. In the next section, further details of the RMS will be

presented.

2.1.6 The Resource Management System in the Cloud

In this section, the Cloud RMS modules will be presented, focusing particularly

on management at the service layer rather than at the virtualisation layer, as

this is the main focus of this research.

The RMS may di�er from one data centre to another; however the main

responsibility of the RMS is to provide automated management of the Cloud

resources based on the objectives set by the Cloud administrator [48]. Among

the objectives are to deliver services that satisfy the users' Service Level Agree-

ment (SLA) and to optimise the resources utilisation. Figure 2.3 shows the

26


Figure 2.3: Modules in Cloud resource management system

basic main modules of the RMS based on architectures proposed in the existing

literature [19][27][48][122]. At the service layer, the focus is on the SaaS service

only. The RMS is divided into two interacting managers: the SaaS manager

(SM) and the VEE manager (VEEM). The VEEM basically focuses on the

management of the VEEs and its host servers at the virtualisation layer, while

the SM is responsible for the management of the service and its corresponding

VEE at the service layer. The two managers contained in the RMS are to pro-

vide a clear separation of responsibilities between layers. This is also to hide

low-level details that occur in the virtualisation layer from the service layer.

There are three modules in the SaaS manager: operational management,

business management and security management. The operational management

module is responsible for all stages in the SaaS cycle, from its initial place-

ment onto the Cloud infrastructure to its optimisation phase while the SaaS is

running at VEEs, as well as for monitoring the SaaS performance based on its

SLA. This module is the main one on which this thesis focuses. The following

are the tasks involved in the operational management module:

• SaaS placement: This task concerns the allocation of resources in the

form of VEEs to SaaS components. The placement is based on the

resource requirements of the SaaS and is driven by the performance of

the SaaS based on certain agreed SLA (e.g., response time).

• Request and admission control: The SaaS Manager is the highest level of

abstraction, where it will interact with the users to receive their requests

27


and derive their requirements, constraints and SLA. The request will

then be assigned to a suitable SaaS, based on the information that has

been derived.

• SLA monitoring and maintenance: Once the requests are allocated, the

SaaS manager will work with the VEE manager to monitor the SaaS and

keep track of the execution of the service to ensure that the performance

meets the agreed SLA. Adjustment of the resource and service allocation

may need to be done dynamically (online) or during maintenance (o�-

line) in order to maintain the service performance while optimising the

resource utilisation.

The business management module focuses on accounting, pricing and billing of

the SaaS. The accounting mechanism of this module will keep track of the user's

usage for billing purposes. The price of the service will then be determined

based on the user's usage and the agreed SLA. For the security management

module, since the SaaS may be shared by multi users at a time, this module

is responsible for authenticating and authorising the right users to the right

service.

The VEE Manager acts as the middleman between the SaaS manager and

the VEE host managers. The VEE host managers are responsible for all VEEs

on a particular server only. The overall performance of VEEs will be under

the responsibility of the VEE manager (VEEM). Basically, the VEEM has to

ensure that all the VEEs are su�cient to meet the request outlined by the

SM while optimising the utilisation of the server's resources. The tasks of

the VEEM can be categorised into three modules: 1) the placement module,

2) the monitoring module, and 3) the optimisation module. The placement

module refers to the mapping of a VEE to physical servers. The placement is

driven by several factors including the requirements and constraints outlined

by the SM as well as the data centre's policies on resource management. The

performance and availability of all the VEEs will be monitored as a group in

the monitoring module. The monitor mechanism will keep track of the resource

entitlement of the VEEs as well as their workload. This information will then

be used in the VEEM Optimisation module, in order to trigger any migration

or consolidation process of the VEEs.

28

2.2. Software as a Service

2.2 Software as a Service

SaaS emerged before Cloud computing came into view. Previously, SaaS

had been successfully implemented in the SaaS vendor's servers and delive-

red through the Web [67]. However, with the increasing demand for SaaS each

year [22], SaaS vendors need to �nd a solution to cope with these growing

requests. An obvious solution for this problem is to host the SaaS in a Cloud

computing infrastructure as it provides scalability to the SaaS that runs in a

Cloud. However, several issues need to be addressed before its bene�ts can

be fully realised. This section will discuss SaaS in more depth, focusing on its

de�nition, characteristics and examples.

2.2.1 De�nition and characteristics

The de�nition of SaaS is still open for debate, inasmuch as a number of pub-

lications have labelled it as a software delivery model [37][93], while others

have argued that SaaS is more than that. Based on the published de�nitions

of SaaS, the basic de�nition of SaaS is best provided by Chong and Carraro

[27], who referred to it as `software deployed as a hosted service and accessed

over the Internet'. To characterise it further, various existing de�nitions of

SaaS have been studied [61][127][12] and it can be concluded that SaaS di�ers

in three criteria from the conventional software or ASP-based applications: its

1) software possession, 2) business model, and 3) software design.

The �rst criterion concerns the separation of possession between the SaaS

and its ownership [134]. Two approaches preceded SaaS: the �rst, a conventio-

nal software approach and the second, the Application Service Provider (ASP)

approach. In the conventional software approach, clients have to buy software

licences from vendors and install the software on their own machines. The

software comes with a package � a CD installation and its manual, and the

price of the software usually includes a maintenance cost by the vendor. Any

version upgrade of the software will be considered as a new release with a

new price. Through this conventional software approach, clients possess and

own the software in their machine. In the ASP approach, the software is still

bought by customers who obtain a licence, but it is installed at the ASP data

centre [72]. The software is not shared with other customers, and the ASP

is responsible for maintaining the data centre infrastructure as well as the

29


software. In SaaS, however, the software resides at the provider's servers and

clients will execute the software via the Internet or an intranet [93]. The owner

of the software is the vendor and clients execute it on their demand only. This

eliminates the cost of IT overheads for the clients, as they do not have to worry

about any other IT infrastructure and management (except for their personal

computers and Internet connections). It can be seen that the main di�erence

between these approaches is the shift of software possession from the users to

the software providers.

The second unique criterion for SaaS is its business model. Conventional

software providers o�er a one-o� price to users, which includes the right to use

the software as long as customers want to as well as the support and assistance

directed in the terms and conditions agreement. In addition, users have to bear

the cost of the hardware and its maintenance. ASP relieves some of the latter

cost from users by hosting the software in their data centre. In this approach,

users are charged for one price that includes the software licence, the hosting

and the maintenance. It should be noted that the software does not belong to

and is not developed by the ASP; the ASP companies act as a middle party

that buys the licence from the software company and provides the hosting

infrastructure to users. As such, the software could not be deployed e�ciently

as any modi�cation or customisation of the software, as well as its maintenance,

will incur costs [72]. In SaaS, users will be charged on a usage-derived basis

via either subscriptions or a pay-per-use scheme. Users do not have to buy the

software licence as required in the conventional or ASP approach; they pay

only when they want to use the software and for how long they use it. As for

the hardware and software infrastructure, since the ownership of the software

shifts from the users to the providers, the costs for these are fully covered by

the providers. This is achieved through economies of scale in which the same

software can be served to multiple users; hence the infrastructure cost is shared

between users. Depending on the number of users of the software, this cost is

usually very small, as it is absorbed by the providers.

As for SaaS design, the multi-tenancy concept is the fundamental design

of SaaS that separates it from the approaches of other applications such as

conventional software, ASP or web-based applications. Through multi-tenancy,

di�erent users can be served concurrently on the shared hardware and software

infrastructure [52]. This is done through two concepts of SaaS application ar-

30


chitecture: multi-instance and multi-tenant. These concepts are mutually ex-

clusive and SaaS vendors apply either of these concepts based on their tenants'

needs and the nature of the application. In a multi-instance concept, one ins-

tance of the application is set to serve only one tenant, so to serve multiple

tenants, the SaaS providers create several identical instances of the SaaS. In

a multi-tenant concept, however, an instance of the application can be shared

among a number of tenants. In both concepts, tenant's customisation and

con�guration data are applied during the runtime to meet the tenant's speci-

�c requirements, if any. A number of existing publications on SaaS measure

the SaaS maturity level based on the multi-tenancy concept a SaaS has ap-

plied. However, there is no standard consensus on this matter. The research's

assumptions on this matter are presented and discussed Section 2.4 .

SaaS brings many more changes to the conventional software and ASP ap-

proaches. These changes bring several advantages to both SaaS users and SaaS

providers. Table 2.2 and 2.3 outline the main di�erences between SaaS, ASP

and the traditional software approach, based on the discussion in [37][43][72][121],

while Table 2.4 depicts the advantages of SaaS to SaaS users and SaaS provi-

ders [22][37][98][121].

2.2.2 Examples of SaaS

Salesforce10, one of the earliest commercial SaaS providers, began its opera-

tion of SaaS in 1998. Its main product, Customer Relationship Management

(CRM) solutions, is broken down into two SaaS products, Sales Cloud and Ser-

vice Cloud. Sales Cloud caters for tasks of sales personnel, including sales ma-

nagers, sales representative and sales marketers, o�ering functionalities such

as sales forecast and analysis, management of customer information, auto-

mated marketing campaigns and automated sales process through work�ows.

Through Service Cloud, Salesforce aims to provide assistance to sales personnel

customers by providing a customer service centre with various means of social

media channels including chat, online calls, portals and forums. As the name

implies, both types of SaaS from SalesForce are fully deployed in their Cloud

computing infrastructure. The price is based on the number of users as well as

on the functionalities that the users want to subscribe to, and it is charged on

10http://www.salesforce.com

31


Table2.2:

Characteristics

ofcon

vention

alsoftw

are,ASPandSaaS

approach

es

Main

characteristic

Trad

itionalsoftw

areapproach

ASPapproach

SaaS

approach

Ownersh

ipUsers.

Users

bought

thesoftw

arelicen

cefrom

thesoftw

arepublish

er.

ASPcom

panies.

ASP

companies

boughtthe

software

fromthe

software

publish

erandlicen

ceitto

users.

SaaS

prov

iders.

SaaS

prov

iders

ownand

develop

thesoftw

areando�er

itto

users

based

ona

pay-per-u

sebasis.

Platform

Softw

areisinstalled

ontheclien

t'smach

ine

Softw

areishosted

atASPdata

centre

Softw

areishosted

atprov

iders'

orthird

party

servers

Medium

ofdelivery

Users

will

receivea

software

package

that

inclu

des

aninstallation

CDand

itsmanual.

The

package

isdelivered

throu

ghretail

channels

and

hard

ware

orsoftw

areven

dors.

Users

accessthe

software

forwhich

they

have

thelicen

cethrou

ghtheIntern

etor

anintran

et.

Users

will

accessthe

software

accordingto

their

dem

andthrou

ghtheIntern

etor

anintran

et.

32


Table2.3:

Characteristicsof

conventional

software,ASPandSaaSapproaches

(continue)

Main

characteristic

Traditionalsoftware

approach

ASPapproach

SaaSapproach

Version

upgrades

Atypicalmajorrevisionis

usually

doneeverythreeto

�ve

yearsbythesoftware

company.

Upgrades

are

provided

based

ontheterm

sin

theagreem

ent.

AstheASPsdonot

ownthe

software,only

custom

isation

andmaintenance

isprovided

withadditionalcosts.

Afrequentandongoing

upgradecyclesince

the

vendor

ownsthesoftware

andthedeploymenttime

required

issm

all.

Software

Development

Methodology

Com

mon

phases

are

requirem

entanalysis,design,

implementation

andtesting

phasein

that

order

doneby

thesoftwarepublisher.

Iterationsmay

occurin

each

phasein

order

tomake

correctionsbased

onfeedbackreceived.

Requirem

ent,analysis,

design,implementation

and

testingphasein

that

order

isdonebythesoftware

publisher.ASPcompanies

areresponsiblefor

custom

isation,deployment,

selling,usage

and

maintenance.

Thephases

includesoftware

speci�cation,construction,

deployment,selling,usage

andmaintenance

inthat

order

donebytheSaaS

provider.

PricingMode

Usershaveto

pay

anup-frontfeethat

includes

thesoftwarelicence

and

maintenance

foraduration

oftime.

Usershaveto

pay

afeeto

theASPcompany,which

includes

thesoftwarelicence

anditscustom

isation,

hostinginfrastructure,and

maintenance.

Userswillbechargedfora

subscription

feeon

apay-per-use

basis.

33


Table2.4:

Advan

tagesof

SaaS

Main

characteristic

SaaS

Users

SaaS

Prov

iders

Delivery

mode

Users

canhave

anytim

eandanywhere

accesssin

cethesoftw

areisavailab

lethrou

ghtheIntern

et.

Thecom

mon

architectu

refor

SaaS

ismulti-ten

antarch

itecture.

Throu

ghthis,

SaaS

vendors

canshare

one

instan

ceof

thesoftw

arecost

e�ectively

acrossmultip

leclien

ts,which

canred

uce

thedelivery

cost.

ITinfrastru

cture

Users

donot

have

tocon

sider

the

complex

ITinfrastru

cture

ormanagem

ent,sin

ceitwill

behandled

bythesoftw

arehost.

SaaS

vendors

canoutsou

rcetheir

hostin

gprocess

toathird

party

prov

ider,

which

eliminates

thecost

oftheIT

infrastru

cture

overhead

.

Main

tenance

and

support

Users

will

receivecon

tinuousupgrad

esfrom

theven

dor

andthey

canexpect

theapplication

tobeupgrad

edin

time

tomeet

their

feedback

.The

main

tenance

will

alsobedonethrou

ghtheIntern

et.

TheSaaS

vendor

cancon

stantly

upgrad

etheir

software

based

onthe

feedback

ofusers

since

the

develop

mentanddeploy

menttim

eare

small.

Thecost

ofmain

tenance

canbe

reduced

since

itwill

bedoneonline.

Cost

Users

canhave

software

atalow

ercost

asthey

only

have

topay

based

ontheir

usage.

SaaS

delivery

modered

uces

the

tradition

alsales

costandoperatin

gcost.

34


a monthly basis. Apart from these two types of SaaS, SalesForce also o�ers a

development platform, Force.com, where users of SalesForce SaaS can develop

their own application to be used together with the SaaS. Force.com's funda-

mental design approach is multi-tenancy with metadata-driven architecture.

This approach is chosen to cope with the large user populations that use the

SaaS [141].

Google also has its own SaaS o�ering, namely Google Apps11, which covers

a wide range of SaaS. The SaaS can be classi�ed into three categories: 1) com-

munication applications in which they o�er Gmail for email, Gtalk for chat and

Google Calendar for calendar services, 2) o�ce applications including Google

Docs for word processor, spreadsheet and presentations, and 3) a mash-up ser-

vice (iGoogle) and web pages (Google Sites). All the applications are o�ered

for free with limited storage, or the user can go to Google Apps for Business

which have larger storage, guaranteed high availability and customer support,

with a price that is charged based on the number of users on a monthly or

yearly basis. The architecture behind Google Apps is unknown to the public;

however, based on Google PaaS and Google App Engine12, applications sup-

ported by Google infrastructure apply the multi-tenant concept, which allows

multiple tenants to run on the same application.

Apart from the commercial software above, enterprises and government also

implement SaaS for their internal use. For example, Satake [127] has discussed

the evolution of Fujitsu's internal software from ASP to SaaS in the Cloud.

Fujitsu is a provider of ICT-based business solutions for the global market-

place. Fujitsu started using the ASP approach for their internal software in

the mid 1990s, and then changed to the SaaS approach in 2005. In 2009, they

implemented the SaaS in a private Cloud infrastructure to take advantage of

the Cloud scalability and economies of scale. In their SaaS services, they o�er

two types of SaaS, general purpose and business SaaS. The former consists of

common services including e-learning and customer relationship management

services, while the latter focuses on speci�c business services, such as admi-

nistrative tasks in medical care or procurement submission processes. Fujitsu

also has its own platform services through which it provides a development

and testing environment for SaaS.

11http://www.google.com/enterprise/apps/business/12https://developers.google.com/appengine/

35


Based on these SaaS examples, it can be seen that SaaS providers have

broken down their SaaS into a smaller group of applications so that the SaaS

will be more �exible in its functionalities. In this way, users can customise and

choose the application that suits them. This is done to maximise the bene�ts

of economies of scale as well as to utilise the multi-tenant concept in which it

can reduce the delivery cost and provide better management of the SaaS.

2.2.3 Composite SaaS

A SaaS can be delivered as a composite application consisting of a group of

loosely-coupled individual applications that communicate with each other in

order to form a higher-level functional system or application [65]. These com-

ponents can be data sources or services that perform a speci�c function of

the SaaS, and may have interdependency with one another. The components

are physically distributed due to certain constraints; for example, a data com-

ponent that contains sensitive data needs to be stored in a certain location. To

serve a request for a particular user, related components will be dynamically

assembled on the �y at the provider's server in order to create the SaaS tailored

to the users' requirements. Delivering the SaaS in a composite mode instead

of atomic SaaS allows �exibility of the SaaS functionalities, where components

can be combined and recombined as needed. In addition, SaaS providers can

reuse the components, which can reduce the SaaS delivery costs as well as

decrease the subscription costs for its clients.

It should be noted that a composite SaaS is somewhat similar to the mash

up concept. Mash up services comprise a development environment in which

users can integrate existing web-based data, presentation or functionality to

create a new service that uses the combined information in a new way [92].

Composite SaaS extends the mash up concept by comprising a combination

of multiple software components with data, logic and processes to create a

new application. The composite SaaS may apply service-oriented architecture

(SOA) as its construction model. SOA is an architecture paradigm that focuses

on the development of a set of component services that interact with other

components [65][93][113] .

A motivating example of a composite SaaS can be taken from Hudli et al.

[61]. The authors proposed a SaaS for the healthcare industry in which a num-

36


ber of stakeholders were involved, such as an insurance company, employees

who wanted to be insured (also referred to as patients in some scenarios),

healthcare providers, physician and pharmacist. The aims of the software are

to 1) provide a collaborative platform for the industrial health insurance pro-

cess, 2) manage multiple healthcare providers for insurance companies, and

3) provide a patient-physicians portal. This SaaS is a motivating example for

the distributed composite SaaS approach previously described. Based on the

SaaS, each aim can be achieved through a number of functions. The functions

can be developed as a service or as data components, and to ensure scalability

of the SaaS, an instance of this service can be shared between stakeholders.

Requests from stakeholders will be served by combining two or more di�erent

components' instances based on the requirements of stakeholders. This ap-

proach enables SaaS providers to manipulate and reuse the SaaS components

in addressing the di�erent levels of services that a stakeholder requires.

Another example of composite SaaS application is the Fujitsu SaaS applica-

tion service discussed earlier. In the Fujitsu general purpose and business SaaS,

some data components are shared between the services. In addition, some of

the services are interdependent in order to provide a higher-level functionality

of the SaaS. At the moment, the interdependency between these services oc-

curs within the same data centre site. However, in order to make the SaaS

more e�cient, Fujitsu aims to link SaaS services that will be distributed among

multiple sites in the future.

These SaaS examples show that there is a need to deliver the SaaS via

composite components in which the composition is done dynamically and au-

tomatically on the provider's side, based on user requirements. The compo-

nents can be interlinked in order to form a higher-level of SaaS functionality.

This way, providers can gain a number of bene�ts including reduced delivery

cost, �exible o�ers of the SaaS functions and decreased cost of subscription for

clients. However, this approach also introduces complexities in SaaS resource

management, especially in maintaining the composite SaaS performance and

optimising the resources used for each of the components.

37


Figure 2.4: Microsoft's SaaS maturity model

2.2.4 Composite SaaS Application Model

As mentioned in a previous section, SaaS came into view a long time before the

Cloud appeared. Since then, it has developed and matured to accommodate

the growing requests from users. In order to characterise the SaaS for Cloud,

the SaaS application model is developed based on two existing SaaS maturity

models. Although these models have di�erent views in some aspects, they

share the same objective, which is to de�ne the key attributes of a mature

SaaS application. This section discusses the two existing maturity models

proposed by Microsoft [27] and a model proposed by Kitagawa et al. [87], and

outlines a composite SaaS application model.

Microsoft developed their SaaS maturity model [27] using three key attri-

butes of SaaS applications � con�gurability, multi-tenant e�ciency and scala-

bility � that are indicators of the maturity of a SaaS application. The model

has four incremental levels, each level considered to be an upgrade from the

previous one in terms of the key attributes. Figure 2.4 illustrates all four levels

of the maturity model. In the �gure, an instance is a copy of the SaaS and a

tenant is an individual or an organisation that subscribed to the SaaS.

Level 1 in the maturity model (denoted as L1) allocates an instance to each

tenant exclusively; the instance will be con�gured and developed speci�cally

to meet the tenants' needs. Level 2 also has a separate instance for each

tenant; however, these SaaS instances are not developed exclusively for each

tenant. In this level, there will be con�guration options to meet the tenant's

speci�c needs. Level 1 and Level 2 apply the multi-instance concept. In a

multi-instance concept, one instance of the application is set to serve only

one tenant. As such, the SaaS providers create several identical instances of

38


Figure 2.5: A general SaaS maturity model [87]

the SaaS in order to serve multiple tenants. Level 3 introduces multi-tenant

support, through which an instance of the application can be shared among a

number of tenants. The tenants' functionality will be con�gured according to

their needs. In Level 4, scalability features are added through a load balancer

mechanism that balances the allocation of the instance to its tenants. Based

on the current technology of Cloud computing and SaaS demand, Level 3 and

Level 4 are the mature levels being practised by SaaS providers.

Kittagawa and colleagues [88] proposed a more comprehensive SaaS ma-

turity model. They de�ned the core criteria of SaaS using two axes: service

component as the x-axis and the maturity level as the y-axis. The service com-

ponent axis represents four features of structuring software business: 1) data,

2) system, 3) service and 4) business. The other axis represents the maturity

levels of the SaaS in respect of four types to SaaS o�ering: 1) ad hoc/base, 2)

standardisation, 3) integration, and 4) virtualisation. For the x-axis, only the

system and service components will be discussed as these two are relevant to

the scope of this thesis. Figure 2.5 shows the maturity model.

As can be seen in Figure 2.5, each level in the maturity model is described

based on service components. Level 1 in this model is similar to the Microsoft

maturity models that were discussed earlier, where the application is developed

to cater for a single tenant's requirements only. The applications in this level

are more akin to the ASP approach than to the SaaS approach. In Level 2, the

con�gurable application is introduced with no multi-tenant support. Level 3

applies multi-tenant support with service connection. The service connection

39


refers to the combination of services to serve various users' functions. Level 4

presents the most mature SaaS, which uses multi-tenant with load balancing,

and the application architecture is fully on SoA. SaaS at this level largely uses

virtualisation technology in a Cloud. Levels 3 and 4 in this model include soft-

ware with service connection and service on SoA. The authors further stated

that the service connection can be achieved by web services or mash ups.

The two maturity models discussed above indicate that SaaS deployed in

a Cloud infrastructure is regarded as the most mature SaaS, with several fun-

damental features including 1) con�gurability, 2) multi-tenancy, and 3) sca-

lability. Con�gurability refers to variations of a single application base, that

make each tenant have a unique software con�guration [115]; a multi-tenant

application can satisfy the needs of multiple tenants using the same hardware

resources [141], and scalability refers to the ability of an application to expand

and serve new tenants dynamically [27]. Another additional feature found

in Kitagawa et al.'s models is the SaaS elasticity feature through dynamic

composability. This means that, the overall functionalities of an application

are achieved by automatically composing several application components in

order to create a new SaaS with higher-level functionalities to meet tenants'

demands.

Figure 2.6 illustrates a composite SaaS application model in a Cloud in-

frastructure that incorporates all the main features of a mature SaaS as well

as its position in a Cloud data centre infrastructure. The model re�ects that

an instance of SaaS is made of one or more application and data components

in which these components o�er elementary services that can be composed to

provide SaaS functionalities. All components can support more than one te-

nant, are con�gurable and can be increased or decreased as necessary in order

to ensure that the overall performance of that particular instance is maintai-

ned. The load balancer in the existing SaaS maturity model is replaced by the

resource management system (RMS), as its task is more complex compared to

the load balancer, which manages a single application with multiple identical

instances. The RMS is responsible for delegating the request to an instance

as well as for managing the components. Virtualisation technology is used in

order to execute these components. Each may be executed at di�erent VEE

and has its own requirement. The quality of the SaaS functionalities depends

on the overall performance of the components based on a business work�ow.

40

2.3. Research Assumptions on Cloud and SaaS

Figure 2.6: Composite SaaS application model in Cloud infrastructure

2.3 Research Assumptions on Cloud and SaaS

As Cloud computing is still in its early stage, numerous di�erent Cloud data

centres and SaaS management models and architecture have been discussed in

existing publications. In addition, most Cloud and SaaS companies do not dis-

close the details of their model/architecture, as such information is regarded as

a company's competitive advantage. Consequently, several assumptions have

to be made, based on information published by the Cloud companies as well

as existing research that has been done in the area. These basic assumptions

will serve as the foundation for the algorithms proposed in the later chapters

of this thesis.

Four main assumptions used in the problem formulations of the research

problems are presented in this chapter. The �rst is the Cloud data centre

model where, through the developed model, information is obtained about the

main elements of Cloud, as well as how these elements are connected (Section

2.1.4). The model is then further explored by studying the integration of vir-

tualisation technology in a Cloud data centre. A high-level virtualised Cloud

data centre architecture is proposed that illustrates the Cloud elements with

its virtualisation layer (Section 2.1.5). The architecture also introduces the

Cloud resource management system, which is responsible for auto-managing

the Cloud resources. In the third assumption, details of the Cloud resource

management system focusing on SaaS management are presented. The main

modules of SaaS management and virtualisation management are discussed

41


and explained (Section 2.1.6). Finally, the main features of the SaaS applica-

tion model, based on two existing SaaS maturity models, have been explored

and the composite SaaS application model in a Cloud outlined (Section 2.2.4).

2.4 Evolutionary Algorithms

Evolutionary algorithms (EA) mimic the process of natural evolution in its

computational models, where the main concept is the survival of the �ttest

[41][129]. EA uses a population of structure in which an individual in the

structure presents as a solution for the problem. These individuals evolve

according to the EA's rules and genetic operations. There are a number of

EA techniques, including genetic algorithms (GAs), evolutionary programming

(EP) and di�erential evolution (DE). Among these technique, GA is chosen as

the main technique to solve the proposed problems.

The major reason GA is chosen is because the three research problems can

be considered as large scale complex combinatorial optimisation problems due

to the size of the problems, its constraints and its optimisation objectives.

GA is suitable for solving this type of optimisation problem where it has been

proven in various domain including business, engineering and science [23]. Ad-

ditionally, GA is also chosen based on its strength that can be utilised for the

problems. Among the strengths are: 1) GA maintains a population of candi-

date solutions in which this has many signi�cant impacts on how the solution

space is searched, 2) GA is naturally parallel and can easily be adapted to

execute on parallel computers, and 3) GA can perform well in problem that

has complex �tness landscape where the �tness function changes over time or

has many local optima.

This section highlights a brief description of genetic algorithm. Variations

of the algorithm are also introduced where these variations will be used as a

base technique in solving the composite SaaS resource management problem.

2.4.1 Introduction of the Genetic Algorithm

Genetic algorithms were �rst introduced by Fraser and later developed by

Holland [58]. GA is a stochastic search method that mimics the process of

biological evolutions, particularly in its selection of solutions process as well as

42

2.4. Evolutionary Algorithms

its recombination of the solutions operation [51]. GAs yield the best solution

by manipulating a group of candidate solutions in which the �ttest solution

gets a higher chance to survive (to model the survival of the �ttest) and the

solution will be recombined with other solutions (to model reproduction) to

introduce new solutions into the population. As of today, GAs have been

applied successfully in many areas including business, engineering and science

[23].

Figure 2.7 illustrates the basic processes that are performed in a classical

GA. The �rst step is the initialisation of a group of candidate solutions, better

referred to as a population of individual solutions. The initialisation is genera-

ted randomly and the size of the population is determined by the implementer

of the algorithm. The size of a population is among the important parameters

in GA: the small size of population may lead to poor sampling and di�culties

in identifying good individuals while, if the population is too big, computa-

tional resources will be wasted in processing the extra individuals [23]. The

second step is to evaluate each of the individuals to determine its worth to the

problem. The evaluation is done using a �tness function, which typically mea-

sures the �tness of each individual based on a number of performance criteria

used to optimise the problem. Then, the algorithm will select a number of

paired individuals to be the parents for the crossover process. The selections

are typically based on the �tness value, where �tter individuals have a higher

chance to be selected. The crossover operation basically resembles the sexual

recombination in natural organisms. The two parents selected earlier will be

recombined, producing two children. These parents or children will be copied

to the next generation of a new population. Some of the individuals in the

new population will then undergo a mutation operation. The new population

of individuals will be evaluated and the process of selection and reproduction

will be repeated until a termination criterion is satis�ed.

Compared to other search algorithms like enumerative search [132] or ran-

dom search [51], GAs are most suitable for large optimisation problems that

have more than one possible solution. The enumerative search is a straightfor-

ward technique, in which the technique evaluates every possible solution from

a given �nite set. This is suitable only when the number of solutions is small.

As for random searches, searching a large space solution randomly takes a long

time. Although GA has a random element in it, the GA search is directed by

43


Figure 2.7: The basic processes of classical GA

the environment. It balances the exploration to avoid local optima with ex-

ploitation converging to the optima through its recombination and selection

process. The following section further describes the main components of the

classical GA and introduces some common terms of the algorithm that will be

used throughout this thesis.

2.4.2 Classical Genetic Algorithm Components

The ability of a GA to �nd the optimal solution mainly relies on the imple-

mentation and manipulation of its main components. The main components

of a classical GA are 1) the representation of individuals, 2) the evaluation

function, 3) the selection process, and 4) the reproduction process.

The representation of individuals An individual solution in a population

is represented by a chromosome containing the problem's speci�c information

and solutions [132]. A chromosome is usually expressed in a �nite-length string

of variables. The variables are referred to as genes of the chromosome and can

be represented by binary, integer, real-valued numbers or any other form de-

pending on the problem [38]. The range of values for genes is also determined

based on the problem. The chromosomes are considered at two levels: pheno-

type and genotypic. The former represents the value for the decision variables

44


of the problem; the latter is an encoded version of the phenotype, which the

computer stores and the GA manipulates. The mapping between these two

levels is an important process; however, in some cases, a phenotype and its

corresponding genotype can also be the same, which means that the mapping

between the two is trivial.

The representation of an individual plays a signi�cant role for the e�ciency

and behaviour of the algorithm [7]. Most of the existing research uses the

classical bit-string representation; however, a number of di�erent approaches

of chromosome representation have been proposed to suit the nature of the

problem and its optimisation strategy. Among the approaches are order-based

representation for graph colouring problems [39], embedded lists for factory

scheduling problems [107] and lookup tables for iterated prisoner dilemma [7].

The evaluation function The evaluation function, better referred to as the

objective function, links the GA with the problem that the algorithm wants to

solve [35]. In most problems, the objective function is stated as the minimisa-

tion of some cost function, or the maximisation of some pro�t function. Each

of the chromosomes will be evaluated using the objective function in order to

know its worth against all other candidate chromosomes. The value of the

objective function may vary from one problem to another. To standardise this

value, an objective function is mapped to a �tness function where the �tness

value for each chromosome is used to determine the ability of the chromosome

to survive in its population.

The selection process Two main selection processes occur in every genera-

tion of a GA. The �rst selection is the parent selection [41]. Two chromosomes

are selected to be the parents, and they will undergo a crossover operation

to produce two new chromosomes (referred to as children or o�spring). The

second selection is to select a new population of chromosomes at the end of

every generation. The selection can be from existing chromosomes or from

new chromosomes that are generated from the crossover operation. Several se-

lection operators have been developed for these processes. In most operators,

�tter chromosomes have a higher chance of being selected and surviving in the

next generation. Following are some of the popular selection operators:

1. Roulette Wheel Selection (RWS): RWS is a proportional selection opera-

45


Figure 2.8: Roulette wheel selection procedure

tor in which the probability of a chromosome being selected in each trial

is constant and equal to its normalised �tness value. Figure 2.8 describes

the procedure of RWS [51].

2. Tournament Selection: In this selection, two chromosomes will be selec-

ted randomly and compared with each other. The chromosome that has

the better �tness value in the pair is declared the winner [53].

3. Elitism: This is a selection strategy for exporting a group of the �ttest

chromosomes to the next generation. The selected chromosomes do not

have to undergo the reproduction process at all. The total number of

chromosomes to be selected is usually based on the problem's need. In

this selection process, the more elite the chromosome that get copied to

the next generation, the less diverse the generation would be.

The reproduction process The purpose of the reproduction process is

to produce new chromosomes that have a high probability of improving the

population performance, such that the solutions are directed to converge to

its optima. Two genetic operators have been adapted from the natural evo-

lutionary process for this purpose: the crossover operator and the mutation

operator. The crossover operator is considered to be the primary exploration in

GAs, while the mutation operator is to introduce variations and add diversity

to the population.

Crossover is a recombination operator that combines subparts of two chro-

mosomes (referred to as `parent chromosomes') to produce o�spring/children

that contain features of their parents [132]. Several types of crossover operators

can be applied onto the parent chromosomes: one-point crossover, multipoints

crossover and uniform crossover [41]. In the one-point crossover, a random

point is randomly selected and the parts of the parent chromosome beyond

46


Figure 2.9: One-point crossover operation

Figure 2.10: One-point mutation operation

the point are exchanged to produce the children. Figure 2.9 shows an example

of a one-point crossover. The multipoints crossover is similar to the one-point,

but in this case n point positions are randomly selected, and the parts between

these points are swapped. In the uniform crossover, each position in a chromo-

some is a potential crossover point. It will be determined by a point-swapping

probability in which, at each point, the corresponding gene is exchanged based

on the probability.

Mutation is an operation that aims to create a new chromosome from an

existing one. This operation is triggered based on a certain probability, which is

typically set to a small value to ensure that �t chromosomes are not changed

easily. Each gene in a chromosome will be checked, and if the gene passes

the probability test, it will be changed to a random new value. Figure 2.10

illustrates an example for the mutation operation.

Apart from the main components that are described above, the termination

condition of the GA is also important and needs to be carefully determined

in order to ensure that the GA can perform well. Among the methods that

are commonly used are to terminate either when there is no improvement on

the best solution after a number of consecutive generations, or based on a

predetermined number of generations [110].

47


2.4.3 Genetic Algorithm Variants

Di�erent implementations and extensions of GAs have been developed over the

years. These variants are developed to cater for requirements of the problems

that the classical GA does not cover. This section introduces three GA variants

necessary for the consequent development of the GA approaches described in

later chapters.

Co-evolutionary Algorithms An early de�nition of coevolution in biologi-

cal evolution was provided by Janzen [73], who de�ned the term as an evolution

of one species resulting from its responses to characteristics of another species

in a common ecosystem. Each species mates within its own species only. This

coevolution process has been adapted as an extension to classical GA. It is spe-

cially developed to cater for 1) complex problems that have very large search

domains, where the problem can be modularised into several interacting sub-

spaces [60], and 2) problems that have to evaluate the �tness of an individual

based on its interaction with other individuals [36]. The co-evolutionary al-

gorithm can be further classi�ed into two types: cooperative co-evolution and

competitive co-evolution.

In cooperative co-evolution, the �tness of a species (or, as it is usually re-

ferred to, subpopulation) is calculated on how well it `cooperates' with other

subpopulations in order to produce a good solution. The decomposition of the

subpopulations is based on a divide and conquer strategy in which all parts

of the problem evolve separately. Among the existing work on cooperative

coevolution is that by Potter and Jong [117], who presented a cooperative co-

evolutionary genetic algorithm for function optimisation. In their paper, an

optimisation problem with N variables can be decomposed naturally into N

subpopulations. The individuals are rewarded when they work well with other

individuals in another subpopulation and are punished if together they perform

poorly. Work by Husbands and Mill [62] applied multiple cooperative subpo-

pulations to a job-shop scheduling problem. This cooperative co-evolution has

also been applied to arti�cial neural network areas [111][119].

Competitive co-evolution refers to problems in which several interactional

subpopulations compete with each other for common resources or space. In

this case, the individuals are rewarded at the expense of those with which they

compete. One pioneer research on this area was by Hillis [56], who applied the

48


Figure 2.11: Coevolutionary model with three species [117]

competitive co-evolution in a host-parasite model to the problem of generating

a minimal sorting network. In the literature, the existing research for com-

petitive coevolution focuses mainly on game strategy and non-linear control

systems.

This thesis focuses on the cooperative co-evolutionary algorithms. Figure

2.11 shows the basic co-evolutionary model with three species. It can be seen

from the �gure that each species evolved in its own population and has its own

GA. However, the �tness of an individual is evaluated through collaboration

with other representatives from another species.

Constraint Handling Genetic Algorithms Most real-world optimisation

problems come with several constraints that a solution has to meet in order to

solve the problem. The constraints restrict the search space for the problem,

as there are search areas that do not comply with the constraint, making

the solution infeasible. GA is a type of unconstrained optimisation algorithm

49


which does not provide any guidelines on how to deal with unfeasible solu-

tions [35]. The reproduction operators in GA, like crossover and mutation,

are not designed to handle constraints in reproducing new individuals [28].

There are generally three categories of constraint in optimisation problems: 1)

boundary constraints � the upper and lower bounds for a variable, 2) equa-

lity constraints � the value of a variable must be equal to a constant, and 3)

inequality constraints � where a value of a variable must be less/greater than

or equal to a constant [41]. A number of constraint handling methods that

incorporate GA are proposed in the existing literature. These methods can be

categorised into several classes, some of which are described below [30].

1. Penalty functions method: This is the most common, widely adopted

method for handling constraints in GA. In this method, the �tness value

of an infeasible solution is degraded by a weighted sum of constraint vio-

lations. Variants of this method include static penalty models in which

the penalty factors do not depend on the current number of generations

[59], dynamic penalty models which consider the current number of ge-

nerations in penalising the solutions [79] and adaptive penalty methods

where the penalty function incorporates feedback from the search process

[13].

2. Preserving feasibility methods: This method introduces a special repre-

sentation scheme for its chromosomes, as well as special reproduction

operators that work in a similar way with the classical operators. This is

to ensure that the feasibility of the solutions is preserved at all times. An

example of this method can be found in Davidor [34], where the author

applies varying length representation schemes to generate robot trajec-

tories, and introduces an analogous crossover operator to accommodate

the the special representation.

3. Repair methods: This method de�nes a special action for infeasible so-

lutions in order to change them into feasible solutions. There is no stan-

dard design on how to repair the solutions; the strategies include the use

of the greedy method, random algorithms, or domain-knowledge based

heuristic to guide the repairing process [30]. Xiao et al. [143] apply

the repair method in their GA design to transform an infeasible path

for a robot moving from one point to another to a feasible one which is

50

2.5. Summary & Conclusion

collision-free. They apply the domain knowledge heuristic in order to get

a feasible solution from an infeasible one.

4. Convert the constrained problem to unconstrained problem: A constrain-

ed problem can be converted into an unconstrained problem by de�ning

the Lagrangian for the constrained problem, and then by optimising

the Lagrangian [41]. The Lagrangian is a mathematical method that

provides a strategy to determine the local maxima and minima of a

function subject to an equality constraint [76].

Each of these classes has its own advantages and disadvantages in solving

the problems. In most cases, the implementations of the constraint handling

technique are based on the nature and the class of the problem in hand. For

instance, a method that performs well in non-linear optimisation problems may

not do well in a di�erent domain, such as combinatorial optimisation problems.

Hybrid Genetic Algorithms The performance of GA can also be impro-

ved with the hybridisation method. This is especially advantageous when the

problem-speci�c knowledge is available [51]. In hybridisation, the classical GA

is combined with local search methods with heuristic or other optimisation.

This is also referred to as memetic GA or genetic local search [114]. The hy-

bridisation can improve both the quality of the solution produced and the GA

e�ciency. For the former, as GA is more on the global search, the combination

with a local search method will produce a more powerful and focused search

algorithm [114]. As for e�ciency, having the local search reach a local opti-

mum while GA provides the speci�c search space can de�nitely enhance the

search e�ciency, especially in terms of computation time taken, as well as the

memory needed to process the algorithm [40].

2.5 Summary & Conclusion

The objective of this thesis is to develop algorithms for composite SaaS resource

management in Cloud. Therefore, this chapter presents background areas that

are relevant to the objective. The areas are categorised into three subjects �

Cloud computing, Software as a Service and evolutionary algorithms.

51


Cloud computing has successfully changed the way that IT resources are

delivered to users. Through the Cloud, all kinds of IT services that were pre-

viously owned and managed by the users can now be outsourced at reasonable

costs with a �ne granularity of level of service. Cloud computing has emerged

as a viable distributed computing infrastructure that brings many bene�ts to

its users. Among the main bene�ts are:

• Reduced cost: Users of a public Cloud can save a considerable amount

of costs relating to setting up and managing hardware infrastructure for

their required IT resources capacity. In addition, charges of IT resources

in a Cloud are based on user's usage. As for private Cloud, by adopting

the Cloud paradigm internally, organisations can save operational costs

and maintenance budgets for their IT resources. This is due to the high

capability of the Cloud concept, where resources can be utilised through

virtualisation technology.

• Flexibility: A wide range of level of services are o�ered by Cloud pro-

viders where users can select what they need and how they want the

services to be. In addition, the services can scale up or down automa-

tically to meet peak or low demands. As such, users do not have to

worry about running out of resources, or underutilising their subscribed

services.

• Automation: All services in the Cloud are highly automated, thus less

human intervention is needed.

Although Cloud computing has been proven relevant to meet the current needs

of IT services, there are some signi�cant challenges for Cloud providers to

address before the full bene�ts can be gained. The need for an e�cient resource

management system has been highlighted in the existing literature as one of

the challenges [47][42][20].

One of the Cloud service, SaaS, is receiving considerable attention from the

software vendors, as well as from software users [67]. According to a review of

SaaS vendor companies by Dubey and Wagle [37], the revenue for companies

that provide SaaS rose 18% between 2002 and 2005; and Gartner Inc [68]

forecasted that SaaS will continue to experience positive growth through 2015,

with worldwide revenue projected to reach $22.1 billion.

52

2.5. Summary & Conclusion

As SaaS is predicted to bring more �nancial incentives and bene�ts to com-

panies and software users, many practitioners and researchers have discussed

methods to improve the quality of SaaS performance. Among the major issues

are the capability of the software vendor to handle SaaS resource delivery and

the computation and data management of SaaS [22][37]. These issues can be

classi�ed as SaaS resource management problems. This research investigates

some of the issues arising in this area, focusing on composite SaaS.

Along with the research background, this chapter presents the research as-

sumption that serves as the main basis for this thesis. This is unavoidable

as there is no standardisation or consensus on SaaS in Cloud computing yet,

as it is still considered to be in its infancy stage. The assumptions are made

based on work published by industrial organisations as well as research done

by researchers and academics. All the assumptions mainly concern the mo-

del and the architecture of a Cloud, SaaS, and the resource management of

SaaS in a Cloud. Formulation of the research problems and development of

genetic algorithms in subsequent chapters will be based on these models and

architectures.

53

Chapter 3

Evolutionary Algorithms for the

Composite SaaS Placement

Problem

SaaS models allow software applications o�ered as a service through a Cloud

rather than as a software package that has to be installed in individual ma-

chines [112]. In order to o�er di�erent functionalities to users, a SaaS can be

delivered as a composite service, which consists of a group of loosely coupled in-

dividual application components and data components that communicate with

each other in order to form a higher-level functional service. The placement

of the composite SaaS onto the Cloud infrastructure has to be done strategi-

cally, as the SaaS components are dependant on each other, and their locations

are geographically spread in the Cloud network. Existing placement methods

were not designed for composite SaaS in the Cloud data centre. Those me-

thods mostly focus on resource consumption by the components and are not

concerned with the placement of the di�erent types of components with de-

pendencies.

This chapter outlines the problem and proposes three evolutionary algo-

rithms for the problem. The solutions proposed are tailored to the composite

SaaS placement problem in a Cloud. The following section will introduce the

problem background and highlight the gap of the problem, while Section 3.2

describes the problem formulation. Section 3.3 reviews the two closely related

existing problems. The proposed algorithms are presented in Section 3.4, Sec-

tion 3.5 discusses the evaluation results and Section 3.6 concludes the chapter.

55

CHAPTER 3. EVOLUTIONARY ALGORITHMS FOR THE COMPOSITESAAS PLACEMENT PROBLEM

3.1 Introduction

One of the many advantages of SaaS is that it o�ers �exibility of functionali-

ties to users. The SaaS functionalities can be added or removed to meet the

requirements of each of the users. In each case, the customisation can be done

either by the users themselves at the client side or automatically at the server

side. Two examples of such a scenario are the SaaS CRM o�ered by Salesforce1,

and Luxor CRM2 by Luxor CRM Inc. Salesforce o�ers �ve di�erent categories

of the SaaS CRM based on the functionalities of its SaaS CRM, where higher

levels indicate more functionalities. In addition, users are allowed to customise

the SaaS at levels four and �ve. This is similar to Luxor CRM, where users are

given access to control and customise their product within certain parameters.

This �exibility of features, also known as elasticity of functionalities, can be

achieved through composite SaaS. Here the SaaS is not delivered in one service,

but as parts of the SaaS, where each part can be deployed on its own. These

parts are referred to as components, and each of the components represents a

well-de�ned function of the software. These components can be data sources

or application services, and communicate with each other in order to form a

higher-level functional system or SaaS [65][85][93].

The full utilisation of composite SaaS brings a number of bene�ts, parti-

cularly to SaaS providers. These bene�ts include 1) reduced resource costs, as

the components are reusable, 2) �exible o�ers of the SaaS functions, and 3)

decreased subscription cost for users. However, it also raises new challenges

for SaaS providers in managing the composite SaaS. One of these challenges

is to determine the initial placement of each component onto the data centre.

The placement is an o�ine process that is carried out at the initial stage of the

SaaS deployment onto Cloud data centre by the Cloud/SaaS provider through

the resource management system. In a wide-area distributed environment in

which common resources are shared, such as a Cloud environment, the com-

ponent placement algorithm must be able to e�ectively initialise the placement

of the components onto Cloud servers, such that the resource contention bet-

ween components can be avoided and the interaction between components is

smooth. This is to ensure that the performance of the SaaS is optimal, while

1http://www.salesforce.com2http://www.luxorcrm.com

56

3.1. Introduction

complying with its requirements. The problem of placing SaaS components

and their related data components in Cloud servers is referred to as the SaaS

Placement Problem (SPP). The aim is to determine which computation server

(or its virtual machine) should be assigned to each of the SaaS components,

and which storage server will hold the SaaS data components, such that the

SaaS resource requirements are satis�ed and the SaaS performance is opti-

mal using the estimated execution time as its performance measure. Both the

computation servers and the storage servers are located across the globe in a

particular Cloud network.

SPP introduces an important new feature to the problem: this feature

has not been addressed in the previous work on two other closely related pro-

blems. One is the component placement problem (CPP), in which the problem

concerns choosing the right physical resources for each application component,

such that the users' requirements are satis�ed and the usage of resources is mi-

nimised [87][135][146]. Another is the task assignment problem (TAP), which

refers to the problem of assigning a number of tasks of a computer program to

a number of processors, in such a way that the given cost function is minimi-

sed [81][90][125]. Among the cost functions that have already been addressed

are the total execution time, the communication time among tasks, and the

minimisation of processor's load. In both problems, the solutions are sub-

ject to a set of constraints, such as the hosts' resource constraints and the

task/component placement constraints. Although extensive research has been

carried out for both types of problem, their solutions do not take account of

the placement of di�erent types of components (or tasks), where these dif-

ferent types of component have to work together and contribute to the overall

performance of the service. This is the case of composite SaaS: it is formed

by a number of application components as well as by data components, and

each of the components has di�erent sets of resource and communication re-

quirements that need to be ful�lled. The existing solutions of CPP and TAP

consider data component placement as the input and not as part of the place-

ment process. This thesis presents a placement algorithm that addresses this

gap. As the CPP and TAP have been proven as an NP-complete problem

[18][81][125][146], the proposed algorithm uses the approximate optimisation

approach through a number of evolutionary algorithm implementations.

The complexity of SPP relies on several factors: the size of the Cloud

57


data centre, the number of SaaS components, SaaS competing resource re-

quirements, SaaS interactions between its components and SaaS interactions

with data components. The resource requirements that are considered in this

problem are those of processing capacity, memory requirement and storage re-

quirement. These resource-level requirements will be treated as constraints in

this problem. The communication between SaaS components will be depicted

through the SaaS work�ows. It is assumed that a composite SaaS may contain

more than one work�ow, and each work�ow may have multiple execution paths.

These paths can be executed in parallel. These communications will be for-

mulated in several numerical attributes and these numerical attributes will be

included in the decision process of the placement problem. The SaaS commu-

nication between components and their interaction with their data component

are based on the bandwidth and latency functions of the Cloud network. The

problem formulation of SPP is de�ned in detail in the next section.

3.2 Problem Formulation

Given a set of computation servers with their resource capacities and virtual

machines, storage servers with their storage capacities, the Cloud communi-

cation network with its links, and the composite SaaS with its requirements

and work�ows, the objective is to determine the placement of each SaaS ap-

plication's component onto the servers (virtual machines) and each SaaS data

component onto the storage servers, such that the performance of the SaaS

is optimal based on its total execution time, while satisfying its constraints.

These inputs, objectives and constraints can be formulated as below:

Input

1. A Cloud data centre, DC = 〈CS ∪ SS, E〉 , where

• CS = {cs1, cs2, ..., csn} denotes the set of all computation servers

in DC, and n is the number of computation servers. The resource

capacities and virtual machines (VMs) of each computation server

are represented in a tuple 〈pci,memi, diski, V MCi〉, 1 ≤ i ≤ n,

where pci is the processing capacity, memi is the memory, diski

is the disk storage capacity, and VMCi is the set of VMs for csi.

58

3.2. Problem Formulation

VMCi ⊆ VM where VM is the set of all virtual machines. Each

VM is de�ned as vmij = 〈pcij,memij, diskij〉, j ∈ N, where pcij is

the processing capacity, memij is the memory, and diskij is the disk

storage capacity.

• SS = {ss1, ss2, ..., ssm} denotes the set of all storage servers in DC,

and m is the number of storage servers. The resource capacities of

each storage server are represented in a tuple 〈diskSSi〉, 1 ≤ i ≤ m,

where diskSSi is the disk storage capacity.

• E is the set of undirected edges connecting the vertices, if and only if

there exists a communication link transmitting information from vi

to vj, where vi, vj ∈ CS∪SS. Bvi,vj : E → R+and Lvi,vj : E → R+

are the bandwidth and latency functions of the link from vi to vj

respectively.

2. A set of composite SaaS, S = 〈AC ∪ DC, DAC, DDC〉, where

• AC = {ac1, ac2, ..., acx} denotes the set of all application compo-

nents in AC, and x is the number of application components. The

resource requirements for each component represented in a tuple

〈pcReqi,memReqi, sizei, amountRWi〉, 1 ≤ i ≤ x, where pcReqi is

the requirement for processing capacity, memReqi is the memory

requirement, sizei is the size of the component for disk storage re-

quirement, and amountRWi is the amount of read/write to other

communication components.

• DC = {dc1, dc2, ..., dcy} denotes the set of data components for S,

and y is the number of data components. The resource requirements

for each component represented in a tuple 〈sizeDCj〉, 1 ≤ j ≤y, where sizeDCj is the size of the component for disk storage

requirement.

• S work�ows are modelled by directed acyclic graphs (DAGs), DAC

is the set of dependencies between application components where

DAC = AC × AC and DDC is the set of dependencies between

application components and data components where DDC = AC ×DC .

59


Objective To �nd the placement plan of application components onto vir-

tual machines:

P : AC → VM (3.1)

where aci 7→ P (aci) = vmk, 1 ≤ i ≤ x, 1 ≤ k ≤ j, and the placement of data

components onto storage servers,

L : DC → SS (3.2)

where dcx 7→ L(dcx) = ssz, and 1 ≤ x ≤ y, 1 ≤ z ≤ m such that the

placements minimise the total execution time of the SaaS, TET (S), that is,

min (TET (S)) (3.3)

while satisfying the constraints that are de�ned in the next section. The

calculation of TET (S) is presented in Section 3.4.1.

Constraints

1. Application components resource constraints: The placement of applica-

tion components onto the VM is subject to the VM capacities. Equations

3.4 to 3.6 denote the constraints for processing capacity, memory capa-

city and disk capacity for all VM respectively.

∀vmi∈VM

∑acj∈AC

pcReqacj ≤ pcvmi| P (acj) = vmi (3.4)

∀vmi∈VM

∑acj∈AC

memReqacj ≤ memvmi| P (acj) = vmi (3.5)

∀vmi∈VM

∑acj∈AC

sizeacj ≤ diskvmi| P (acj) = vmi (3.6)

2. Data components resource constraint: The placement of data compo-

nents onto storage servers is subject to the capacity of the storage servers.

Equation 3.7 denotes the constraints for disk capacity for the storage ser-

vers.

60

3.3. Related Work

∀ssi∈SS∑

dcj∈DC

sizeDCdcj ≤ diskSSssi | L(dcj) = ssi (3.7)

3.3 Related Work

This section reviews the two closely related problems with SPP: component

placement and task assignment. The former problem is emphasised more than

the latter, since it shares more similarities with SPP. The formulations and

solutions proposed from these problems are analysed and compared to provide

an overview of the areas that the problems tackle, which, in turn, justi�es the

need for a new e�cient placement algorithm for solving SPP.

In the existing literature, CPP can be further divided into two categories:

1) online CPP and 2) o�ine CPP. The term `online CPP' refers to the place-

ment problems of short-lived applications and it is solved during runtime [86].

As such, solutions for online CPP often emphasise the resource consumption

of an application [91], the load balancing between servers [84][131], and the

behaviour of the application during its run time [87]. The timescales for the

placement process are usually done in seconds to minutes, and for the o�ine

CPP, the placement of the application is made at the initial stage of the appli-

cation deployment and takes minutes to hours to complete [146]. O�ine CPP

often looks into the application's requirements and its policies when doing the

placement [91][146]. This section will discuss CPP in more detail, mainly in

three aspects: 1) the problem formulations, 2) the application's constraints,

and 3) the technique used.

Several existing studies formulated CPP as a resource optimisation pro-

blem [84][87] and also as a variant of the multiple knapsack problem [135].

These formulations aim to maximise the application performance in a hosting

platform and, at the same time, satisfy the resource constraints. The resource

constraints in these formulations refer to the availability of resources, such as

CPU, memory and network bandwidth to the application. Some of the exis-

ting studies focus on managing a single resource only, and some allow multiple

types of resource to be managed. Karve et al. [84] divided these resources

into two categories: load dependent and load independent. Load dependent

resources primarily depend on the intensity of the application load, such as the

CPU, while load independent resources do not depend strongly on the current

intensity of the application workload, such as memory. Low [103] emphasised

61


the network bandwidth consumption in formulating the problem, considering

the communication tra�c that will occur between the application's compo-

nents. Existing studies show that there are some common elements, such as

resources and network topology, which need to be formalised in any placement

problem, and that these can be adapted to this research. However, a formu-

lation is mainly dependent on the objective function of the problem itself. As

such, more work needs to be done on the formulation of the data placement of

an application, since all approaches focus on the placement of the application's

components only, with no regard for the placement of the application's data.

Zhu [146] addresses the placement problem by not limiting the application's

constraints to the resource level. He included storage access requirements for

each component in an application where these components may need to ac-

cess their data �les located somewhere in storage servers during execution.

The proposed placement method considered this factor during the placement.

However, the location of the data in Zhu's work is already known prior to the

placement process. Zimmerova [147] proposed a placement method that focu-

sed on resolving the interaction aspect between components. The interactions

are captured using an automata language, and the placement method is based

on the cost of interaction between components. Zimmerova's proposed method

is to be integrated with an existing method on non-interaction aspects. Re-

search similar to this was done by Kichkaylo et al. [87], where the application

is de�ned by a set of interface types and component types. Each component

speci�es the required service or component for its execution through the inter-

face. From these studies, it can be seen that the constraints of the application

are not strictly related only to resources. Other application's constraints need

to be satis�ed in the placement as well. This research is concerned with the

SaaS application as well as the data components constraints, where the data

components are placed simultaneously with the SaaS components. So far, no

existing studies address this problem in their solutions.

Resource allocation techniques that aim to satisfy an application's requi-

rements in component placement problems can be considered as NP-hard pro-

blems, which have been discussed in existing studies that are mostly based on

heuristic algorithms [84][91][131][135]. Urgaonkar [135] uses the �rst-�t based

approximation algorithm in placing component applications in an o�ine CPP.

The algorithm places the component at the �rst server found that can satisfy

62

3.3. Related Work

its demand. Karve [84] also applied a similar heuristic to his o�ine CPP. His

work follows an intuitive rule, that is, to place the application according to

the memory's demand �rst, rather than the CPU demand. The density of the

application, as well as the servers are also considered in Karve's solution. A

placement concerned with SaaS, presented by Kwok and Mohindra [91], consi-

ders a placement problem for SaaS components in a multi-tenant architecture.

The placement of the components is made within a set of available servers,

and the main objective is to optimise the resource usage in each server. The

principal rule of the optimisation is straightforward, in that a new instance

of a component will be deployed in a server that has the smallest residual

resource left after having the instance. This reserves servers that have larger

residual resources, such as those that have a higher resource demand. This

work also proposes a resource computation model that calculates the resource

demand for an upcoming tenant, including the storage requirement. Although

this work is concerned with SaaS deployment, it is more focused on the multi-

tenant resource model and does not consider the SaaS data deployment in

the network. Other studies reviewed the problem as being mathematical pro-

gramming problems [146] and planning problems [86]. However, these studies

do not deal with the placement of a component and its data for SaaS in a

Cloud network. They focus primarily on the placement of the application's

components to available servers, based on physical resources only.

Stone [130] �rst introduced the problem of TAP, de�ning it as a task as-

signment problem in a distributed system subject to a set of constraints. He

proposed two algorithms for TAP, with the aim being to minimise the inter-

processor communication among components of an intermediate coupled sys-

tem as well as to minimise the cost of computation used. The problem was then

picked up by researchers, and, to date, there has been a signi�cant amount of

research done proposing a solution for this problem. Some of the research is

discussed in this section, highlighting the techniques used as well as its problem

formulation.

One example of early research for TAP was done by Ka�l and Ahmad [81],

who proposed A* heuristic algorithm to solve the problem. Two variants of the

algorithm were implemented, one using sequential search and the other using

parallel search. Experimental results show that the sequential version pro-

duces an improvement in terms of the quality of the solutions compared with

63


existing studies, while the parallel version o�ers a speeding-up of the process.

More recent research that also used heuristics to solve TAP was done by Zao

et al. [148], who proposed a global harmony search algorithm to minimise the

sum of communication between the task and the processing costs of all tasks.

Harmony search algorithms mimic the process of a musician �nding the perfect

state of harmony [95]. They improvised the classical harmony search by modi-

fying the step such that the new harmony can mimic the global harmony in the

harmony memory. Genetic mutation is also applied to enhance the probability

of escaping from local optima. The result of this modi�cation shows that the

algorithm has a strong capacity for space exploration and demonstrated high

e�ciency in solving the problem.

Salcedo-Sanz et al. [125] presented a novel formulation of TAP in which

a resource constraint is introduced. This resource constraint is a limit to the

number of tasks that each processor can handle. In their paper, they propo-

sed two hybrid metaheuristics. Both approaches implement a hybrid neural

network to handle the problem's constraints, combining it with a genetic al-

gorithm and with simulated annealing in order to improve the quality of the

solutions produced. Other research that have also used a meta-heuristic ap-

proach include tabu search [116], genetic algorithm [4][5], simulated annealing

[11], particle swarm optimisation [82] and neural networks [145]. All the pro-

posed algorithms have shown good results, subject to their constraints and

objectives; however, these solutions cannot be immediately applied to solve

the composite SaaS placement problem due to the di�erent requirements and

complexities that the SPP introduced.

To summarise, this section has reviewed studies on the component pla-

cement problems and the task assignment problem. It has focused on three

main aspects: the problem formulation, the application constraints and the

techniques used. The existing placement methods that have been proposed

achieved good results concerning their objective; however, none of the existing

methods of CPP and TAP include data placement in their solutions. In ad-

dition, the SPP has more constraints than the existing two problems. In the

SaaS placement case, the data as well as the components will be located on

the Cloud provider's servers. As such, Cloud providers must apply a strategic

placement method in order to ensure that the components and the data are

well placed and that the SaaS performance is optimised.

64


3.4 Evolutionary Algorithms

As discussed in Chapter 2, the size of a Cloud's data centre is huge: there are

massive resources involved in Cloud resource management [1][20][47]. Thus,

SPP can be considered as a large-scale and complex combinatorial optimisation

problem that deals with the allocation of servers to components, subject to a

set of constraints. It is also a decision-making process, with the goal being to

optimise the SaaS performance.

The SPP can be broken down into two interrelated tasks � the placement

of application components into VMs and the placement of data components

into storage servers. The performance of the SaaS is evaluated based on the

combined solutions from these two tasks. The goal is to optimise the SaaS

performance based on its total execution time. To determine the total execu-

tion time, four numerical attributes are introduced. These attributes de�ne

the execution time (in seconds) of a component in a selected VM/server as

well as the total execution time of the composite SaaS that is being placed.

Two techniques are proposed in this research to solve the problems. The

�rst technique employs the classical genetic algorithm, in which both tasks are

treated as one large problem. The candidate solutions from both tasks are

combined from the start, and evolve together throughout the process to �nd

an optimal solution. The second technique uses a di�erent strategy in which

candidate solutions for both tasks are encoded and dealt with separately, such

that each subpopulation can evolve on its own. The evaluation of a candidate

solution is based on its performance when combined with a representative

solution from the other subpopulation and vice versa. Two models of the

cooperative co-evolutionary algorithm are implemented using this strategy �

the iterative and parallel model.

The next section presents the attributes and process involved in determi-

ning the SaaS execution followed and explains the three algorithms in detail.

3.4.1 Determining the SaaS Total Execution Time

The total execution time of a composite SaaS is calculated based on four nu-

merical attributes: a) the time taken for transferring data between the storage

servers and the VM, b) the processing time of a component in a selected VM,

c) the execution time of a path in the SaaS work�ow, and d) the sum of the

65


execution time of the critical path of each work�ow multiplied by its weighting.

Following are the descriptions of these attributes:

• The data transfer time (DTT): The estimated time taken for transferring

data between storage servers and VMs. Given a current placement for

a component, ack, DTT is calculated based on amountRW ack , the total

bytes of amount of read/write task of ack, Bvi,vj , bandwidth of the links

involved, and Lvi,vj , the latency that may occur in those links.

DTT (ack) =∑

vi,vj∈E

amountRW ack × 8

Bvi,vj

+ Lvi,vj (3.8)

• The processing time (PT): The processing time for a component in a

selected VM. This is based on the processing requirement a component,

pcReqack , the processing capability of the selected VM, pcvmj, and the

value of DTT (if there is any). If a component accesses more than one

storage server, only the maximum value of these attributes will be consi-

dered.

PT (ack) =pcReqackpcvmj

+max(DTT ) (3.9)

• The execution time (ET): The execution time of a path in a work�ow.

This is based on the sum of PT of each component in a path. The ET

is de�ned as:

ET (pathk) =∑

ac∈pathk

PT (aci) (3.10)

• The total execution time (TET): The total time taken in execution for a

composite SaaS being placed in the Cloud. From Equation 3.10, the ETs

for all paths in the SaaS work�ows are obtained. These values are used

to determine the critical path of a work�ow if the work�ow has more

than one path (detailed explanations on the critical path determination

are presented next). Then the TET is de�ned by the sum of the ET of

the critical path of each work�ow multiplied by its weighting as shown

in Equation 3.11.

TET (S) =∑q

i=1ET (criticalpath)×WFwfi (3.11)

66


Figure 3.1: An example of a composite SaaS with two work�ows

A composite SaaS is modelled by a DAG and may have more than one work-

�ow. These work�ows consist of several components, each of which represents

a speci�c task for a particular function. A work�ow may have multiple paths

that may run in parallel. Figure 3.1 shows an example of a SaaS that has two

work�ows. In the example, work�ow 1 has more than one path from the `Start'

component to the `Finish' component. In this case, a critical path algorithm

will be applied.

In Figure 3.1, a circular node ack represents a SaaS application component

where 1 ≤ k ≤ |AC|. The time consumed to execute in a particular VM

is denoted at the lower half of the circle. This is calculated based on the

processing requirement and processing capacity of the host VM. A square node

with an arrow to a component represents a data component, dci, at a storage

server. The time taken for the data transfer process from the computation

server to the storage server is depicted at the edge. The calculation for the

time taken is de�ned in Equation 3.8.

To determine the critical path, the graphs in Figure 3.1 are converted to

super graphs, as illustrated in Figure 3.2. The super graphs combine a circular

node in Figure 3.2 with its corresponding square node. If there is more than

one square node involved, the maximum value is selected. This combination

indicates the component's processing time (PT), as described in Equation 3.9.

The value in the lower half of the circle depicts the value of PTs.

For each path in the super graphs, the execution time of a path (ET) is

computed based on Equation 3.10. This value will be used to determine the

critical path of a work�ow in order to obtain the ET of each SaaS work�ow.

The total execution time (TET) for the whole SaaS will then be computed

67


Figure 3.2: An example of a supergraph for a composite SaaS

by Equation 3.11. This is based on the ET for the critical paths and the

weighting. This value will be used in the placement algorithm to determine

the optimal placement solution for the composite SaaS.

3.4.2 A Classical Genetic Algorithm

A classical genetic algorithm, one method in evolutionary computation, is a

search heuristic inspired by the theory of evolution. It is a population-based

technique that encodes a set of candidate solutions for the problem, and that

evolves the candidate solutions through genetic operations to �nd the optimal

solution.

A classical genetic algorithm (CGA) is developed for SPP. The population

of the CGA consists of a set of candidate solutions that represent the place-

ment plans for both application components and data components. To address

the resource constraints that are formulated in the problem, the CGA uses a

penalty-based �tness function in which the function rewards feasible solutions

and penalises infeasible ones. The population is evolved through a number of

generations by means of the application of crossover, mutation and selection

operations.

Algorithm 1 describes the CGA. The best �tness and the best placement

plan are initialised in Steps 1 and 2. In Step 3, the initial population that

consists of a placement plan for application components and data components

is generated randomly. Based on the encoding scheme used, there is a possibi-

lity that the generated population contains invalid genes. In this situation, the

chromosome will be repaired. This is done in Steps 5 and 6. An explanation of

68


such a scenario is presented in a later section. Steps 7 to 11 are responsible for

evaluating the �tness of each candidate solution, in which the best placement

plan and the best �tness found are stored. Steps 12 to 15 are for the selection,

crossover and mutation operations. The following subsections will describe the

CGA in detail.

Algorithm 1: The classical genetic algorithm (CGA)

1 bestF itness = 02 bestP lacementP lan = 03 create an initial population Population of PopSize individuals, thatconsists of solution for application components placement and datacomponents placement

4 while termination condition is not true do5 if X contains invalid genes then6 Repair(X)

7 for X ∈ Population do

8 Calculate X �tness value, F (X), penalised if X violates SaaSresource requirement constraint

9 if F (X) > bestF itness then10 Replace bestF itness11 bestP lacementP lan = X

12 Select individuals from the Population based on roulette wheelselection

13 Probabilistically apply the crossover operator to generate newindividual

14 Probabilistically select individuals for mutation15 Use the new individuals to replace the old individuals in the

Population

16 output bestF itness17 output bestP lacementP lan

Genetic Encoding

A chromosome in the CGA represents a placement plan for the composite

SaaS. It consists of two compartments. The �rst compartment contains n

genes, each of which corresponds to an application component, representing

the VM, where the application component would be placed in the placement

plan of the SaaS and where n is the total number of application components in

69


the SaaS. The second compartment holds m genes, each of which corresponds

to a data component used in the SaaS, that stands for the storage server in

which the data component would be stored in the placement of the SaaS. Each

gene in the chromosome is represented in a triple < C,R, S >, where C, R and

S are the identi�cations for continent, region and server, respectively. Figure

3.3 shows a gene encoding and an instance of the chromosome representation,

with n application components and m data components in the SaaS.

Figure 3.3: An example of gene and chromosome encoding scheme

Infeasible Encoding Problem

The representation naturally maps a composite SaaS placement plan into a

chromosome of the CGA. However, it has a de�ciency. The individuals gene-

rated randomly in the initial population, and the individuals generated by the

genetic operators (discussed in the following section), may not be feasible. For

example, on continent one, where there are only 10 regions, the genetic opera-

tor may produce an individual < 1, 11, 1 >, indicating that the corresponding

application component or data component would be located at the 11th region

of the 1st continent, which does not exist. In order to handle the infeasible

encoding problem, an infeasible encoding repairing technique is developed.

The repairing technique performs a simple check on each gene to �nd any

invalid codes for servers. Each gene should contain a set of three valid integers

that represent an existing server in the Cloud data centre. If any of these

integers is invalid, that is, an invalid code for continent, region or server,

another integer will be randomly generated based on a correct range of the

codes.

Genetic Operators

Crossover The crossover operation is a classical one-point crossover. The

point of crossover is between the segments of genes in a chromosome. The

70


Figure 3.4: An example of the crossover procedure

crossover operation combines segments from two selected parents and produces

two children. The top two �ttest among the parents and children are selected

for the next generation. Figure 3.4 illustrates the crossover operation.

Mutation To promote further exploration in the search space, a mutation

operator is introduced in order to keep the diversity of the genes in the po-

pulation. The mutation operator is a knowledge-based operator, changes the

computation server of a particular component to another computation server

such that the new computation server is located closely to the storage server

that has the component's data. By doing this, the data transfer time from the

storage servers to the computation servers can be minimised. Hence, the total

execution time of the SaaS is reduced.

The mutation operation is applied to selected genes of the application com-

ponents compartment in a selected chromosome. The genes and chromosomes

are selected randomly. As described earlier, the gene represents the location of

a VM that holds a particular SaaS component. The operation is conducted by

randomly selecting any integer in a gene and replacing it with another server

that is closer to its corresponding data component. Figure 3.5 illustrates the

mutation operation.

Fitness Function

The main attribute for the �tness function evaluation is the total execution

time (TET) of the composite SaaS. The calculation for TET is de�ned in

Equation 3.11. The problem has four resource constraints, as formulated in

Equations 3.4 to 3.7. The chromosomes that were generated may violate these

constraints, making the placement infeasible. However, to fully discard these

chromosomes from the population is una�ordable, as the chromosome may

71


Figure 3.5: An example of the mutation procedure

contain some useful building blocks in its genes. This is important in order to

produce �tter children for the next generation. Therefore, to handle this situa-

tion, the following strategy is applied to these infeasible chromosomes. Any

violations occurring in the chromosomes for any constraints will be counted as

1. The value is accumulated and stored in CVi in which i represents the ID of

the resource constraint type. A penalty will be imposed on the �tness value

of chromosomes that have violated, such that any infeasible chromosome will

always have a lower �tness value than any feasible chromosome. The �tness

function is de�ned as follows:

Fitness(X) =

TET ∗

TET (X)×2 + 0.5,∑

i∈|CV | CVi = 0

TET ∗

TET (X)×2 ×(

1∑i∈|CV | CVi(X)

), otherwise

(3.12)

where TET ∗ is the minimum value of the total execution time in the popula-

tion, and is de�ned as:

TET∗ =∑

X∈Population

min(TET (X)) (3.13)

Equation 3.12 guarantees that feasible chromosomes always have a �tness

value greater than 0.5 and infeasible chromosomes always have a �tness value

less than 0.5. It also guarantees that for infeasible chromosomes, the more

constraints are not satis�ed, the less their �tness values are.

72


3.4.3 A Cooperative Co-evolutionary Algorithm

Section 2.1.3 in Chapter 2 has outlined the basic layout for a classical gene-

tic algorithm (CGA) as well as for a cooperative co-evolutionary algorithm

(CCEA). It has been proven in the existing literature that CCEA is more e�-

cient than the classical genetic algorithm for complex combinatorial problems

like SPP [101][118]. This has served as motivation for an investigation of the

applicability of the CCEA to SPP.

The CGA presented in the previous subsection combined the placement for

application components and the placement for data components in its solution

encoding. Thus, the evolvement process of the solution through the genetic

operations, selection operations process and �tness evaluation process are done

together for both tasks. The main distinction between the CGA and the CCEA

is that the latter divides the candidate solutions into a number of groups

according to the tasks, and the groups of solutions are then evolved into their

own group to solve the designated task. In this way, the search process gets

a chance to exploit its own search space instead of tackling the entire search

space as in the CGA. Since each search space is smaller than the entire search

space, CCEA may �nd better solutions faster than the CGA.

In the CCEA, the core idea is that several subpopulations representing

solutions for a task of the problem are co-evolved together. Each subpopula-

tion constitutes a partial solution for the problem, and its combination with

a solution from all other species generates a complete solution of the pro-

blem. Although the subpopulation evolves independently, the collaboration

with other subpopulations in order to form the complete solution is crucial,

as this collaboration serves as guidance for the subsequent evolvement pro-

cess. Thus, in CCEA, in addition to the basic processes such as chromosome

encoding, selections, and genetic operations, a number of other factors play

a signi�cant role in the algorithm's performance, such as the decomposition

of the problem and the collaboration strategies. In the following subsections,

each of these processes is discussed.

Problem decomposition and genetic encoding

The decomposition of the problem can be done either statically, though par-

titioning the problem manually and with the number of subpopulations �xed,

73


Figure 3.6: An example of chromosome for subpopulation 1 and 2

or dynamically, where the partition process and the number of the subpopula-

tions are both determined during the run time [120]. Since the SPP consists of

two dependent component placement tasks, it is natural to consider the static

decomposition with a �xed number of subpopulations.

Based on the characteristics of SPP, the problem is decomposed into two

collaborating sub-problems: 1) the placement of SaaS application components

in VMs, and 2) the placement of the SaaS data components in storage servers.

Each sub-problem is assigned to the optimisation of a variable's performance,

that is, SaaS application components or data components. The candidate

solution for each sub-problem is represented in a subpopulation.

The CCEA solutions' representation is split into two subpopulations based

on its components' types. The �rst subpopulation contains n genes, each of

which corresponds to an application component, representing the computation

server in which the software component would be placed in the placement

plan, where n is the total number of application components in the SaaS. The

second subpopulation is encoded in similar fashion for data components and

its corresponding storage server. Each gene in the chromosome is represented

in a triple < C,R, S > , where C, R and S are the IDs for the continent, region

and server, respectively. Figure 3.6 illustrates examples for the encoding for

both subpopulations. Subpopulation 1 represents the chromosomes for the

application component placement sub-problem; Subpopulation 2 represents

the chromosomes for the data component placement problem.

The collaboration method and the �tness function

The collaboration between subpopulations is the essence of the CCEA, dif-

ferentiating it from the CGA. The collaboration occurs when evaluating the

�tness of individuals in each subpopulation, where the �tness of the individual

is evaluated on how well it cooperates with members in other subpopulations

74


in solving the problem. There are a number of strategies to implement the

collaboration method. Two basic strategies were suggested by De Jong and

Potter [119]: 1) a single best collaboration strategy, and 2) a random/best

collaboration strategy. In the �rst strategy, the subpopulation under consi-

deration is combined with the best solution from the other populations. In

the second strategy, the subpopulation is combined with either the best or a

random solution from another population. The best combination with a hi-

gher �tness value will be selected. An initial experiment was conducted to

determine which strategy is more bene�cial for the SPP. Based on the result,

the �rst strategy gave a better overall solution than that of the random one.

Therefore, the single best strategy is applied for the collaboration method of

the CCEA.

In each subpopulation, the collaboration takes place prior to the �tness

evaluation. During the �rst generation of each subpopulation, where each

chromosome is randomly generated, it is not possible to apply best member

collaboration since there is not yet any �tness evaluation. Hence, random

member collaboration is performed in the �rst generation. After that, the

best member collaboration technique, as described earlier is adopted. In each

generation, a chromosome with the best �tness is selected from another sub-

population to be the representative in the �tness evaluation.

The �tness function is based on the total execution time of the compo-

site SaaS, as de�ned in Section 3.4.1. Unlike in the CGA, which applies the

penalty-based �tness function in handling the constraints, CCEA uses a repair-

based �tness function in which each chromosome will be repaired if it violates

any of the resource requirement constraints. For subpopulation 1, the appli-

cation component placement sub-problem, each chromosome has to comply

with the processing capacity, memory and disk storage constraint of the VMs,

while for subpopulation 2, each chromosome has to comply with the disk sto-

rage constraint of the storage servers. The repair-based method is adopted to

ensure that the �tness value fully represents the cooperativeness of a parti-

cular chromosome with its counterparts, without having to worry about the

infeasible combination. In addition, the number of constraints of the two

subpopulations is di�erent: subpopulation 1 has three constraints while sub-

population 2 has one. It would be a complex process to determine the penalty

value for the �tness evaluation, hence, a simpler method is applied. Equation

75


3.14 de�nes the �tness function for the CCEA:

Fitness(X) =TET (X)

TET ∗(P )(3.14)

where TET ∗ is the minimum value of the total execution time in the subpo-

pulation, SP , de�ned in Equation 3.13.

The CCEA models and algorithms

So far, as described in previous subsections, the CCEA divides the SPP into

two smaller sub-problems. The solutions for these two optimisation sub-

problems will be evolved interchangeably and cooperatively in two separate

subpopulations in the CCEA. The subpopulations are listed below.

1. Subpopulation 1: A set of individuals that serve as candidate solutions

for the placement problem of the SaaS application component. The

placement must comply with the VM resource capacity.

2. Subpopulation 2: A set of individuals that serve as candidate solutions

for the placement problem of the SaaS data component. The placement

must comply with the storage servers' disk capacity.

The evolution of each subpopulation is handled by the standard GA. A com-

plete solution is obtained by combining the individuals from each subpopu-

lation, based on best �tness solution strategy. These individuals are scored

based on the �tness of the complete solution in which they participate. Thus,

the �tness is computed by estimating how well an individual cooperates with

the best representative from another subpopulation to produce good solutions.

Two models of CCEA were developed � an iterative CCEA in which each

subpopulation is executed iteratively starting from subpopulation 1, and a

parallel CCEA in which both subpopulations are executed in parallel. The

following sections provide further details on these models.

Iterative CCEA Algorithm 2 describes the pseudocode of the iterative

CCEA. Step 1 to step 3 is the initialisation of variables. Both populations

are initialised randomly in Steps 4 and 5. If the generated values are invalid or

if they violate any of the constraints, the chromosome will be repaired. This

is performed in Steps 6 and 7. Step 8 assigns a random chromosome from

76


subpopulation 2 to the bestSolution variable, which acts as a bu�er. This

bu�er stores the best solution of a subpopulation, which will be used in the

collaboration process. In the �rst generation, the solution will be picked ran-

domly. The algorithm will start the GA process starting from subpopulation

1. Steps 12 to 17 are responsible for evaluating the �tness of each chromosome

in the subpopulations. The evaluation begins with the combination process

of the chromosome under consideration with the bestsolution (Step 12); then

the �tness value is calculated (Step 13). If the �tness value is higher than the

current best �tness value, the chromosome, the combination, as well as the

calculated �tness value will be recorded (Step 14 to 17). In this case, the best

chromosome recorded is considered to be the best solution found so far for this

subpopulation, and so will be used as the representative in the collaboration

process with another subpopulation in the next iteration. The subpopulation

then undergoes the genetic operations in which �tter individuals are copied

to the next generation (Step 18 to 21). These processes are repeated with

subpopulation 2, and continued iteratively until the termination condition is

met.

Parallel CCEA In the parallel model, the computation of the problem is

separated into two unsynchronised and parallel subcomputations � the place-

ment of the application component, and the placement of the data components.

Similar to the iterative model, each subcomputation is evolved by a standard

GA. However, unlike the iterative CCEA, in which both subpopulations share

the bu�er for the best solution and update it in turn, the parallel CCEA uses a

bu�er that has two units: one unit stores the best solution from subpopulation

1; the other, that from subpopulation 2. At the end of each subpopulation's

generation, the GAs update their best solution in the respective bu�er. Since

the two GAs are not synchronised, one GA may update its best solution in

the bu�er more frequently than the other during the computation. Figure 3.7

shows the unsynchronised parallel model for parallel CCEA.

Both subpopulations have their own standard GA that caters to the op-

timisation and evolvement of a subproblem. These GAs are developed based

on the iterative GA presented in Algorithm 2. Algorithm 3 describes the GA

for the placement of the application component subproblem. In the algorithm,

the subpopulation for application component placement solutions is initialised

77


Algorithm 2: The iterative CCEA

1 bestF itness = 02 bestSolution = 03 bestP lacementP lan = 04 for subPopulation ∈ Population do

5 randomly initialise subPopulation6 if X ∈ subPopulation contains invalid genes or violates any

constraints then7 Repair(X)

8 Randomly assign an individual from subPopulation 2 to bestSolution9 while termination condition is not true do10 for subPopulation ∈ Population do

11 for X ∈ subPopulation do

12 Combine X with bestSolution13 Calculate X �tness value, F (X)14 if F (X) > bestF itness then15 Replace bestF itness16 bestP lacementP lan = X ∪ bestSolution17 bestSolution=X

18 Select individuals from the subPopulation based on roulettewheel selection



Population

22 output bestF itness23 output bestP lacementP lan

78


Figure 3.7: Parallel CCEA model

randomly and repaired in Steps 3 to 6. Then each individual will undergo

a �tness evaluation by combining the individual with the best solution from

the other subpopulation. This is obtained from the bu�er, as shown in Step

8. Based on the �tness evaluation, the best solution will be recorded (Steps

11 to 13), and the genetic operations will be carried out (Steps 14 to 17).

The best solution found will be updated in the bu�er. Similar processes are

implemented for the other subproblem. This is presented in Algorithm 4.

Based on these two algorithms, the parallel CCEA is as Algorithm 5. The

GAs for each subpopulation are executed in parallel until the termination

condition is met (Step 3). Then, Steps 4 and 5 combine the best solution to

the application component placement problem and the best solution to the

data component placement problem in the bu�er to form a solution to the

SaaS placement, and output it.

Genetic Operators

The genetic operators for CCEA are the same as in the CGA, except that the

operations occur only in the same subpopulation.

The crossover operation is a classical one-point crossover between the seg-

ments of genes in a chromosome. This operation combines segments from two

selected parents and produces two children. The top two �ttest among them

are selected into the next generation. The mutation operator applied is a

79


Algorithm 3: The placement of the the application components subpro-blem in parallel CCEA

1 bestF itness = 02 bestSolutionAC = 03 for X ∈ subPopulation1 do

4 randomly initialise subPopulation1

5 if X ∈ subPopulation1 contains invalid genes or violates anyconstraints then

6 Repair(X)

7 while termination condition is not true do8 Get the best solution to the data component placement problem

from the bu�er, bestSolutionDC for X ∈ subPopulation1 do

9 Combine X with bestSolutionDC

10 Calculate X �tness value, F (X)11 if F (X) > bestF itness then12 Replace bestF itness13 bestSolutionAC=X

14 Select individuals from the subPopulation1 based on roulette wheelselection



Population18 Update the best application component placement solution,

bestSolutionAC , in the bu�er.

80


Algorithm 4: The placement of the data components subproblem inparallel CCEA

1 bestF itness = 02 bestSolutionDC = 03 for X ∈ subPopulation2 do

4 randomly initialise subPopulation2

5 if X ∈ subPopulation2 contains invalid genes or violates anyconstraints then

6 Repair(X)

7 while termination condition is not true do8 Get the best solution to the data component placement problem

from the bu�er, bestSolutionAC for X ∈ subPopulation2 do

9 Combine X with bestSolutionAC

10 Calculate X �tness value, F (X)11 if F (X) > bestF itness then12 Replace bestF itness13 bestSolutionDC=X

14 Select individuals from the subPopulation2 based on roulette wheelselection



Population18 Update the best application component placement solution,

bestSolutionDC , in the bu�er.

Algorithm 5: The parallel CCEA

1 bestP lacementP lan = 02 while termination condition is not true do3 run Algorithm 3 and Algorithm 4

4 bestP lacementP lan = bestSolutionAC ∪ bestSolutionDC

5 output bestP lacementP lan

81


random mutation operator in which the selected genes in the selected chromo-

somes are assigned a new valid value of the server's continent, region or site.

The mutation operation is done for both subpopulations.

Since the crossover and mutation operators work within the same subpopu-

lation, the exploitation and the exploration of the �tness landscape are carried

out in a local search space [119]. The process of applying the operators locally

helps to build better subpopulations, which also improves the quality of the

combined solution.

3.5 Evaluation

The three algorithms that have been developed for SPP are evaluated based on

the quality of the solutions produced as well as on the scalability and e�ecti-

veness of the algorithms. The quality of the solution evaluation is investigated

by comparing the proposed algorithm with a generic placement heuristic. For

scalability and e�ectiveness, the algorithms are executed in a number of test

problems with di�erent sizes of Cloud servers and SaaS components. The

test problems, the comparison heuristics, and the results of the evaluation are

presented in detail in the following subsections.

3.5.1 Test Problems

The performance of the proposed algorithms depends largely on the size and

the complexity of the SPP. The size of the SPP is determined by two factors �

the number of Cloud servers that a problem has, and the number of the SaaS

components under consideration. The complexity of the problem depends on

the interdependencies that the composite SaaS has between its components.

Indirectly, the number of SaaS components also contributes to the complexity

of the problem. Therefore, to ensure that these factors are taken into account,

two sets of test problems are created, as described below.

Test problems with di�erent numbers of Cloud servers

The �rst set of test problems includes �ve test problems with a di�erent num-

ber of Cloud computation servers and storage servers. For both servers, the

numbers range from 50 to 250. The attributes of the servers, including their

82

3.5. Evaluation

Table 3.1: Test problems with di�erent numbers of Cloud servers

Test ProblemTest Problem Characteristics

#Computation servers #Storage servers #Total servers1 50 50 1002 100 100 2003 150 150 3004 200 200 4005 250 250 500

Figure 3.8: An example of composite SaaS with �ve application and data components

processing capacity, memory capacity and storage capacity, are generated ran-

domly based on commercial servers by Hewlett Packard and IBM [55][63]. Each

computation server hosts a number of virtual machines. The communication

links between the servers are also generated randomly. Table 3.1 shows the

characteristics of the �ve randomly generated Cloud data centres. For this set

of problems, the number of SaaS application components and data components

is each set to 10.

Test problems with di�erent numbers of SaaS components

The second set of test problems consists of �ve test problems with a di�erent

number of SaaS application and data components. The number ranges from

5 to 25. Figure 3.8 illustrates an example of SaaS with �ve application com-

ponents and �ve data components. This serves as a building block for test

problems that have a greater number of components. The number of compu-

tation servers for these test problems is set to 100, and the number of storage

servers is also set to 100. Table 3.2 shows the �ve test problems with their

characteristics.

83


Table 3.2: Test problems with di�erent numbers of SaaS components


#Application components #Data components #Total1 5 5 102 10 10 203 15 15 304 20 20 405 25 25 50

3.5.2 A Hill Climbing Heuristic Algorithm

The composite SaaS placement problem is a new problem that introduces new

challenges to the existing placement problems. No solutions in the existing

research that can be used as a benchmark for the proposed algorithms. A

heuristic algorithm is therefore developed and specially designed to solve the

SaaS placement problem, to serve as a comparison for the proposed algorithms.

The developed comparison algorithm uses a hill climbing heuristic. Hill

climbing [124] is a search technique that starts with an arbitrary solution of the

problem, then attempts to �nd a better solution by changing a single element

in the solution with its neighbour. If the change produces a better solution, it

will be kept for the next iteration. The process will be repeated a number of

times, until a termination condition is met. Hill climbing is one of the most

widely used optimisation techniques due to its simplicity, in terms of its space

and time requirement, and also its design [78]. The main disadvantage of hill

climbing is that it is easily stuck at local optima rather than global optima.

To overcome this drawback, a number of hill climbing versions are introduced,

including stochastic hill climbing, in which the moves are operated randomly,

and best hill climbing, where all the neighbours for the selected elements are

generated and the best one will be chosen [9].

For this problem, a stochastic hill climbing is developed, as presented in

Algorithm 6. The implementation of the hill climbing begins with a random

placement for the initial solution shown in Step 1. In Step 2, the total exe-

cution time for the placement is calculated. A pair of SaaS components is

selected at random in Step 4. The pair consists of one application component

and its corresponding data component. The neighbours for the application

component are generated: these neighbours are the VMs that are located in

84

3.5. Evaluation

the same site or the same region as the current VM that hosts the application

component under consideration (Step 5). The neighbours of the data compo-

nents are generated in a similar fashion in Step 6. The current placement of

the components is changed with random values selected from the neighbour

sets. If these changes can improve the total execution time of the SaaS, the

placement changes will be kept (Steps 10 to 12), otherwise, the process will be

repeated until no improvement is found for 100 consecutive generations.

Algorithm 6: The hill climbing algorithm

1 Randomly initialise a solution, X2 Calculate the total execution time for X, TET (X) based on Equation11

3 while (count < 100) do4 Randomly select an application component, aci, and its

corresponding data component, dcj5 Ni = NEIGHBOUR(aci)6 Nj = NEIGHBOUR(dcj)7 Generate new placement for aci from NEIGHBOUR(aci)8 Generate new placement for dcj from NEIGHBOUR(dcj)9 Calculate the new total execution time, TET (X ′)

10 if (TET (X ′) < TET (X)) then11 Accept the placement changes12 count = 0

13 else

14 count = count+ 1

3.5.3 Experimental Results

To compare and evaluate the performance of the algorithms, the CGA, iterative

CCEA, parallel CCEA and hill climbing algorithms have been implemented

in Microsoft Visual C# 2010 and executed in desktop computers with 3.00

GHz Intel Core 2 Duo CPU and 4GB RAM. The parameter settings for the

three evolutionary algorithms are presented in Table 3.3. These parameters

are determined based on several initial experiments in which parameters that

yielded the best results are selected. The results of the evaluation will be

presented based on the test problems described in Section 3.5.1.

85


Table 3.3: Simulation parameters for the CGA, iterative CCEA and parallel CCEA

Parameter Value

Population size 100

Crossover rate 90%

Mutation rate 10%

Termination condition (# of generation withoutimprovements)

25

Experiments on the Number of Servers

These experiments on the number of servers are to investigate the impact of the

number of Cloud servers on the solutions' quality and the computation times

of the three proposed evolutionary algorithms, as well as on the hill climbing

heuristic. The test problems outlined in Section 3.5.1 were used. Since all al-

gorithms consisted of some stochastic elements in their implementation, each

of the test problems was executed 30 times. The objective of the problem is to

place the SaaS components onto the Cloud servers such that their performance

is optimised while satisfying all the constraints. As described earlier, the per-

formance of the SaaS is measured based on its total execution time. Table

3.4 shows the best, worst, average and standard deviation of the SaaS total

execution time and the algorithm's computation times, based on the results of

30 runs.

Based on the results, the shortest total execution time, which indicates the

best performance of the SaaS for all test problems, is achieved using the parallel

CCEA, followed by the iterative CCEA, the CGA and the hill climbing. The

best average values for all test problems are highlighted in boldface. The paral-

lel CCEA produced the best placement plan, with its average total execution

time being between 35% and 60% of the average total execution time of the

other algorithms. Figure 3.9 illustrates these results for the �ve test problems.

It can be seen that the performance of the composite SaaS degrades with the

increasing number of servers; this is because the search space gets larger. It

should also be highlighted that the gap in SaaS performance between the CGA

and the iterative GA is higher in larger test problems, inasmuch as the gap is

86

3.5. Evaluation

Table3.4:

Experim

entalresultsof

thehillclimbing(H

C),classicGA

(CGA),iterativeCCEA

andparallelCCEA

fortest

problems

withdi�erentnumbersof

Cloudservers

Test

Algorithm

TotalExecution

Time(seconds)

Com

putation

time(seconds)

Problem

Best

Worst

Avg

Std

Dev

Best

Worst

Avg

Std

Dev

1

HC

51.1

112.2

83.7

15.4

3.6

11.8

62

CGA

48.9

91.2

67.6

10.5

71.4

383.2

168.3

64.7

IterativeCCEA

48.1

83.3

66.8

7.3

94.6

440.4

249.9

82.2

ParallelCCEA

7.1

55.7

28.9

14.6

44.4

141.6

77.5

29.2

2

HC

125.5

252.5

198.7

32.1

8.3

24.6

14.2

4.5

CGA

99.1

226.2

147.3

26.7

347.4

1109.4

600

150.7

IterativeCCEA

97.4

175.4

122.7

15.5

681.7

2228.4

1130.1

367.4

ParallelCCEA

33.7

124

63.5

25.7

115.8

480

232.9

104.1

3

HC

242.4

494.9

386.6

58.8

1842

27.3

7.2

CGA

273.4

388.2

316.7

25.6

925.4

2665

1437.4

397.2

IterativeCCEA

202.9

368.3

286

41.4

712.8

3451.2

2296.3

661.9

ParallelCCEA

34.6

343

172.1

65.4

229.2

1302

489.6

255

4

HC

466.1

831.1

628.8

102.7

31.8

86.9

53.2

11.8

CGA

393.8

657.8

525.6

63.4

1101.6

3081.6

2170.3

603.6

IterativeCCEA

323.3

644.5

452.8

83.3

1257.9

5688.6

3794.7

890.3

ParallelCCEA

19.2

411.1

212

96.8

401.4

1516.2

782.6

279

5

HC

354.9

981.7

738.8

122.3

9.8

146.1

79.1

30.9

CGA

364.5

842.7

584.3

115.5

1796.1

5992.2

3513.3

1127.5

IterativeCCEA

76.2

745.8

543

142.6

1000.2

10029.6

6382.2

1964.9

ParallelCCEA

44.8

509.2

259.1

106.6

609.6

2094.6

1203.4

398.2

87


Figure 3.9: Comparison of the total execution time (TET) of the SaaS with di�erentnumbers of Cloud servers for parallel CCEA, iterative CCEA, CGA and hill climbing

only 1.18% in the smallest test problem, while for the other test problems the

gap is about 7% to 17%. A series of one-tailed t-tests are also conducted in

order to analysed the performance of the CGA and CCEAs with the heuristic.

The results indicate a statically signi�cant (p < 0.01) performance di�erence

between each of the algorithms and the heuristic.

Regarding the computation time of the analysed algorithms, Table 3.4

shows that the hill climbing heuristic always has the shortest computation

time in all the test problems compared to the others (in boldface). Figure 3.10

illustrates the e�ect of the number of Cloud servers on computation time. The

iterative CCEA has the highest average computation time for all test problems,

where the di�erence with the CGA is between 32% and 46%. This is understan-

dable since the iterative CCEA split the evolvement process into two separate

iterative processes, compared to the CGA which handled the evolvement pro-

cess as one big task. The parallel CCEA obtained a better computation time,

with an improvement between 53% and 65% from the CGA, while the hill

climbing has the best computation time, about 93% to 94% better than the

parallel GA. It should be noted that, for larger size problems, the computation

time gaps between these algorithms were larger. In addition, all algorithms

exhibit linear or close to linear growth.

88

3.5. Evaluation

Figure 3.10: The e�ect of the total number of Cloud servers on computation time

Experiments on the Number of SaaS Components

In this set of experiments, the algorithms are tested to solve test problems

that have a di�erent number of SaaS components. This is to study the impact

of the number of SaaS components on the quality of the solution produced by

the algorithms as well as on the computation time. Similar to the previous

experiment, each of the algorithms was repeated 30 times for each test problem.

The best, worst, average total execution time and computation time, with their

standard deviations, were recorded. These results are shown in Table 3.5, in

which boldface values indicate the best average solution produced among the

algorithms.

Based on the result, the relative standings of the algorithms are the same

as in the previous experiments, with the parallel CCEA producing the best

average SaaS total execution time, followed by iterative CCEA, CGA and hill

climbing. A graph of the solution quality in terms of the total execution time

(Figure 3.11) shows the comparison results between these algorithms. In all

test problems, the parallel CCEA produced up to 77% better in the SaaS exe-

cution time compared to the iterative GA and the CGA, and 86% better than

the hill climbing. For the smallest test problem, in which the SaaS consists of

ten components, the gap between the iterative GA and CGA is really small.

The gap increases as the number of components increased. The hill climbing

algorithm shows no clear relation to its performance with the increment num-

ber of SaaS components, as it has the smallest di�erence of results with other

89


Table3.5:

Experim

ental

results

ofthehill

climbing(H

C),classic

GA

(CGA),iterative

CCEA

andparallel

CCEA

fortest

prob

lems

with

di�eren

tnumbers

ofSaaS

components

Test

Algorith

mTotal

Execu

tionTime(secon

ds)

Com

putation

time(secon

ds)

Prob

lemBest

Worst

Avg

Std

Dev

Best

Worst

Avg

Std

Dev

1

HC

93.2175.7

125.621.6

2.66.6

3.7

1CGA

68138.8

103.216.9

55.8151.5

101.124.9

IterativeCCEA

88.5129.6

102.410.9

118.2419.4

218.776.3

Parallel

CCEA

0.589.3

23.7

20.742.3

154.281.5

32

2

HC

200.7312.6

261.427.7

8.431.8

15.3

5.8CGA

108.4210.4

154.427.5

445.6861.4

621.490.4

IterativeCCEA

96.3190

12723.4

811.12416.8

1278.2338.6

Parallel

CCEA

4.580.1

35.2

23.8120.3

371.4208.1

64.1

3

HC

174.8315.6

250.331.5

1866.6

35.5

12.6CGA

143.5245

197.926.6

159.25693

1610.8943.7

IterativeCCEA

130.6197

161.220

1651.26877.8

3111.31169.2

Parallel

CCEA

5.7145.5

63.4

43219

832.2441

176

4

HC

271.2407.6

339.537.6

38.2112.2

72.1

19.5CGA

157.3366.2

270.348

6974473

2828.51161

IterativeCCEA

170.2380.6

24451.3

1340.48934

5652.62056.6

Parallel

CCEA

12.7203.4

125.7

54.9415.2

950.4667

150.6

5

HC

278417.8

353.635.2

71.5309

166.4

73CGA

226.9338.3

295.728

16798918.4

47751963.6

IterativeCCEA

203.6328.5

25732.6

220815763.8

8318.23613.1

Parallel

CCEA

16.1238

120

79.2602

1938929.9

312.4

90

3.5. Evaluation

Figure 3.11: Comparison of the total execution time (TET) with di�erent numbersof SaaS components for parallel CCEA, iterative CCEA, CGA and hill climbing

algorithms in the test problem of 40 components (62%), and the largest dif-

ference is in the test problem with 20 components (86%). Signi�cance of the

results of the proposed algorithms with the heuristic were also tested using

t-tests with the level of signi�cance set to 0.01. The results con�rmed that the

performances of the three proposed algorithms are signi�cantly di�erent from

the heuristic in all test problems.

The computation time trends of the algorithms, as the total number of

SaaS components increases, are depicted in Figure 3.12. It can be seen that all

algorithms exhibit a linear growth, with the hill climbing heuristic being the

fastest technique. This pattern is similar to that of the previous experiments:

the computation time taken increases as the problem becomes larger, and

the gap between the algorithms also increases as the number of component

increases. It should be highlighted that the computation time for parallel

CCEA and the hill climbing algorithm increased much more slowly than the

CGA and iterative CCEA. Computation times for the iterative CCEA were

the highest, being up to 98% slower than the hill climbing, 88% slower than

the parallel CCEA and 54% slower than the CGA.

Summary of the experimental results

The above experiments were summarised based on the two objectives of the

evaluation: the proposed algorithms' quality of solution and their scalability.

In terms of the quality of solution, all three proposed algorithms � classi-

91


Figure 3.12: The e�ect of the number of SaaS components on computation time

cal GA, iterative CCEA and parallel CCEA � outperformed the hill climbing

heuristic in all test problems, especially for large-sized test problems, that

have a large number of servers or a large number of SaaS components. The

performances of the algorithms are also proven to be statistically signi�cantly

di�erent from the heuristic. Prior to the evaluation, two outcomes were ex-

pected: 1) both versions of the CCEA would produce better solutions than

the CGA, and 2) the parallel CCEA would improve the computation of the

iterative CCEA. These assumptions were made based on the claims and re-

search reported in the existing literature. As expected, the results of parallel

and iterative GA are better than those obtained by evolving solutions as a

single population in the CGA. The di�erence in quality is more obvious in the

large-sized test problems. The second assumption was also proven to be true,

as the parallel CCEA improved the computation time of the CCEA by more

than half. In addition, it is interesting to note that the parallel CCEA not only

improved the computation time, it also improved the quality of solutions tre-

mendously. This could be attributed to the design of the unsynchronous best

solution bu�er, which allows each subpopulation to update its best solution as

frequently as it wants without having to wait for the other subpopulations.

Both the CGA and the parallel CCEA exhibit good scalability: both algo-

rithms have a linear growth, especially the parallel CCEA, whose computation

time increased slowly as the problem size increased. The highest computation

time is produced by the iterative CCEA, where the computation time showed

a signi�cant increase with the increment of servers or SaaS components. Com-

92

3.6. Conclusion

pared with the hill climbing algorithm, the three proposed algorithms are seen

to have a trade-o� of speed against the solution quality: all three evolutionary

algorithms are much slower than the hill climbing heuristics, but give much

better results. However, even though hill climbing average computation times

are much faster than the parallel CCEA, the latter recorded a big improvement

in the quality of solutions, which is about 86% better than for the hill clim-

bing. It can be summarised that, of all the algorithms evaluated, the parallel

CCEA achieves the best quality solutions and is also time e�cient in solving

the composite SaaS placement problem.

3.6 Conclusion

This chapter presented a new problem, the composite SaaS placement problem

(SPP) in a Cloud data centre. The SPP introduces new challenges and requi-

rements in which the existing solutions for the common placement problem

cannot be applied directly to the SPP, and so new solutions for the problem

are required. The formulation of the new problem, also described in this chap-

ter, was as a complex optimisation problem with constraints, in which the

objective is to �nd placements for SaaS components such that their perfor-

mance is maximised based on the total execution time while satisfying the

constraints.

Two evolutionary algorithms were proposed: the �rst one is a classical ge-

netic algorithm (CGA) and the second one is the cooperative co-evolutionary

algorithm (CCEA). The main di�erence between these two types of evolutio-

nary algorithm lies in the evolvement process: the CGA evolves its solution

as one population while the CCEA splits its population into two cooperative

subpopulations based on the type of SaaS component. The CCEA has two

versions, the iterative CCEA that implements an iterative evolvement process

for its subpopulation, and the parallel CCEA, which uses the asynchronous

evolvement process.

The performances of all the proposed algorithms were tested in two sets of

experiments: 1) experiments with a di�erent number of Cloud servers, and 2)

experiments with a di�erent number of SaaS components. The algorithms were

compared with the performance of a hill climbing heuristic. The evaluation

focused on the quality of solutions produced as well as on the scalability of

93


the algorithms. The results of the experiments showed that the proposed

algorithms obtained better performance in all test experiments compared to

the heuristic, although the computation time taken was much longer than for

the hill climbing. However, the proposed algorithms showed good scalability

as the problem size grows, especially the parallel CCEA, which also showed an

impressive solutions' quality.

94

Chapter 4

Grouping Genetic Algorithms for

the Composite SaaS Clustering

Problem

At the initial stage of the composite SaaS placement process, SaaS compo-

nents are placed onto the VMs for execution. The VM must have su�cient

resources to ful�l the SaaS performance level speci�ed in the user's Service

Level Agreement (SLA). In the dynamic environment of a Cloud data centre,

where the workloads of applications and resource capacities keep changing over

time, the initial placement may need to be recon�gured in order to maintain

the SaaS performance as well as to optimise the resources used. To achieve

this, scheduled recon�guration for the current component placement in VMs

is triggered at a certain point of time. However, the placement recon�guration

in existing resource management for Cloud data centres often ignores the com-

posite SaaS constraints, which are its communication or dependency between

the components. It is important to include these elements, as they will directly

a�ect the performance of the SaaS.

This chapter investigates the placement recon�guration of composite SaaS

through component clustering, where the objective is to optimise the resources

used while maintaining the SaaS performance. Two new genetic algorithms are

developed each of which adopts a di�erent constraint handling strategy for the

problem. The next section introduces the background of the problem and its

gap, Section 4.2 presents the problem formulation, and the related work is

discussed in Section 4.3. The proposed algorithms are presented in Section

95

CHAPTER 4. GROUPING GENETIC ALGORITHMS FOR THE COMPOSITESAAS CLUSTERING PROBLEM

4.4, while Section 4.5 describes the evaluation that has been conducted and

its results. Section 4.6 concludes the chapter.

4.1 Introduction

The large scale and the complexity of a Cloud data centre make it hard to

manage. In addition, while the bene�ts are huge, the use of virtualisation tech-

nology contributes to the growth of resource management complexity. Among

the complex virtualisation management processes are the mapping of resource

requirements from physical machines to virtual machines (VMs) [3][26], the

consolidation and migration of services [6][14], and the recon�guration of the

initial placement of the service [50]. These processes need to be addressed in

the context of maximising the resource utilisation to the bene�t of the Cloud

providers and, at the same time, maintaining the SLA for the bene�t of the

users. As such, e�cient resource management that can respond well to the

changes in a Cloud is crucial in order to ensure that the Cloud services are

delivered smoothly while optimising the resources used for the services.

A considerable amount of research has been done to address the manage-

ment of VMs within the dynamic resource management of Cloud services, par-

ticularly the aim to optimise Cloud resources, including computation resources,

storage, power and the overall cost of the Cloud service. These objectives are

achieved through various management plans at di�erent levels. For instance,

at the platform level, most existing research focuses on the management of VM

mapping to physical servers, as well as on VM migration, while at the appli-

cation level, the plan is to increase or decrease the VM resources based on the

application's workload. The approaches proposed are proven to be successful,

subject to their objectives. However, although SaaS components are placed

and executed in VMs, these existing approaches for managing and optimising

the VMs resources cannot be used directly for optimising the resources used

for a composite SaaS. This is due to new criteria that the composite SaaS

resource optimisation problem introduced, which the existing solutions do not

address. These new criteria are:

• For a composite SaaS, multiple di�erent components are used in order

to deliver the SaaS functions to users. These components can be placed

either on a single VM, or on an individual VM for each component,

96

4.1. Introduction

Figure 4.1: A high level scenario of clustering SaaS components

or selected components can be clustered together on a single VM. This

decision is crucial as it can a�ect the cost of resources used as well as the

performance of the SaaS. However, most existing solutions for resource

management for VMs use the traditional placement pattern, which is

one component per VM. This might not be an ideal case for a composite

SaaS to optimise the resources used.

• A composite SaaS has dependencies between each other and among the

data components. When these components are placed in the VMs, the

network capacity among the components' VMs and storage servers will

directly a�ect the SaaS performance. The dependencies between the

SaaS components should be taken into consideration in management and

optimisation activities. Existing work often regards a VM as an indivi-

dual independent entity in which the dependencies between VMs are not

considered at all.

Based on the new challenges that arise from the composite SaaS criteria, this

chapter presents a new approach for addressing the resource optimisation pro-

blem of composite SaaS in a dynamic Cloud environment. The problem is

tackled using the clustering approach, in which the general idea is to recon-

�gure the initial placement of the SaaS application components by clustering

suitable components into VMs such that the resources used are optimised and

the SaaS performance is maintained. Figure 4.1 illustrates a high level of such

a scenario: the di�erent shapes represent an application component of a com-

posite SaaS, and a VM can host multiple components at a time. In order to

deliver a higher level of functionality to users, a composite SaaS may span over

multiple VMs.

Since moving a component from one location to another is an expensive

process, the proposed solutions will produce a solution with the least movement

97


required. In addition, the solution has to comply with the constraints that a

SaaS has. The constraints include the components that cannot be clustered

together, the resource requirements of these components, and the dependen-

cies between them. The placement recon�guration is usually scheduled by the

Cloud providers at a certain period of time, based on their needs. Di�erent

approaches can be taken at di�erent periods of time, and can be either dy-

namically or statically. In order to obtain an optimal solution, the proposed

solution deals with the dynamic environment at a static point of time, where

all SaaS in the data centre are considered.

The composite SaaS clustering problem stated above is a typical NP hard

and combinatorial optimisation problem. The number of possible combinations

for clustering the components and their placement will increase exponentially

as the number of Cloud VMs or SaaS components increases. In addition,

the problem's constraints further complicate the problem. Because of this,

genetic algorithms with constraint handling techniques are proposed to solve

the problem. A formal description of the problem is presented in the next

section.


Given a set of computation servers with VMs and their capacities; storage ser-

vers with their storage capacities; the Cloud communication network; and all

composite SaaS that are deployed in the Cloud data centre with their require-

ments, constraints and current placements, the objective is to recon�gure the

current placement of the SaaS application component by clustering suitable

components such that the cluster and the new placement will minimise the

cost of resources used while maintaining the SaaS performance. These inputs,

objectives, and constraints can be formulated as below:

Input

1. A Cloud data centre, DC = 〈CS ∪ SS, E〉, where


in DC, and n is the number of computation servers. The virtual

machines of each computation server are represented as 〈VMCi〉,

98


1 ≤ i ≤ n, where VMCi is the set of VMs for csi. VMCi ⊆ VM

where VM is the set of all VMs. Each VM is de�ned as vmij =

〈pcij,memij, diskij, priceij〉 , j ∈ N, where pcij is the processing

capacity, memij is the memory, diskij is the disk storage capacity,

and priceij is the cost of the VM.


and m is the number of storage servers.

• E is the set of undirected edges connecting the vertices, if and only

if there exists a communication link transmitting information from

vi to vj, where vi, vj ∈ CS ∪ SS. Bvi,vj : E → R+and Lvi,vj : E →R+are the bandwidth and latency functions of the link from vi to

vj respectively.

2. A set of composite SaaS, S = {s1, s2, ..., sj, ..., sq} where 1 ≤ j ≤ q,

and q is the number of composite SaaS deployed in DC. Each composite

SaaS consists of at least one application component, one data component

and the dependencies, sj = 〈ACj ∪ DCj, DAC, DDC〉 .

• ACj = {ac1, ac2, ..., acx} denotes the set of all application com-

ponent in sj, and x is the number of application components for sj.

ACj ⊆ AC where AC is the set of all application components. The

resource requirements for a component, aci, represented in a tuple

〈pcReqi,memReqi, sizei, amountRWi〉, 1 ≤ i ≤ x, where pcReqi is

the requirement for processing capacity, memReqi is the memory

requirement, sizei is the size of the component for disk storage re-

quirement, and amountRWi is the amount of read/write to other

communication components.

• DCj = {dc1, dc2, ..., dcy} denotes the set of data component for sj,

and y is the number of data components. DCj ⊆ DC where DC is

the set of all data components.

• S modelled by directed acyclic graphs (DAGs), DAC is the the

set of dependencies between application component where DAC =

AC ×AC and DDC is the set of dependencies between application

components and data components where DDC = AC ×DC .

99


3. The current placement of S and its placement constraint.

• A current placement con�guration, P , of application components,

AC, onto VM , P : AC → VM where aci 7→ P (aci) = vmk, and

1 ≤ i ≤ x, 1 ≤ k ≤ j.

• A current location, L, of the data components, DC, at storage

servers, SS, L : DC → SS where dcx 7→ L(dcx) = ssz, and 1 ≤x ≤ y, 1 ≤ z ≤ m.

4. A response time for the composite SaaS, rts.

Objective To �nd a new placement of S onto VM by clustering the appli-

cation components AC:

P ′ : AC → VM (4.1)

where aci 7→ P (aci) = vmk, 1 ≤ i ≤ x, 1 ≤ k ≤ j, such that the new placement

minimises the total cost of resources used for the SaaS, that is:

min (TC(S)) (4.2)

while satisfying all the constraints. As placement recon�guration is an expen-

sive process, the proposed solution will achieve the objective with a minimum

number of changes to the current placement con�guration. This is measured

based on the migration cost of the components that have to be moved during

the recon�guration process, that is:

min (MC(S)) (4.3)

The total cost of resources used, TC, and the migration cost, MC, are

de�ned in Equations 4.9 and 4.12.

Constraints

1. Resource constraint: The placement of application components onto

VM are subject to the VM capacities. Equations 4.4 to 4.6 denote the

constraints for processing capacity, memory capacity and disk capacity

for all VMs respectively.

100


∀vmi∈VM

∑acj∈AC


∀vmi∈VM

∑acj∈AC


∀vmi∈VM

∑acj∈AC


2. Placement constraints: The placement constraints are the anti-location,

AL, and the anti-colocation constraint, ACL.

• An anti-location constraint, AL, requires an application component

aci is never to be located in any VM in a computation server, csk.

In this scenario, we say that aci and csk are anti-located. A group of

anti-location CS−AC pairs is given as: AL ={(csk, aci)p , ...

}where

p ∈ N.

• An anti-colocation constraint, ACL, requires two application com-

ponents aci, acj is never to be located on a same computation server,

csk. In this scenario, we say that aci and acj are anti-colocated. A

group of anti-colocationAC pairs is given as: ACL ={(aci, acj)z , ...

}where z ∈ N.

The placement must comply with these placement constraints, formula-

ted as below:

aci 7→ P (aci) 6= vmy , ∀(aci, vmy) ∈ AL (4.7)

P (aci) 6= P (acj) , ∀(aci, acj) ∈ ACL (4.8)

3. Response time constraint: This constraint enforces the total response

time of the SaaS, TET , to be bounded by rt, TET ≤ rts. Calculation

of the TET is similar to that de�ned in Chapter 3.

101


Output A new placement con�guration for application components, AC =

{ac1, ac2, ..., acx}, 1 ≤ i ≤ x where x is the total number of application com-

ponents. Let P ′ denote the new placement plan where P ′ : AC → VM where

aci 7→ P ′(aci) = vmk, and 1 ≤ k ≤ j.

4.3 Related Work

In this section, existing works are reviewed and analysed based on the ap-

proaches they use to optimise the resources. The analysis focuses on the suita-

bility of the approach to the optimisation of composite SaaS in a Cloud data

center. Three common approaches are identi�ed: VM migration, placement

recon�guration and VM clustering.

Existing research on resource management at the platform level applies

migration of the VM as the main method of dealing with dynamic changes in

the Cloud environment [49][54][139]. A VM migration refers to the process of

moving one or more VMs from one computation server to another, without a

signi�cant interruption to the service [29]. Hermenier et al. [54] proposed a

two-phase solution for VM recon�guration in a data centre, named Entropy.

In its �rst phase, the minimum number of physical servers that can host the

current VMs is determined. In this phase the problem is formulated as the

constraint satisfaction problem, where the constraints are the capacities of

the servers. The second phase of the problem concerns �nding the cheapest

recon�guration plan of the VM, based on the physical servers found in the �rst

phase. The cost is determined by migration overheads that occur during the

recon�guration process, where the overhead is calculated based on the memory

requirement of the virtual machine being migrated. The solution in this work

is triggered by the current status of the VM. Other work such as the one

proposed in Verma et al. [139], triggers the migration periodically, based on

the maintenance schedule. They proposed an algorithm that consists of four

main processes; selection of the physical server that needs migration, selection

of the suitable VM on that physical server, selection of the new physical server

and assignment of the VM to the physical server. The selection is based on

load pro�les as well as on the behaviour of the servers. This earlier research at

the platform level consider a VM as an independent entity that does not need

to communicate with other VMs or storage servers in completing its task.

102

4.3. Related Work

A number of existing research that uses placement recon�guration as an

approach for resource optimisation in a Cloud considers communication among

VMs in their solution. In one such work, by Jayasinghe et al. [74], the authors

proposed a solution for recon�guration placement that supports three types of

constraints: VMs demands, communications and availability. The data centre

is modelled as a hierarchical structure that represents communication costs

based on its hierarchy. Other research that also concerns the communication

among VMs is presented in Wang and Wang [140]: they consider a multi-tier

application where the placement may span over multiple VMs. The proposed

solution is designed at two levels. At the application level, there is a controller

that will dynamically assign resources to applications, based on their requi-

rement; and at the platform level, they propose a consolidation algorithm to

re-place VMs to physical servers in the case of overload problems. The aim at

the platform level is to optimise the data centre's power usage. Similar research

can be found in Cucinotta, Palopoli, Abeni, Faggioli and Lipari [33] where a

multi-level solution is also proposed. These authors in that paper highlight the

implementation of the adaptive technique both at the application-level, where

the application adapts automatically to the availability of the resources, and at

the resource-allocation level, where the resources allocated adapt to the dyna-

mic workload requirements. There is another level considered in this work, in

which the power consumption is adapted to the demands at the resource-power

level. Although these solutions consider the individual VM interdependencies

between one another, they do not consider a composite application in which a

VM could host multiple components with di�erent requirements. In addition,

the components have to work with other components to achieve the overall

applications' functionalities that are subject to the user's SLA. The proposed

solution presented in this chapter addresses this gap.

Much has been done to optimise the resources using the clustering ap-

proach, which is closely related to the composite SaaS clustering problem.

One such research, by Hirofuchi et al. [57], proposed a genetic algorithm for a

Cloud resource management system that aims to achieve better resource op-

timisation based on the number of computation servers used by the VMs. In

their solution, the management system periodically monitors the load of the

computation servers, and tries to �nd a new computation server for the VM

by clustering several VMs together, in order to reduce the number of servers

103


as well as to minimise the power consumption. The algorithm is implemented

in a prototype data centre with seven computation servers and 64 VMs. Ba-

sed on the results, the algorithm demonstrated good �exibility of clustering

options and yielded good results. Although this research is quite similar to the

composite SaaS clustering problem, the algorithm considers only the resource

requirements of the VM. In the composite SaaS clustering problem there are

a number of important constraints that need to be addressed, including the

component dependencies and the placement constraints in order to ensure high

availability of the SaaS.

A more recent research can be found in Fan et al. [45], in which the

authors proposed a clustering-based method in selecting Cloud servers for a

communication-intensive application. The authors argue that there is a gap

in selecting Cloud servers for placing this type of application, since most exis-

ting works select the servers based on their resource capacity only. To ad-

dress this gap, they consider the communication relations between the VMs,

where all VMs are ranked based on their distance from one another. The

communication-intensive applications are placed using this rank. An evalua-

tion is conducted based on the make span of the application as well as its

throughput: the approach is compared with other approaches, including ran-

dom approach, selection based on resources only and selection based on com-

munication relation only. The results demonstrated that the clustering-based

approach performed better than the others. However, the main limitation of

this approach is that it considers neither the current workload of the servers

nor the dependency structure and constraints of the applications. Therefore,

the approach proposed is too general to apply for composite SaaS clustering

problems where the problem has more constraints to be addressed. In addi-

tion, the clustering of the proposed approach is based on the VM, while in

composite SaaS clustering problems it is based on the SaaS components.

To sum up, none of the research in the resource management optimisation

area considers applications similar to composite SaaS, in which the placement

process and communication requirement are di�erent from a typical applica-

tion. For these reasons, this research proposes a solution for resource optimi-

sation for composite SaaS in a Cloud data centre using a clustering approach

that concerns the composite SaaS requirements, dependencies and constraints.

104

4.4. Grouping Genetic Algorithms

4.4 Grouping Genetic Algorithms

From the computational point of view, this problem is a large-scale and com-

binatorial optimisation problem with constraints, for which an evolutionary

computation technique would be suitable. As the approach for this problem

is to cluster components into VMs, the grouping genetic algorithm (GGA)

technique is a natural choice. GGA [44], a modi�ed version of a genetic algo-

rithm (GA), is designed for solving grouping problems. While the GA treats

its chromosomes and cost function as a whole, the GGA divides its chromo-

somes based on relevant groups, and the optimisation of the cost functions is

done based on this grouping. The genetic operations in the GGA can also be

done based on the de�ned groups. This is to ensure that the groups can fully

explore the search space in order to �nd the optimal solution.

As formulated in Section 4.2, the composite SaaS clustering problem has

three types of constraints with which a solution has to comply: 1) the VMs

resource capacities constraint, 2) the SaaS component placement constraint,

and 3) the SaaS response time constraint. Although GGA is a credible and

powerful optimisation tool, it is not developed for constraint problems. Howe-

ver, a number of constraint handling techniques can be incorporated with the

GGA in order to produce a feasible solution subject to the constraints. Such

techniques include the repair-based technique, the penalty-based technique,

the dominance-based approach, and the Lagrange multiplier method [30]. In

this thesis, two types of technique were implemented, resulting in two di�erent

GGAs. The �rst is a repair-based GGA in which all the infeasible solutions are

repaired such that the GGA population consists of feasible solutions only. The

second GGA is a penalty-based GGA, which uses a penalty-based �tness func-

tion to favour the feasible solutions throughout the search. In the following

parts of this section, the two GGAs are introduced in detail.

4.4.1 A Repair-based Grouping Genetic Algorithm

The repair-based GGA (RGGA) uses a repair procedure to ensure that all

candidate solutions are feasible at all times. This means that solutions that

are generated from the initial population, as well as those produced from the

genetic operation, will be checked and repaired before the �tness value is cal-

culated. The solutions will be checked against the three constraints � the VM

105


resource capacity constraint, the SaaS component placement constraint and

the SaaS response time constraint.

Algorithm 7 describes the RGGA. The best �tness value and the best

placement recon�guration plan are initialised in Steps 1 and 2. In Step 3,

the initial population, consisting of the new placement plan for all SaaS in the

Cloud, is generated randomly. Each of the chromosomes is checked against the

problem's constraints, and any chromosomes that violate any of the constraints

will be repaired. This is done in Steps 6 and 7. The infeasible chromosomes

and the repairing procedure are explained in the next section. The objective

of the problem is to minimise the resources used by the SaaS and to make the

minimum number of changes possible to the current placement. As such, the

solutions are evaluated based on two attributes: the total cost of the VMs that

is used to host the components, and the migration cost of the components that

need to be moved. These are done in Steps 8 and 9, respectively. Based on the

value of these attributes, the �tness function of the chromosomes is calculated

in Step 10. The best �tness value and the best recon�guration plan are stored

in Steps 12 and 13. Steps 14 to 17 are for the selection, crossover and mutation

operations. The following sections will describe the RGGA in detail.

Genetic Encoding

In this problem, the performance of the SaaS is evaluated based on the total

response time of a group of SaaS components rather than on a single com-

ponent. Therefore, the chromosome is grouped based on the composite SaaS

that is deployed in the Cloud. Each group consists of a set of genes that

represent the new recon�guration placement of the set of components of a

particular composite SaaS.

The encoding scheme of the chromosome has two compartments. The �rst

compartment contains n genes, each of which corresponds to an application

component in that particular group. The second compartment contains the

ID of the VM, where the application component would be placed in the new

placement plan. Figure 4.2 shows an instance of the chromosome representa-

tion, where the total number of composite SaaS in the Cloud data centre is q,

and each of the SaaS has a di�erent number of application components.

106


Algorithm 7: The repair-based grouping genetic algorithm (RGGA)

1 bestF itness = 02 bestReconfigurationP lan = 03 randomly initiliase an initial population Population of PopSizeindividuals

4 while termination condition is not true do5 for X ∈ Population do

6 if X violates VM resource capacities, SaaS placement constraintor SaaS response time constraint then

7 Repair(X)

8 Calculate the new VM's cost9 Calculate the cost of components' migrations

10 Calculate X �tness value, F (X)11 if F (X) > bestF itness then12 Replace bestF itness13 bestReconfigurationP lan = X




Population

18 output bestF itness19 output bestReconfigurationP lan

Figure 4.2: An example of RGGA chromosome encoding scheme with q compositeSaaS with a di�erent number of components.

107


Infeasible Encoding Problem

The chromosomes generated may be infeasible due to the constraints of the

problem. All solutions that do not comply with these constraints will be

repaired. Based on the type of constraint, the repair procedures either use

domain-speci�c knowledge in order to make the chromosome feasible, or gene-

rate a new random value to correct the chromosome. The procedures are as

below:

Algorithm 8: The repair procedure for RGGA

1 if X violates VM resource capacities then2 Remove the last component that is placed on the VM3 Select new VM randomly

4 if X violates SaaS placement constraint then5 Change the placement to another random VM

6 if X violates SaaS response time constraint then7 Select the component that has largest computation time, ac8 Move ac to another VM that has shorter execution time9 Calculate the new response time, TET

Genetic Operators

Crossover The crossover operation is designed based on the grouping chro-

mosomes. A single-point inter-group crossover is used. This combines segments

from di�erent SaaS, and produces two children. The top two �ttest among the

parents and children are selected for the next generation. Figure 4.3 illustrates

the crossover operation.

Mutation An inner-group mutation operator is used to keep the diversity

of chromosomes in the population. The mutation operator is applied within

a composite SaaS. It changes a VM for a component to another VM that

also satis�es all the constraints. Figure 4.4 shows an example of the mutation

operation.

108


Figure 4.3: An example of inter-group crossover operation among composite SaaS

SaaS 1...

SaaS NSaaS 2

SaaS 1...

SaaS NSaaS 2

Figure 4.4: An example of inner-group mutation operation within a SaaS

109


Fitness Function

The aim of the problem is to create clusters of components of the multiple

composite SaaS. Components that are grouped together will be placed onto

the same server such that the new group and placement can minimise the total

resource costs while satisfying the SaaS constraints. The proposed solution

will try to achieve this aim with a minimum number of changes to the current

placement. The cost of the resources and the changes are incorporated in the

objective functions of the problem. These are used as the basis for evaluating

each of the solutions, as de�ned below:

1. The cost of VMs used by the SaaS

Each VM has its own price, given as an input of the problem. This price

is based on the VM's resource capacity: the higher the capacity, the

more it will cost. To calculate the total cost of the VM for a SaaS in a

particular chromosome, the total cost (TC) to host the SaaS components

will be the basis of the evaluation. This is de�ned as:

TC =∑

vmj∈VM

Costvmj(4.9)

where

Costvmj=

pricevmj, ∃vmj

| P (aci) = vmj

0 otherwise(4.10)

The following equation is to normalise the TC, and to ensure that the

TC is less than the current placement cost, initialCost:

F (TC) =

0, TC ≥ initialCost

initialCost−TCinitialCost

, otherwise(4.11)

2. The migration cost of a solution

Changing the current placement of a component from one VM to another

requires some memory and bandwidth on both the source and destina-

tion servers. Greater resources will be needed for large components or for

a component with a large memory requirement. These will incur some

costs. To estimate this cost, the calculation for placement changes is

110


based on the size of the components as well as the memory requirement.

In addition, to change the placement, the solution has to consider the

sequence of components that need to be moved, based on the current

placement at that time. This sequence may directly a�ect the cost of

changing the placement. Two scenarios will be considered in this pro-

blem:

• Sequential move: A particular component can be moved only when

another move has been completed. Migrations of two components

cannot be done in parallel when the destination VM for one of

the components has insu�cient resources (processing capacity/ me-

mory/ secondary storage). For example, if the VM contains another

component that is due to be migrated, this component needs to be

moved out �rst, to free some resources for the other component.

• Cyclic move: The migration of a set of components may need an

intermediate destination machine. This is the case where two or

more components need to exchange places. This can create a cyclic

constraint if the machines involved have insu�cient resources.

Considering the above, the migration cost for the migrated components,

MC, is de�ned as:

MC =∑

aci,j∈AC

sizeacimax(sizeAC)× 2

+memReqaci

max(memReqAC)× 2(4.12)

The following equation is to normalise MC:

F (MC) = 1− MC

|AC|(4.13)

Based on the attributes that have been de�ned above, the �tness function for

RGGA is:

Fitness(X) = (F (TC)× w1) + (F (MC)× w2) (4.14)

where w1 and w2 are the weightage for each part and w1 + w2 = 1.

111


4.4.2 A Penalty-based Grouping Genetic Algorithm

The RGGA described previously repairs each of the infeasible solutions in or-

der to handle the constraints. Based on the constraints that have been de�ned

in Section 4.2 and on the encoding scheme used, it can be seen that some of

the constraints concern a single gene, while other constraints involve a group

of genes. For the latter, repairing the selected genes randomly may lead to

early loss of diversity as well as loss of useful building blocks. In addition,

the checking and repairing procedures may contribute to a high computation

time due to the large size of the Cloud data centre and the large number of

SaaS components. Therefore, another simple constraint handling technique

is adopted and implemented, resulting in a penalty-based GGA (PGGA). Al-

though the PGGA keeps the infeasible solution in the population, its �tness is

degraded by a weighted sum of the constraint violations.

Algorithm 9 presents the pseudocode of the PGGA. Although it is similar

to the RGGA shown in Algorithm 7, the PGGA repairs only the chromosomes

that violate the resource constraint (Steps 6 and 7); the other two constraints,

the placement and response time constraints, are incorporated in the penalty-

based �tness function (Step 10). The resource constraint needs to be repaired

because the response time of the composite SaaS can be calculated only when

the resource requirements of the components are ful�lled. The following sec-

tions are the elaboration of the PGGA.

Genetic Encoding

The PGGA uses the same encoding scheme as the RGGA introduced in the

previous section (See Figure 4.2).

Genetic Operators

The PGGA adopts the same genetic operators as RGGA, as described in the

previous section. The crossover operation and the mutation operation are

illustrated in Figures 4.3 and 4.4 respectively.

Fitness Function

The two numerical attributes de�ned in RGGA (Section 4.4.1) will be used

as the basis to evaluate each of the chromosomes. The �rst attribute refers

112


Algorithm 9: The penalty-based grouping genetic algorithm (PGGA)

1 bestF itness = 02 bestReconfigurationP lan = 03 randomly initiliase an initial population Population of PopSizeindividuals


6 if X violates VM resource capacities then7 Repair(X)

8 Calculate the new VM's cost9 Calculate the cost of components' migrations

10 Calculate X �tness value, F (X), penalised if X violates SaaSplacement constraint and response time constraint

11 if F (X) > bestF itness then12 Replace bestF itness13 bestReconfigurationP lan = X




Population

18 output bestF itness19 output bestReconfigurationP lan

113


to the VM costs of a chromosome, and the second attribute is the migration

cost from the initial placement to the new recon�guration placement. These

attributes are de�ned in Equation 4.11 and Equation 4.13 and represent the

cost of a solution.

Unlike RGGA, PGGA allows infeasible solutions in its population, to pre-

serve infeasible solutions that might have good schemata that can contribute

to the development of an optimal solution. However, the infeasible solution

will be penalised through a penalty-based �tness function, to guarantee that

the infeasible solutions have lower �tness values than those of the feasible so-

lutions. In addition, to de�ne the relationship between the infeasible solutions

and the feasible region of the search space, the level of the solution's infeasibi-

lity is measured: solutions that violate more constraints will be more harshly

penalised than an infeasible solution that violates fewer constraints.

Three constraints were de�ned in Section 4.2. As each of the solutions

has to meet the resource requirement before other constraints can be checked,

solutions that violate the resource constraints will be repaired. For the pla-

cement constraint, any violation of the component's placement constraint will

be counted and accumulated as V1, de�ned as below:

V1 =

∑aci∈AC PCi

|AC|, where PCi =

1, aci 7→ P (aci) = vmy | ∀(aci, vmy) ∈ AL

1 P (aci) = P (acj) | ∀(aci, acj) ∈ ACL

0, otherwise

(4.15)

For the response time constraint, if the total execution time for a composite

SaaS, si, exceeds its agreed time, rtsi , it will be counted as V2 de�ned as below:

V2 =

∑si∈S T i

| S |, where T i =

1, TET (si) > rtsi

0, otherwise(4.16)

Based on Equations 4.11, 4.13, 4.15, and 4.16, the �tness function for the

PGGA is:

114

4.5. Evaluation

F (X) =

(F (TC)× w1 + F (MC)× w2) + 0.5,∑

i∈|V | Vi = 0

(F (TC)× w1 + F (MC)× w2)×(1−

∑i∈|V | Vi

|V |

), otherwise

(4.17)

where w1 and w2 are the weightage for each attributes, w1 + w2 = 0.5.

4.5 Evaluation

This section evaluates the performance of the two proposed GGAs. Two cri-

teria are used in the evaluation. The �rst criterion is the quality of solutions

produced by the algorithms. Ideally, the best way to evaluate the quality of

these solutions is to compare the algorithms with solutions obtained by exis-

ting techniques on the same problem. However, there is no benchmark with

which to compare this problem. Therefore, the GGAs are compared with the

�rst �t decreasing heuristic (FFD), the most common heuristic used for the bin

packing problem (BPP) in which BPP shares similar traits with the composite

SaaS clustering problem.

The second criterion covers the e�ectiveness and scalability of the GGAs.

This is evaluated by running the algorithms on a number of problems with a

di�erent number of Cloud VMs and di�erent number of composite SaaS. The

di�erent number of Cloud VMs represents the di�erent sizes of search space,

while the number of composite SaaS re�ects the complexities of the problem in

which it depends on the SaaS constraints as well as the dependency between

the SaaS components. The details of the evaluation are introduced in the

following parts of this section.

4.5.1 Test Problems

The quality of solutions as well as their e�ectiveness and scalability of the

GGAs are tested on two sets of test problems with di�erent sizes and com-

plexities. The �rst test problem represents the number of Cloud VMs involved

in the problems, while the second test problem represents the number of com-

posite SaaS under consideration. Below is the elaboration of the test problems:

115


Test problems with di�erent numbers of Cloud VMs

Five test problems with di�erent numbers of Cloud VMs are created. The

numbers range from 300 to 1500, with an increment of 300. The capacities

of the VM, including its processing capacity, memory capacity and storage

capacity, are generated randomly based on IBM and HP commercial servers

[55][63]. The price of the VM is calculated based on its resource capacity. The

communication links between the VMs are based on their computation servers'

link. For this set of test problems, the number of composite SaaS is set to three

with a total of 15 components. Table 4.1 shows the characteristics of the �ve

randomly generated test problems.



#Virtual Machines #Storage servers #Total servers1 300 50 3502 600 100 7003 900 150 10504 1200 200 14005 1500 250 1750

Test problems with di�erent numbers of composite SaaS

Five test problems were designed, each consisting of a di�erent number of

composite SaaS. Each of the composite SaaS consists of a di�erent random

number of application components and data components. The number of the

composite SaaS ranges from 2 to 6, while the total number of application

components ranges from 9 to 39, and the data components from 4 to 12. Table

4.2 shows the number of composite SaaS for each test problem together with

the total number of components involved. An example of the test problems

with three composite SaaS is illustrated in Figure 4.5. For all test problems,

the number of VMs is set at 900.

4.5.2 A First Fit Decreasing Algorithm

Since there are no benchmark solutions available for comparison, a �rst �t

decreasing (FFD) heuristic algorithm is developed. The FFD is among the

116

4.5. Evaluation

Table 4.2: Test problems with di�erent numbers of composite SaaS

TestProblem

Test Problem Characteristics

#CompositeSaaS

Totalnumber ofapplicationcompo-nents

Totalnumber ofdata com-ponents

1 2 9 4

2 3 15 6

3 4 22 8

4 5 30 10

5 6 39 12

Figure 4.5: An example of three composite SaaS with di�erent numbers of applicationcomponents and data components

117


simplest heuristic for solving the bin packing problem. A bin packing problem

is a problem of assigning a number of items to a number of bins, such that the

total weight of the items in each bin does not exceed the capacity of the bin

and that the number of bins used is minimum [100]. If a SaaS component is

considered to be a multi-dimensional item and the VM is a multi-dimensional

bin, then the problem of clustering the components into VMs shares basic

features similar to a bin packing problem. However, the former has more

constraints and is more complex than the latter. The FFD developed in this

problem is modi�ed to address the problem's constraints and complexities.

Algorithm 10 shows the pseudocode of the FFD. In Steps 1 and 2, the SaaS

components and VMs are sorted in decreasing order based on their processing

requirement (for SaaS component), or their processing capacity (for the VMs).

Then, each of the components is packed to the �rst available VM that satis�es

the resource and placement constraint (Step 6). If a complete solution is found,

the total execution time is calculated to ensure that the solution meets with

the response time constraint. If the solution violates the time constraint, the

component with the highest execution time will be moved to another random

VM that yields a better execution time. The algorithm will continue until

the constraint is satis�ed or until there is no improvement for 100 consecutive

iterations. These are shown in Steps 12 to 19.

4.5.3 Experimental Results

Both versions of the GGAs and the FFD heuristic were implemented in Mi-

crosoft Visual Studio C++ and executed on a desktop computer with 3 GHz

Intel Core 2 Duo CPU and 4GB RAM. The RGGA and PGGA share similar

settings of the algorithm, which are illustrated in Table 4.3. These parame-

ters are determined based on the trial runs of the algorithms, in which the

parameters that produced the best results are used.


The objective of the problem is to minimise the cost of resources used, by

making possible minimum changes of placement while maintaining the SaaS

performance. The resources cost is calculated from the accumulated VM cost

used by the SaaS; the changes are based on the cost of migrating the compo-

118

4.5. Evaluation

Algorithm 10: The �rst �t decreasing heuristic algorithm

1 Sort AC in descending order based on its procesing requirement, ACsort2 Sort VM in descending order based on its procesing capacity, VMsort3 count = 04 for ac ∈ ACsort do5 for vm ∈ VMsort do6 if vm satis�es resource requirement constraint and placement

constraint then7 Pack component ac in bin vm8 Update vm9 Break the loop and pack the next component

10 if ac did not �t in any available bin then

11 found = false

12 while (count < 100) and (found) do13 Check the response time constraint14 if response time constraint satis�ed then

15 Accept the packing plan16 Break the loop

17 else

18 Change the location of component that has the highest executiontime

19 count = count+ 1

119


Table 4.3: Simulation parameters for the GGAs

Parameter ValuePopulation size 100Crossover rate 95%Mutation rate 5%Termination condition (# of generation without improvements) 25RGGA w1 0.6RGGA w2 0.4PGGA w1 0.3PGGA w2 0.2

nents from their initial location to a new one. The solution has to comply with

the response time of the SaaS to ensure that the performance of the SaaS is

maintained.

The three algorithms are tested to solve each test problem in the �rst set

outlined in Section 4.5.1. Each algorithm repeated the experiments 30 times

due to the stochastic nature of the GGA, as well as the random element that

exists in the FFD. Table 4.4 shows the statistics of the results, including their

best, worst, average and standard deviation for VM cost and migration cost, as

well as the computation time taken by the algorithm. The average of the VM

cost, migration cost, and computation time are further illustrated in Figure

4.6, Figure 4.7, and Figure 4.8, respectively.

From the results, it can be seen that all the algorithms are able to produced

feasible solutions for all the test problems. For the VM cost, the PGGA has the

lowest cost for all test problems, followed closely by the RGGA, while the FFD

has the highest VM costs. The di�erence between the RGGA's and PGGA's

VM cost is about 10% to 14%, and that of the FFD's and PGGA's is from

22% to 38%. There is no signi�cant pattern observed in the VM cost obtained

by the algorithms as the number of Cloud VM increases. Although the PGGA

outperformed the RGGA in terms of the VM costs, the results show that the

PGGA has higher migration costs than the RGGA for all test problems. The

di�erence between the PGGA and RGGA migration cost ranges from 3% to

9%, and between the PGGA and FFD from 1% to 5%, with the FFD having

the higher migration cost. In addition, to get a clear view of the two GGAs

over the heuristic, statistical signi�cance tests for each of these algorithms

against the heuristic are performed. The one-tailed t-test results for the VM

120

4.5. Evaluation

Table4.4:

Experim

entalresultsof

thePGGA,RGGAandFFD

fortest

problemswithdi�erentnumbersof

VMs

Test

Algorithm

VM

Costs

Migration

costs

Com

putation

time(seconds)

Problem

Best

Worst

Avg

Std

Dev

Best

Worst

Avg

Std

Dev

Best

Worst

Avg

Std

Dev

1PGGA

20.1

29.3

26.1

2.6

5.5

7.1

6.2

0.4

29280

132.5

63.9

RGGA

27.4

32.9

30.3

1.6

4.6

6.5

5.7

0.5

40250

98.7

52.1

FFD

40.8

43.2

42.2

1.2

6.1

6.6

6.5

0.09

00

00

2PGGA

2032

27.2

3.1

67.1

6.9

0.3

63287

154

61RGGA

26.7

35.4

30.6

25

7.1

6.3

0.4

24290

83.9

53FFD

36.7

42.5

40.7

1.8

7.1

7.1

7.1

00

00

0

3PGGA

23.1

31.7

26.8

1.8

5.9

7.1

6.8

0.3

71553

167

110

RGGA

26.5

40.3

30.3

2.8

5.8

7.1

6.6

0.5

25168

87.2

43.1

FFD

3841.1

39.8

1.5

7.1

7.1

7.1

00

00

0

4PGGA

20.3

30.4

25.8

2.1

6.5

7.1

6.9

0.3

37480

198

108

RGGA

25.6

33.3

28.7

1.9

5.4

7.1

6.5

0.5

28197

83.9

39.6

FFD

28.7

36.8

331.9

7.1

7.1

7.1

00

00

0

5PGGA

20.4

29.7

26.2

2.1

6.1

7.1

70.3

119

377

212

63RGGA

26.1

3229.5

1.5

5.5

7.1

6.7

0.4

33166

8637

FFD

28.1

37.2

34.7

2.7

7.1

7.1

7.1

00

00

0

121


costs and migration costs with 95% con�dence level show that both GGAs are

signi�cantly di�erent from the heuristic. Overall, between the two GGAs, the

PGGA managed to obtain a new recon�guration placement for the composite

SaaS with cheaper VM costs; however, the migration cost to the new placement

is a little higher than the one for the RGGA.

Figure 4.6: Comparison of the VM cost of PGGA, RGGA and the FFD for di�erentnumbers of VMs

Figure 4.7: Comparison of the migration cost of PGGA, RGGA and the FFD fordi�erent numbers of VMs

For the computation time, the FFD is the quickest of all three. Interesting-

ly, despite the increasing number of Cloud VMs, the FFD exhibits a constant

computation time of under one second for all test problems. The RGGA has

the second best time, taking about 1.4 to 1.6 minutes to solve the problems.

122

4.5. Evaluation

The longest time between the three algorithms is produced by the PGGA.

Its computation time is greater by about 26% to 60% than the RGGA. In

addition, the PPGA shows an almost linear growth as the number of Cloud

VMs increases.

Figure 4.8: The e�ect of the number of VMs on computation time


In this experiment, the algorithms are evaluated with test problems that have

a di�erent number of composite SaaS. This is to investigate how the algo-

rithms perform when the complexities of the problem increase in terms of

its constraints and dependencies. The experiments for all three algorithms

are conducted 30 times. Table 4.2 shows the best, worst, and average of the

VM cost, the migration cost, and the computation time, together with their

standard deviation. The results in boldface styles indicate the best solution

produced among the algorithms.

Based on the results, it can be observed that the PGGA and RGGA have

the same lowest VM cost for test problem 1; for the rest of the test problems,

the PGGA has a better VM cost compared to the other algorithms. The costs

that are obtained by the PGGA are up to 15% cheaper than the RGGA, and

33% cheaper than the FFD. Figure 4.9 illustrates the results of the VM cost:

it can be seen that the costs increase as the number of composite SaaS grows.

The same cost is obtained between the RGGA and PGGA for the smallest

test problem, which consists of only two composite SaaS. From the bar chart,

123


Table4.5:

Experim

ental

results

ofthePGGA,RGGAandFFD

fortest

prob

lemswith

di�eren

tnumbers

ofcom

posite

SaaS

Test

Algorith

mVM

Costs

Migration

costsCom

putation

time(secon

ds)

Prob

lemBest

Worst

Avg

Std

Dev

Best

Worst

Avg

Std

Dev

Best

Worst

Avg

Std

Dev

1PGGA

11.116

13.5

1.31.9

2.62.5

0.265

305150

71RGGA

10.916.9

13.5

1.51.4

2.62.5

0.226

16169

35FFD

16.513.8

20.11.4

2.62.6

2.60

00

00

2PGGA

23.131.7

26.8

1.85.9

7.16.8

0.371

553167

110RGGA

25.532.7

28.71.8

5.87.1

6.6

0.525

16887.2

43.1FFD

3841.1

39.81.5

7.17.1

7.10

00

00

3PGGA

30.145.5

36.2

4.21.4

7.97.5

1.28

368131

72RGGA

35.150.2

42.53.9

6.77.9

7.5

0.429

17976.5

41.1FFD

43.448.7

46.31.7

7.987.98

7.980

00

00

4PGGA

5164.3

55.8

3.811.2

13.212.7

0.579

346143

60RGGA

5677.8

63.75.6

10.313.2

12.2

0.929

23468.9

44.7FFD

72.674.5

73.61.5

13.213.2

13.20

00

00

5PGGA

5877.5

67.1

4.410.1

10.810.6

0.290

485190

90RGGA

6285.3

73.84.9

9.570.9

10.4

0.515

32979.4

58.8FFD

74.280

77.61.8

10.310.3

10.30

00

00

124

4.5. Evaluation

Figure 4.9: Comparison of the VM cost of PGGA, RGGA and the FFD for di�erentnumbers of composite SaaS

it can be seen that the gap between the algorithms increases as the number

of composite SaaS increases. One-tailed t-tests between the GGAs and FFD

for VM costs were also conducted. The results show that there are signi�cant

di�erences (p < 0.01) between the two techniques with the heuristic in all test

problems.

On the other hand, there is no signi�cant pattern produced by the algo-

rithms for the migration costs. Based on the table results, the RGGA has the

lowest migration cost for all test problems; however, this cost is the same as

the PGGA in test problems 1 and 3. In addition, the highest migration cost

obtained among all the test problems is not from the test problem with the

highest number of composite SaaS, but from test problem 4, which consists of

only �ve composite SaaS. These results are further illustrated in Figure 4.10.

With regard to the computation time taken by the algorithms, the relative

standings are the same as the computation times taken in the previous expe-

riment. The FFD has the fastest execution time, with the longest time taken

being about six seconds in test problem 5. As for the RGGA and PGGA, no

correlation can be seen between the numbers of the composite SaaS with the

computation time taken by both GGAs. The PGGA has the longest compu-

tation time for all test problems; it took about 2.2 to 3.2 minutes to solve

the problem, while the computation time for the RGGA is about 42% to 58%

faster than the PGGA.

125


Figure 4.10: Comparison of the migration cost of PGGA, RGGA and the FFD fordi�erent numbers of composite SaaS

Figure 4.11: The e�ect of the number of composite SaaS on computation time

126

4.6. Conclusion

Summary of the experimental results

Based on the above experimental results for the two sets of test problems, the

following conclusions can be drawn:

• Performance: Both the GGAs and the FFD can produce feasible so-

lutions for all test problems that have di�erent sizes and complexities.

The PGGA consistently outperforms the other two algorithms in terms

of �nding the lowest VM cost for the new placement plan. This could

be attributed to the constraint handling technique used in solving the

problem, as the PGGA kept the infeasible solutions in its population to

preserve the schemata. The infeasible solutions are penalised in a way

that provides a direction to the feasible region. This helps the search to

�nd a better placement plan with each generation. The cheaper place-

ment cost of the PGGA is a trade-o� with its migration cost: in some of

the cases, the PGGA has a higher cost than the RGGA. However, since

the highest di�erence is only about 10%, and the cost savings are much

greater, this is acceptable.

• Scalability: In the �rst set of test problems, the PGGA increases almost

linearly when the number of Cloud VMs increases, while the RGGA's

computation time pattern is more or less constant. In the second set of

test problems, neither GGA exhibits any signi�cant pattern of compu-

tation time growth. Overall, there is a big gap between the times taken

by the GGAs and the computation times taken by the FFD. Although

the time di�erences are signi�cant, the large improvement in minimising

the GGA resource usage makes this still a�ordable.

4.6 Conclusion

This chapter presented the problem formulation and modelling of the mul-

tiple composite SaaS component clustering problem for the dynamic resource

management of Cloud data centres. The major objective of the problem is

to minimise the usage of resources of the SaaS without violating their SaaS

constraints; which is done by recon�guring the placement of the applications'

components. Meanwhile, achieving the objective with the minimum changes

possible, remains the aims.

127


Two versions of grouping genetic algorithms (GGAs) have been proposed

and implemented. The GGAs are speci�cally designed to cater for the struc-

tural group of a composite SaaS. The clustering and recon�guration placement

problem considers not only the resource requirements of the SaaS, but also the

communication needs of the SaaS components. The two versions of the GGAs

employed a similar process of population evolution, except for the way they

handle the problem's constraints. The �rst GGA used a repair-based method

(RGGA) while the second version used a penalty-based method (PGGA).

Both GGAs are compared with a common heuristic in a similar optimi-

sation problem: the �rst �t decreasing heuristic. Based on the experimental

results, the proposed GGAs always produce feasible solutions for all test pro-

blems, with the PGGA solutions having the lowest VM costs and similar or

slightly higher migration costs than the RGGA and FFD, and hence, a better

recon�guration placement plan for the composite SaaS. Although the com-

putation time taken is quite long, it is still acceptable considering that, in a

data centre, there are various types of maintenance conducted at di�erent time

scales.

128

Chapter 5

A Hybrid GA for the Composite

SaaS Scalability Problem

This chapter discusses the composite SaaS scalability problem which refers

to the the scaling process that is done in order to cope with the increasing

or decreasing workload of the SaaS, in which the component's instances can

be created if the demand suppresses supply and will be deleted if the supply

suppresses the demand. This feature is referred to as the scalability of the SaaS.

Since a composite SaaS introduces several new challenges for the scalability

problem that existing scalability mechanisms do not address, there is a need to

develop a new solution for the problem. This chapter investigates the problem

and proposes a new hybrid genetic algorithm to address the gaps. The following

section will introduce the problem background and its gaps in detail. Section

5.2 describes the problem formulation, while Section 5.3 reviews the related

work. The proposed algorithm is discussed and evaluated in Section 5.4 and

Section 5.5 respectively, and Section 5.6 concludes the chapter.

5.1 Introduction

One of the essential characteristics of Cloud computing is to provide access to a

large pool of computation resources in which the resources can be dynamically

provisioned based on the demand. The automated provision mechanism in

a Cloud is responsibles for adding or removing the resources for a particular

Cloud service, such that the usage of the resources is minimised while its

129

CHAPTER 5. A HYBRID GA FOR THE COMPOSITE SAAS SCALABILITYPROBLEM

performance is maintained. The process of adding/removing the resources

based on the demand, referred to as the scaling up or scaling down process,

represents the scalability of the service [21].

The term `scalability' is relatively new in the service application area. Se-

veral existing publications de�ne the term. For Bondi[15], it is a concept that

implies the ability of a system to accommodate an increasing workload gra-

cefully, where the cost for this accommodation, including but not limited to

the response time, memory or money, should not be excessive. Another de-

�nition, found in Jogalekar and Woodside [77], sees scalability as the ability

of the system to operate e�ciently with adequate quality of service over the

given range of con�gurations proportionate to the system's cost. These de�-

nitions are in line with the four main characteristics of scalability de�ned by

Lee and Kim [94]: 1) able to handle the growing demands, 2) with assuring

schemes, 3) scale with acceptable cost, and 4) without signi�cant degradation

of its quality. Based on the de�nition and discussion in the existing literature,

it is clear that scalability is a must-have characteristic in Cloud services, since

the main aim of Cloud providers is to o�er a dynamic amount of resources to

meet the user's SLA with a low cost.

Caceres et al. [21] discussed scalability from a Cloud computing perspec-

tive, and classifying the action to scale into two categories � vertical scaling

and horizontal scaling. Vertical scaling, also known as `scaling-up', is where

more computation resources are added to the service to enable it to cope with

high demands. In horizontal scaling or `scaling-out', more similar services are

created and users' demands will be directed to the appropriate service. Dif-

ferent categories have di�erent approaches of implementation. Migration is

among the popular approaches for implementing vertical scaling [89][94]. In

this approach, for example, a service (either virtual machines (VMs) or ap-

plication components) that receives a high request nearing its maximum load

can be migrated to a more powerful server in order to cope with its spike

[89]. Another approach for vertical scaling is to directly add more computa-

tion resources, such as a CPU or memory, to the VM or the application. This

approach, however, requires a VM to be restarted or rebooted in order for the

changes to take e�ect, which might result in some downtime [136]. Among the

approaches for horizontal scaling are distributions of workloads across multiple

instances of a service and replication of the service [26][123][142]. The distri-

130

5.1. Introduction

bution of workload is done through a load balancer in a Cloud infrastructure,

where the load balancer is responsible for routing and balancing the workload

to instances of services in the Cloud [26]. The second and more common ap-

proach for horizontal scaling is the replication/deletion of the service. The

replication is done by creation (scale up) or deletion (scale down) of a service

[16][123][142]. Once a replication is created, it must be e�ectively placed in the

data centre to provide e�cient access to the replica. Both categories of scaling

are triggered by scalability metrics. Examples of scalability metrics are the

number of current users of the service, the quality of solution of the service,

the number of incoming requests and the current resource usage of a service

[89][123][136][142]. This thesis focuses on the replication/deletion approach as

the scaling mechanism to handle the composite SaaS scalability.

The scaling mechanism in a Cloud data centre management can be consi-

dered at two di�erent levels based on its granularity: 1) at the infrastructure

level to scale the servers, and 2) at the application level to scale the application

components [21][123][136]. At the infrastructure level, VMs act as the server's

abstractions. The scalability metrics depend on the current resources of a

server including its CPU, disk, and memory. Either the scaling middleware

or the resource management system monitoring the VM resources has a set

of prede�ned server performance metrics, in which the VM will be replicated

automatically to cope with its workload or deleted in order to maintain the

utilisation of the servers. As for the application level, the scalability metrics

are on a higher level that is based on the application's attributes instead of

on the computation resources. Among the metrics are the number of current

users of the application, the number of tasks and the utilisation level of the

application in its host servers [16][123][142]. The replicas that are created have

to comply with the SLA and any constraints that the application may have.

This includes the placement of the replica, the replica response time to users

and the cost of running the replica. In both levels, a load balancer is used to

spread the user's request across the replicas. The main challenges of the scaling

process for both levels are to determine the threshold of the scalability metric,

to determine the scalability rules that are associated with the metric, and to

determine the number of replicas to be created/deleted so that the service's

performance is maintained and the resources are utilised. The scalability rules

refers to a set of conditions of the scalability metrics in which, when the condi-

131


�

Figure 5.1: An example of scalability rules at the application level [123]

tions are met, a set of actions in respect of the replication process is activated

[123]. The actions include the replication or deletion process, its placement

onto the host servers and the update broadcast to the load balancer. Figure

5.1 illustrates an example of the scalability rules at the application level.

The scaling process for a composite SaaS in a Cloud data centre introduces

several new challenges compared with the existing problem:

• First, the performance of a composite SaaS is measured by a set of appli-

cation components instead of by a single component. The current scaling

process at the application level treats the application as a single entity

and the relationship between other application components are often not

considered. This is the same for the scaling process at the infrastructure

level, as the scalability metrics and rules are dealing with an individual

VM only. For a composite SaaS, any component that is replicated not

only has to perform well on its own, but must also comply with the

overall performance SLA, which involves other application components

as well as data components. As such, knowledge of all the SaaS compo-

nents, their current workload, requirements and constraints are essential

attributes in making proper decisions.

• Second, a particular component in a composite SaaS may be requested

more than other components in the same SaaS. Thus, it is an additional

challenge to determine which component is more suitable to scale, and

how many replicas are needed for that particular component in order

to cope with the overall workload and maintain the performance, while

utilising the resource usage.

132


• Third, the placement of a new replica of a composite SaaS has to consider

its communication with other components. It is assumed that more

than one application component can be placed in a VM. As such, to

some extent, the replication process for a composite SaaS has to consider

both the application and infrastructure level scalability metrics. The

application scalability metrics are used to determine the candidate for

replication, while the infrastructure scalability metrics are used to get

a suitable placement for a replica such that it can work well with other

replica/components. This is di�erent from the current replication process

in which both levels are dealt with separately.

To address these new challenges, a new scaling algorithm for a composite SaaS

is developed in which the algorithm uses information at both the application

and infrastructure layers in making the decisions. To ensure the scaling results

meet the SaaS overall performance, the algorithm is designed such that it can

explore the best scaling decision without having to fully rely on the scalability

rules as well as the on resource metrics. The following section will present the

problem formulation and its objective in detail.


Given a set of computation servers with their resources and virtual machines,

storage servers with their capacities, the Cloud communication network, the

composite SaaS with its requirements and constraints, and the set of tenants

with their users, the objective is to determine which SaaS component should

be replicated/deleted, how many replicas to create/delete and where to place

the new replica in the Cloud data centre such that the performance of the SaaS

complies with its constraints while minimising the Cloud running cost. These

inputs, constraints and output can be formulated as below:

Input

1. A Cloud data centre, DC = 〈CS ∪ SS, E〉, where


in DC, and n is the number of computation servers. The resource

133


capacities and virtual machines of each computation server are re-

presented in a tuple 〈pci,memi, diski, V MCi〉, 1 ≤ i ≤ n, where pci

is the processing capacity, memi is the memory, diski is the disk sto-

rage capacity, and VMCi is the set of VMs for csi. VMCi ⊆ VM

where VM is the set of all virtual machines. Each VM is de�ned

as vmij = 〈pcij,memij, diskij, priceij〉 , j ∈ N, where pcij is the

processing capacity, memij is the memory, diskij is the disk storage

capacity, and priceij is the cost of the VM.


and m is the number of storage servers.

• E is the set of undirected edges connecting the vertices, if and only if

there exists a communication link transmitting information from vi

to vj, where vi, vj ∈ CS∪SS. Bvi,vj : E → R+and Lvi,vj : E → R+

are the bandwidth and latency functions of the link from vi to vj

respectively.

2. A set of composite SaaS, S = 〈AC ∪ DC, DAC, DDC〉, where

• AC = {ac1, ac2, ..., acx} denotes the set of all application compo-

nents in S, and x is the number of application components. The

resource requirements for each component represented in a tuple

〈pcReqi,memReqi, sizei, amountRWi,maxUseri〉, 1 ≤ i ≤ x, where

pcReqi is the requirement for processing capacity, memReqi is the

memory requirement, sizei is the size of the component for disk

storage requirement, amountRWi is the amount of read/write to

other communication components, and maxUseri is the maximum

user for aci.

• DC = {dc1, dc2, ..., dcy} denotes the set of data components for S,

and y is the number of data components.

• S modelled by directed acyclic graphs (DAGs), DAC is the the

set of dependencies between application component where DAC =

AC ×AC and DDC is the set of dependencies between application

components and data components where DDC = AC ×DC .

3. The current placement of S and its placement constraint.

134


• A current placement con�guration, P , of application components,

AC, onto VM , P : AC → VM where aci 7→ P (aci) = vmk, and

1 ≤ i ≤ x, 1 ≤ k ≤ j.

• A current location, L, of the data components, DC, at storage

servers, SS, L : DC → SS where dcx 7→ L(dcx) = ssz, and 1 ≤x ≤ y, 1 ≤ z ≤ m.

4. A response time for the composite SaaS, rts.

5. A set of tenant, T = {T1, T2, Ti, ..., Tv}, and 1 ≤ i ≤ v. Each tenant may

have one or more users denoted as 〈ui〉.

Constraints

1. Resource constraint: The placement of application components onto

VM are subject to the VM capacities. Equations 5.1 to 5.3 denote the

constraints for processing capacity, memory capacity and disk capacity

for all VMs respectively.

∀vmi∈VM

∑acj∈AC


∀vmi∈VM

∑acj∈AC


∀vmi∈VM

∑acj∈AC


2. Placement constraint: The placement constraints are the anti-location,

AL, and the anti-colocation constraint, ACL.

• An anti-location constraint, AL, requires an application component

aci is never to be located in any VM in a computation server, csk.

In this scenario, we say that aci and csk are anti-located. A group

of anti-location CS −AC pairs is given as: AL ={(csk, aci)p , ...

}where p ∈ N.

135


• An anti-colocation constraint, ACL, requires two application com-

ponents aci, acj is never to be located on a same computation server,

csk. In this scenario, we say that aci and acj are anti-colocated. A

group of anti-colocationAC pairs is given asACL ={(aci, acj)z , ...

}where z ∈ N.

The placement must comply with these placement constraints formulated

as below:

aci 7→ P (aci) 6= vmy , ∀(aci, vmy) ∈ AL (5.4)

P (aci) 6= P (acj) , ∀(aci, acj) ∈ ACL (5.5)

3. Response time constraint: This constraint enforces the total response

time of the SaaS, TET , to be bounded by rt, TET ≤ rts. Calculation

of the TET is similar to that de�ned in Chapter 3, with the exception of

the two attributes below. These changes are made to include the a�ect of

having more than one replica as well as to include the number of tenants.

• the processing time, PT , of a component, aci, in a VM:

PT (aci) =

((pcReqi ×

∑t∈T ut

)/ki)/maxUseri

pcvmaci× y

(5.6)

where pcReqi is the processing requirement of aci, ut is the number

of user for tenant t, ki is the number of replica for aci, maxUseri is

the maximum user aci can serve, pcvmaciis the processing capacity

of the VM that hold aci, and y is the utilisation rate of vmaci .

• the time taken, TT , of a component, aci, for transferring data bet-

ween a VM to a storage server, or between VMs that are hosted at

di�erent computation servers:

TT (aci) =

((amountRWi ×

∑t∈T ut

)/ki)/maxUseri

Bvi,vj × y+ Lvi,vj (5.7)

136


where amountRWi is the read/write amount of aci, ut is the number

of user for tenant t, ki is the number of replica for aci, maxUseri is the

maximum user aci can serve, Bvi,vj is the bandwidth between two servers,

Lvi,vj is the latency, and y is the utilisation rate of the link.

Output A scaling plan for application components,

R = {R1 ∪R2 ∪Ri ∪ ... ∪Rx} , 1 ≤ i ≤ x, where x is the total number

of application components. Let Ri denote the scaling plan for aci, where

Ri = {(aci,1, P (aci,1)) , (aci,2, P (aci,2)) , ..., (aci,k, P (aci,ki))} and aci,ki is the kth

replica of aci, P (aci,k) is its placement and ki ∈ N.

Objectives The objectives of the problem are:

1) to minimise the number of computation servers used,

min∑

csi∈CS

dcsi (5.8)

where

dcsi =

1, ∀j∈AC∃i∈CS | P (acj) = csi

0 otherwise

2) to minimise the cost of VM used,

min∑

vmi∈VM

costvmi(5.9)

where

costvmi=

pricevmi, ∀j∈AC∃i∈VM | P (acj) = vmi

0 otherwise

3) to minimise the number of replica created

min∑

aci∈AC

kaci (5.10)

while satisfying all the constraints.

137


5.3 Related Work

A considerable amount of literature has been published on service scalability.

In this section, existing research on scalability is reviewed based on the sca-

lability levels: infrastructure and application. Research on object and data

scalability will also be discussed. The discussion will focus on replication and

deletion as the mechanism of scalability.

At the infrastructure level, there are a couple of commercial Cloud provi-

ders that o�ering add-on features that aim to scale the IaaS (Infrastructure

as a Service) that users rent. For instance, Amazon o�ers Amazon Cloud

Watch1 and Amazon Auto-scale2 for its EC23 service. Amazon EC2 or Elastic

Compute Cloud service provides resizable computation capacity for users. A

unit of EC2 can be considered as a VM that has its own memory, processing

capacity and storage. Amazon provides Cloud Watch to monitor the perfor-

mance of each EC2, including its CPU utilisation, disks read and write and

network tra�c. This information is then used in Amazon Auto-scale, in which

users determine their scalability rules to replicate or destroy EC2 in order to

cope with its demand or to minimise the costs. A scalability rule is a condi-

tion�action statement based on the current resource metric, for example, `if

CPU utilisation is greater than 60% for more than 5 minutes, increase the

number of EC2 by 10%'. Another commercial service for scalability is Right-

Scale4, a management platform for users to manage their Cloud resources from

multiple providers. Through the platform, RightScale allows users to set their

scalability rules based on computation resources in order to control their Cloud

VM. Both scalability solutions o�ered by Cloud providers focus on servers' re-

sources (CPU, memory, disk) in respect of the scalability metrics. While this

works well for handling VM scalability, �ner granularity is needed to handle

application scalability, particularly for applications like composite SaaS. This

is especially so when a VM contains more than one SaaS application com-

ponent and each application has di�erent workloads. If one of the applications

has a higher demand than the others, replicating the whole VM may not be a

good solution, as it will a�ect the utilisation of resources. As such, scalability

1http://aws.amazon.com/cloudwatch/2http://aws.amazon.com/autoscaling/3http://aws.amazon.com/ec2/4http://www.rightscale.com/

138

5.3. Related Work

rules that use application attribute metrics are better than resource metrics in

handling the application scalability.

One of the most recent research at the application level is that of Rodero-

Merino et al. [123]. In this research, the authors di�erentiated the roles of

Service Providers (SPs) between the one that owning the service and Cloud

provider, the one owning the infrastructure. Another abstraction layer, named

Claudia, is proposed and implemented to o�er a high level interface for SPs in

managing their services. Claudia provides a wide range of scalability rules that

focus on meeting the quality of the solution of the application instead of dealing

with the rules for low-level resources. Application components under Claudia

management will be replicated or destroyed based on the selected rules. In

addition, Claudia can also be implemented across di�erent Cloud providers

to avoid Cloud vendor lock-in. Claudia provides no solution concerning the

placement of the replica, as this is under the authority of the Cloud provider

instead of that of the SP. Lee and Kim [94] also proposed an application-

oriented solution for a scalable service in the Cloud. They used two di�erent

mechanisms for scalability � replication and migration. The replication of

an application is triggered if the application exceeds the threshold for the

response time. For the placement of the replica, all nodes are checked for

their suitability for hosting the new replica. In another similar study, Chieu

et al. [26] described their architecture for scaling of web applications in a

virtualised Cloud data centre. The architecture consists of a load balancer

that balances the incoming request among replicas and a scaling algorithm that

creates a new replica based on the number of active sessions of an application.

In this solution, the object to be replicated is the VM. All the studies described

above have provided a convenient and innovative way to manage application

scalability using application-oriented metrics, as opposed to infrastructure-

oriented metrics. However, the replication and delete process is still done at

the VM level instead of the application level. As such, the solutions will have

a similar problem to that discussed earlier, inasmuch as there might be some

applications that are forced to be replicated due to the replication of their

host.

None of the previously mentioned studies took into account an applica-

tion that needs to communicate with another application in order to deliver

its tasks. This gap is addressed by Bonvin et al. [16], who proposed geogra-

139


phically diverse application component replication in a Cloud infrastructure.

In their solution, each component acts as an agent that rents resources from

its host server. The agent migrates, deletes and replicates itself based on its

economic �tness, where the �tness represents the value of the utility of the

component as compared to its cost. The placement of the replica is based

on the geographical location, where the least loaded and closest server from

its communication component will be chosen. Wu et al. [142] investigated

the scalability of composite web services in a Cloud based on the producti-

vity of the service, which is measured based on the bandwidth consumed by a

particular composite service. They designed a GA to search the best replica-

tion and placement plan for the web service, such that the productivity of the

scaled service is maximised. Similar research concerning the communication

between services was presented by Urgaonkar et al. [135]. They proposed a

provisioning technique for a multi-tier Internet application that includes reac-

tive provisioning for the application's scalability in order to respond to �ash

crowds. Each tier is checked at every interval time and any tier that exceeds its

resource threshold is allocated more resources. Other related tiers are checked

to ensure no bottleneck occurs. However, none of these studies considers the

overall performance of the application as its performance indicator. Although

to some extent the dependency of one application on another application is

considered, the evaluation of the action taken is still independent: this di�ers

for a composite SaaS that has an overall target performance to meet.

Apart from service/application replication, several early research concen-

trated on replicating web contents, refering to objects like an HTML page, an

image, or a �le that is accessed from multiple locations on the Internet [104].

Tenzakhti et al. [133] proposed two replication algorithms for object replica-

tion on websites where the websites are interconnected by a communication

network. Both algorithms use greedy heuristics in which the �rst algorithm

operates in a centralised location while the second is for distributed replica-

tion. In the centralised version, a central site acts as a replication mechanism,

determining the number of replicas needed and the location of the replicas to

minimise a cost function, while in the distributed version, each site makes its

own decision whether to replicate or destroy the objects, based on statistical

information collected from other sites. The cost function used is the reading

cost from the source site to the target site. Another similar research proposed

140

5.3. Related Work

by Mahmood [104], used a hybrid solution that consists of a tabu search with

a particle swarm optimisation algorithm to solve the placement problem of the

replication of web contents. The placement is done based on the total read

and write requests of the objects, subject to the total storage capacity of a

site. In both works, the strategies applied in the object replication problem

and its placement consider the cost of communication between the sink and

target sites, which is one of the highlights of the composite SaaS replication

problem. However, the object is evaluated as an independent entity where it

does not have to communicate with other objects in delivering its functiona-

lity. In addition, the solution addresses the constraints at the infrastructure

level only, which is the capacity of the storage, and not the constraints at the

application level.

Another similar area that has a signi�cant amount of research done is the

data replication problem. Loukopoulos and Ahmad [102] proposed two heuris-

tics for the data replication problem with static read and write patterns. The

�rst heuristic is a greedy algorithm, which uses the replication bene�t value in

making its decision. The replication bene�t value basically determines whether

it is bene�cial to replicate a data component considering its read and update

cost. The second heuristic is a genetic algorithm that aims to minimise the

total network transfer cost that arising from the read and write to/from an ob-

ject's activities. More recent work on this problem was presented by Lim et al.

[99], who addressed the scalability of the storage servers in a Cloud data centre.

They implemented a controller that uses the conventional control theory tech-

nique in which users can con�gure the threshold of infrastructure metrics in

the controller for replicating storage servers. The controller also determines

the amount of bandwidth needed to rebalance the data after the replication

process using a cost-optimisation-based approach. Among the things that can

be taken from the research in this area are the data replication bene�t value

and the optimisation of the bandwidth needed for the communication process;

however, the formulations of data replication and composite SaaS application

are di�erent in which the latter has more constraints that need to be considered

compared to the former. For instance, the application replication has to consi-

der the processing capacity of the servers and the overall performance as well

as the communication between application components and data components.

The prior research discussed above has motivated the direction of this thesis

141


towards studying the replication problem for a composite SaaS in the Cloud

data centre. This is due to the challenges resulting from a composite SaaS

replication problem, which may be more suitably addressed to both the appli-

cation and infrastructure layers than to one layer only. In addition, to utilise

the resources used and to avoid unnecessary replication, the granularity of the

replication must be at the application level instead of at the VM level. The

overall performance of the SaaS must also be considered in evaluating the re-

plication decisions. To address such issues, a hybrid genetic algorithm for a

composite SaaS replication problem is proposed. The following section will

describe the algorithm in detail.

5.4 A Hybrid Genetic Algorithm

It has been proven in the existing literature that deciding how many replicas for

an object and where to place them is an NP hard problem [83][102]. Therefore,

a hybrid GA (HGA) is developed to address the problem formulated in Section

5.2. A composite SaaS consists of two types of components � application

and data. For this scaling problem, only the application component will be

considered for replication; however, communication between these two types of

components is formulated as one of the deciding factors in �nding the solution.

The proposed algorithm will �nd the best scaling plan for a composite

SaaS such that it can minimise the total resource usage without violating its

constraints. There are two main processes in producing the scaling plan: 1)

selection of components to replicate/delete and the number of replicas, and 2)

the placement of the replica. Unlike most scaling algorithms that use rules to

trigger the scaling process, HGA attempts to solve the problem by exploration

of the search space using its genetic search operations to transform the initial

population of the solution based on the problem's objective. The HGA also

utilises two types of domain knowledge in order to improve its performance,

as outlined below.

Knowledge at the application level: Each component has a number of

maximum users it can serve at a time. It is assumed that this knowledge is

given by the SaaS developers based on their own experience and knowledge

of the SaaS. This knowledge will then be used as the upper boundary for the

142

5.4. A Hybrid Genetic Algorithm

Figure 5.2: An example of a chromosome representation

component's replication process as well as for calculating the total execution

time of the SaaS, given the current users at a particular time. The response

time is formulated as one of the constraints in this replication problem.

Knowledge at the infrastructure level: At the infrastructure level, the

algorithm will use the knowledge of the location and the utilisation rate of

VMs in order to decide the placement of a replica.

Algorithm 11 describes the HGA. In the HGA, Steps 1 and 2 are to ini-

tialise the best solution and the best replication plan. Step 3 is responsible

for generating the initial population using domain knowledge, instead of the

traditional random generation of the initial population. This introduces good

seed into the initial population to increase the likelihood of �nding the best

solution. The initial population generation procedure is described in a later

section. Each individual is checked for resource requirement constraints in

Steps 6 and 7. Steps 8 and 9 are responsible for evaluating the �tness of

all individuals in the initial population. The best replication plan and best

�tness will be stored. Steps 12 to 15 are the evolving processes in which selec-

tion, crossover, mutation and �tness evaluation are performed. The following

sections explained the main parts of the algorithm in detail.

Genetic Encoding

The chromosome (or individual) is encoded by three one-dimensional parallel

integer arrays of x genes, where x is the number of components in the composite

SaaS. The �rst array represents the component, the second represents the

replication �ag, and the third array stores the VM for the replica(s). The

replication �ag is encoded by a signed integer where a positive value means the

replication process, a negative value means the deletion process, and 0 means

the current number of replica remains. Figure 5.2 illustrates the representation

of one chromosome with x application components.

143


Algorithm 11: The hybrid genetic algorithm (HGA)

1 bestF itness = 02 bestP lan = 03 create an initial population Population of PopSize individuals, basedon the initialisation procedure in Section 1.4.2


6 if X violates SaaS resource requirements constraint then7 Repair(X)

8 Calculate X �tness value, F (X), penalised if X violates SaaSplacement constraint and response time constraint

9 if F (X) > bestF itness then10 Replace bestF itness11 bestP lan = X




Population

16 output bestF itness17 output bestP lan

144


Initial Population Generation

The initial population in classical genetic algorithms is usually generated ran-

domly. However, to ensure that the population starts o� the exploration with

good seeds, HGA uses a procedure that utilises the domain knowledge. There

are two tasks involved in generating the initial population.

The �rst task is to determine the number of replicas for each component.

The value will be generated from a range, with a lower bound of 1 (no replica-

tion at all). For the upper boundary, two di�erent methods are implemented.

The �rst method determines the upper boundary, UB, based on a formula

where the total users of all the tenants of the SaaS are divided by the maxi-

mum users of all the components in the AC, as shown in Equation 5.11.

UB =∑

aci∈AC

∑tj∈T utj

maxUseraci(5.11)

The second method determines the upper boundary using the results pro-

duced by a random replication algorithm, as shown in Algorithm 12. It is

assumed that the algorithm is triggered if the response time constraint of the

SaaS is violated, and all components have only one instance at the point the

algorithm is triggered. The algorithm will randomly replicate the component.

If the replication can shorten the SaaS total execution time, the replica will be

kept. The process will continue until the time constraint is satis�ed or until

there is no improvement for 100 iterations. The result of each component will

be stored as the upper boundary for the component. A comparison discussion

between these two methods is presented in Section 5.5.1.

The second task in generating the initial population is to �nd the placement

for the new replica or to select a replica to delete. For the placement, the least

utilised VM and closest to its communicating component is chosen. For the

deletion process, a replica in a least-loaded VM will be selected. Algorithm 13

shows the algorithm description for the initialisation procedure; Algorithm 14

shows the placement procedure.

The placement procedure will �nd the closest and least utilised VM to place

the replica. The utilisation of a VM is calculated based on the SaaS demands

for the computation resources, including processing capacity, memory, secon-

dary storage and bandwidth. The composite SaaS is served to a number of

145


Algorithm 12: The random replication algorithm

1 UBi = 02 count = 03 while (TETs > rts and count < 100) do4 for (aci ∈ AC) do5 Choose replicate ∈ {true, false} at random6 if (replicate) then7 Create a new replica for aci8 Find aci placement9 Calculate the new newTETs

10 if (newTETs < TETs) then11 Accept the replica and its placement12 UBi = UBi + 1

13 else

14 count = count+ 1

Algorithm 13: The initialisation procedure

1 for (j = 1 to PopSize) do2 for (aci ∈ AC) do3 Take a random value from [1, UBi] for replicaNum4 if (replicaNum > currentReplica) then5 replicaF lag = replicaNum - currentReplica6 for k = 1 to replicaF lag do7 Create a new replica, aci,k8 Find aci,k placement

9 else if (replicaNum < currentReplica) then10 replicaF lag = replicaNum - currentReplica11 for k = 1 to (currentReplica-replicaNum) do12 Destroy aci,k

13 else

14 replicaF lag = 0

146


Algorithm 14: The placement procedure

Input : aci,kOutput: VM

1 Get successor component for aci,k2 Find the least utilised VM and the closest VM to successor3 Place aci,k onto the VM

tenants in which each tenant has a di�erent number of users. It is assumed

that the resource demands of the SaaS components are linearly proportional

to the number of tenants and the total number of users for all tenants [91].

The VM utilisation is calculated using Equation 5.12 to Equation 5.15 for each

of the resources.

Utilisation of processing capacity: The utilisation of processing capacity

of a VM, vmj, is calculated based on the sum of the requirements of the pro-

cessing capacity by all components for all users in the VM and the additional

processing capacity required to isolate tenants from each other in the shared

components, as given below:

UtilPcvmj =

(∑aci,j∈AC pcReqaci,j ×

∑t∈T ut

)+ fpc−overhead (|T |)

pcvmj

× 100

(5.12)

where pcReqacij is the processing requirement for aci at vmj, ut is the total

number of user for tenant t, fpc−overhead is the additional processing capacity

required for tenants' isolation and pcvmjis the processing capacity for vmj.

Utilisation of memory The memory requirement for a component is quite

independent from the load of the component. This is due to the di�erent

way the memory is managed in a computation server. As such, to determine

the memory demand based on the number of tenants and users is not really

accurate. Thus, in this problem, the memory requirement of a component is

considered as an upper limit of the memory usage. The calculation for its

utilisation for a particular VM, vmj, is de�ned as:

UtilMemvmj =

∑aci,j∈AC memReqaci,j

memvmj

× 100 (5.13)

147


where memReqacij is the memory requirement for aci at vmj and memvmjis

the memory capacity for vmj.

Utilisation of Secondary Storage The utilisation of the secondary storage

of a VM, vmj, is calculated based on the size of the component as well as the

overhead storage to isolate tenants in the shared environment:

UtilSSvmj =

(∑aci,j∈AC sizeaci,j

)+ fss−overhead (|T |)

diskvmj

× 100 (5.14)

where sizeacij is the size of component aci at vmj, fss−overhead is the additional

storage required for tenants' isolation and diskvmjis the disk capacity for vmj.

Utilisation of bandwidth A component may communicate with other com-

ponents and read/write data from/to storage servers. The amount of commu-

nication between the components is dependant on the number of users that

the component has. This will be used as a basis to calculate the estimated

utilisation of a VM's bandwidth:

UtilBW vmj= max

(amountRWaci,j ×

∑t∈T ut

Bvmj ,vmk

)× 100 (5.15)

where amountRWaci,j is the read/write task t for aci at vmj, ut is the total

number of user for tenant t, and Bvmj ,vmkis the bandwidth from vmj to vmk,

and vmj, vmk ∈ E.

5.4.1 Genetic Operators

The crossover and mutation operators are responsible for exploring the search

space for the HGA. A single-point crossover is implemented, as shown in Fi-

gure 5.3. In this crossover, two chromosomes are selected based on the roulette

wheel selection scheme. A randomly selected point in each of the chromosomes

is chosen and the part after the point is exchanged and merged together to

produce two child chromosomes. The chromosomes will be checked for re-

148


Figure 5.3: An example of crossover procedure

Figure 5.4: An example of mutation procedure

source requirement constraints and will be repaired accordingly. The best two

chromosomes from the parents and child chromosomes will be copied to the

next generation.

The chromosomes are randomly selected for mutation operation. A new

value for the replication �ag of a component is generated based on the com-

ponent's replica range. Based on the new value, the replication or destroy

process will be carried out. The procedure for mutation is shown in Figure

5.4.

5.4.2 Fitness Function

As formulated in Section 5.2, the problem has three di�erent objectives that

need to be optimised and constraints that need to be complied with. The HGA

uses a weighted aggregation approach in which each objective and constraint is

given a weight value depending on its importance in the context of the problem.

The sum of all the weight values is one. Then a composite objective function is

formed by summing the weighted objectives and converting them into a single

objective optimisation. One of the other approaches for handling the multi-

objective optimisation is the population-based non pareto and pareto approach

[41][46]. However, the chosen approach has a couple of advantages for this

problem compared with other approaches. First, the objectives of the problem

149


have rankings that represent their priority in the problem. The replication of

the components needs to be carried out in order to maintain the performance of

the SaaS with the minimum cost possible. Thus, the costs for the replication

plan and its compliance with the constraint have higher priority than the

total replica created. Second, the weighted aggregation approach produces

a single compromise solution, and thus it does not need further interaction

with the decision maker. This is important since the algorithm is executed

automatically with no intervention from human administrators.

Equations 5.16 to 5.18 provide the de�nition of the objective functions of

the problem, and Equations 5.19 and 5.20 give the value of the constraint

violation for the placement and response time constraint.

Fobj1 = 1−(Rmax −

∑csi∈CS dcsi

Rmax

)(5.16)

where Rmax is the maximum number of possible replication for all components,

de�ned as Rmax = UB × |AC| , and dcsi is the number of computation server

used by the SaaS.

Fobj2 = 1−(RmaxCost −

∑vmi∈VM costvmi

RmaxCost

)(5.17)

where RmaxCost is the maximum cost for Rmax, de�ned as RmaxCost = Rmax ×max(costvm) and costvmi

is the VM cost for the SaaS.

Fobj3 = 1−(Rmax −

∑aci∈AC kaci

Rmax

)(5.18)

where kaci is the number of replica created for aci.

CV1 =

∑aci,k∈Ri

PC∑aci∈AC kaci

(5.19)

where PC = 1 if the placement of component aci violated its constraint and

kaci is the number of replica created for aci.

CV2 =

1, TET ≥ rts

0, otherwise(5.20)

where TET is the total execution time of the SaaS, and rts is the response

time constraint.

150

5.5. Evaluation

A penalty function will be used to determine the degree of infeasibility

raised by violation of these constraints. The �tness function is designed so

that an infeasible solution has a lower �tness value than any feasible solution,

and an infeasible individual that violates more constraints will be penalised

more than the solution that has lower constraint violations.

Equation 5.21 de�nes the �tness function of the problem.

F (X) =

∑

j∈3 Fobjj(X)× wobjj + 0.3,∑

i∈2 CVi = 0∑j∈3 Fobjj(X)× wobjj ×

(1−

∑i∈2 CVi

|CV |

), otherwise

(5.21)

where∑

j∈3wobjj + 0.3 = 1.

In Equation 5.21, the �tness of an individual is determined by the sum of

objective functions multiplied by its weightage. If X is a feasible solution, its

�tness will be added by 0.3, where this value represents the reward for feasible

solutions. This value is obtained through a number of trial experiments in

which the value that produced the best solutions is used. Otherwise, its �tness

will be multiplied by the expression(1−

∑i∈2 CVi

|CV |

), which guarantees that the

more constraints that an infeasible individual violates, the lower is its �tness.

Based on the �tness de�ned, the value of any feasible solutions will always be

higher than the infeasible ones by 0.3.

5.5 Evaluation

This section presents the evaluation plan and discusses the results of the eva-

luation. Several experiments were carried out to evaluate the proposed algo-

rithm in respect of: 1) the quality of solutions produced, and 2) the scalability

of the HGA. First, the evaluation of the two di�erent methods to determine

the upper boundary of a component's replication described in Section 5.4 is

conducted. This is explained in the next section.

151


Table 5.1: Test problems and upper boundary values for HGA(F) and HGA(R)

Test Problem Cloud serversUpper boundary valuesHGA(F) HGA(R)

1 300 134 52 400 134 163 500 134 19

5.5.1 Evaluation of methods in determining the upper

boundary

In generating the initial population, the proposed algorithm determines the

number of replicas for each component based on a random value generated from

a predetermined range. Two methods were used in determining the range's

upper boundary. In the �rst method, the upper boundary is determined using

Equation 5.11; while the second method uses the result produced by a random

algorithm presented in Algorithm 12. A detailed explanation concerning this

can be found in Section 5.4.

To analyse the e�ect of these two di�erent upper boundary values on the al-

gorithm performance, a set of experiments was designed. Two variants of HGA

were implemented � HGA(F) uses the �rst method, HGA(R) uses the second

method. Both algorithms have exactly the same parameters � the population

size is 100, crossover and mutation probability are 90% and 10% respectively

and termination condition is `25 consecutive generations with no improvement

on the best solution'. The algorithms were executed for 20 independent runs on

three test problems which have 15 SaaS components, 200 tenants with 15,927

users that were generated randomly, and di�erent numbers of Cloud servers.

Table 5.1 shows the characteristics of the test problem as well as the upper

boundary for HGA(F) and HGA(R).

The following results were recorded: the average number of computation

servers (CS) used by the replication plan, its average VM costs and the average

of the total number of replicas created. The average computation times for

both algorithms were also recorded. The results are shown in Table 5.2 and

Figure 5.5.

It can be seen from the table that the algorithm using the upper boundary

produced by Algorithm 12, HGA(R), has better solutions (in boldface) in all

test problems compared with HGA(F), which uses the upper boundary from

152

5.5. Evaluation

Table 5.2: Comparison results of the HGA(F) and HGA(R)

Test Problem Algorithm Avg. #CS Avg. VM Cost Avg. #Replica

1HGA(F) 15 49.01 29HGA(R) 9 26.02 11

2HGA(F) 16 54.06 28HGA(R) 10 35.06 13

3HGA(F) 18 61.34 31HGA(R) 10 34.72 13

Figure 5.5: The computation times for HGA(F) and HGA(R)

the formula de�ned in Equation 5.11. HGA(R) uses about 36 to 44% fewer

servers, 35 to 47% less cost and has 51 to 62% fewer replicas than HGA(F). It

should be noted that the upper boundary for HGA(R) for all test problems is

much lower than for HGA(F), which indicates that the solution search space

for the HGA(R) is quite signi�cantly reduced from the solution search space

for HGA(F). For some problems, this may not be an ideal way since space for

promising solutions might be omitted. However, in this problem, the better

solution achieved by HGA(R) shows that the solution space is reduced e�-

ciently without the loss of optimal solutions. Based on these results, it can be

concluded that HGA(R) provides a good starting point for the initial popula-

tion for this problem. As for the computation time, it can be seen from Figure

5.5 that HGA(R) took a longer time than HGA(F) in �nding the solutions.

However, since the di�erence is about 12 to 90 seconds, and considering the

large improvement it made for the solutions, this is still acceptable.

153




#Computation servers #Storage servers #Total servers1 100 60 1602 200 120 3203 300 180 4804 400 240 6405 500 300 800

5.5.2 Evaluation of the performance and the scalability

of the HGA

Test Problems

The scalability and quality of the HGA were tested on a number of problem

instances with di�erent sizes and complexities. The size of the problem is de-

termined by three dimensions: 1) the number of Cloud servers in the problem,

2) the number of tenants and their corresponding users, and 3) the number of

applications and data components. Three types of problem representing each

of the dimensions are created to evaluate how these dimensions a�ect both

the quality of the solution, produced by HGA, and its scalability. The quality

of solution is evaluated based on the objective function as a whole as well as

on the three objectives separately. For scalability evaluation, the computation

time taken to produce the solution is measured. Below is the elaboration of

these three test problems.

Test problems with di�erent numbers of Cloud servers Five test pro-

blems were constructed with di�erent numbers of Cloud computation servers

and storage servers. For computation servers, the number ranges from 100 to

500, while for storage servers the number ranges from 60 to 300. The attributes

of the Cloud servers were randomly generated using the models presented in

the Hewlett-Packard and IBM websites [55][63]. The communication between

the servers was also generated randomly. Table 5.3 shows the total number of

servers for each test problem. For all test problems, the number of application

components is set to 10, data components to 5 and the number of tenants to

200.

154

5.5. Evaluation

Table 5.4: Test problems with di�erent numbers of tenants

Test ProblemTest Problem CharacteristicsNo. of tenant No. of users

1 300 23,6072 350 26,1093 400 31,7154 450 34,0305 500 39,660

Table 5.5: Test problems with di�erent numbers of application components


#Application components #Data components #Total1 5 2 72 10 5 153 15 7 224 20 10 30

Test problems with di�erent numbers of tenants Five test problems

were created with a �xed number of computation servers (400), storage ser-

vers (240), application components (10), and data components (5), and with

varying number of tenants ranging from 300 to 500, with an increment of 50.

For each tenant, the minimum user is set to 1, the maximum number of users

is 200 and the value will be generated randomly. Table 5.4 shows the tenants

with their corresponding number of users.

Test problems with di�erent numbers of application components

Four test problems were designed with composite SaaS with di�erent num-

bers of application and data components and a �xed number of Cloud servers

and tenants. The number of application components ranges from 5 to 20, while

the number of data components is from 2 to 10. Table 5.5 shows the number

of components for each test problem. The problem with ten application com-

ponents and �ve data components is illustrated in Figure 5.6. This is used as

a building block to construct other test problems that have more components.

The number of computation servers is set to 500, storage servers is set to 300,

and the number of tenants, to 200.

155


Figure 5.6: A composite SaaS with ten application components and �ve data com-ponents

A Greedy Algorithm

Although comparing the HGA to the optimal solution obtained by an exhaus-

tive search is the best way to illustrate the performance of the algorithm,

such a search is able to provide an optimum solution for small size problems

only. Since this is not the case, a simple greedy algorithm is developed for

comparison. Basically, the greedy algorithm will replicate a component if the

replication brings bene�t to the SaaS performance in terms of its total exe-

cution time. It is assumed that at the start of the algorithm, all components

have only one instance. Algorithm 15 shows the greedy replication algorithm.

Step 1 is responsible for triggering the replication process based on a scalabi-

lity rule, where the response time constraint is used as the metric. For each

component in the composite SaaS, the algorithm increases its replica by one.

This is done in Step 4. Step 5 �nds a placement for the replica using the

placement algorithm outlined in Algorithm 14. With the addition of the new

replica, the total execution time of the SaaS is recalculated. If the replica can

improve the time, then it is accepted in the replication plan. The process is

done for all components, and continues until the response time constraint is

satis�ed or until there is no improvement for 100 consecutive iterations.

Experimental Results

A number of experiments were conducted to evaluate the scalability and e�ec-

tiveness of the proposed algorithm. The HGA(R) version was used in these ex-

periments since it yields better results than HGA(F). In this section, HGA(R)

156

5.5. Evaluation

Algorithm 15: The greedy algorithm

1 count = 02 while (TETs > rts and count < 100) do3 for (aci ∈ AC) do4 Create a new replica for aci5 Find aci placement6 Calculate the new newTETs

7 if (newTETs < TETs) then8 Accept the replica and its placement9 count = 0

10 else

11 count = count+ 1

is referred to as HGA only. In order to conduct the evaluation, the algorithm

was implemented in Microsoft Visual Studio C++ 2010. The greedy algorithm

introduced in the previous section was implemented in the same language. All

the experiments were conducted using a desktop computer with 3 GHz Intel

Core 2 Duo CPU and 4GB RAM. The parameter setting for HGA is illustra-

ted in Table 5.6. These parameters were obtained through trials on randomly

generated test problems. Parameters that led to the best performance in the

trials were selected as the settings of the algorithms for the experiments below.

Table 5.6: Simulation parameters for the experiments

Parameter ValuePopulation size 100Crossover rate 90%Mutation rate 10%Termination condition (# of generation without improvements) 25wobj1 0.25wobj2 0.25wobj3 0.2


This experiment evaluated how the number of Cloud computation servers af-

fects the solution quality and computation time of the HGA, compared to

using the greedy algorithm. Considering the stochastic nature of HGA, and

157


that the random element exists in the greedy algorithm, the experiments were

executed 30 times for all problem instances. The objective of the problem is

to minimise the replication plan's cost while satisfying the SaaS constraints

with the minimum number of replicas possible. The cost here refers to the

resource cost that is used for the components, which includes the number of

computation servers (CS) used and the price of VM. For all test problems, the

best, worst and average for the number of replicas created, the number of CS

used and the price of VMs, along with their standard deviation, were recorded,

as shown in Table 5.7.

In the table, the bold-face values represent the best average values in each

category between the two algorithms. It can be seen that both algorithms

can always produce feasible solutions. The HGA can always �nd a better

result for all categories in each test problem than the greedy algorithm �nds.

For all test problems, the HGA generates fewer replica components while still

maintaining the SaaS performance. In addition, the number of CS used and

the VM cost indicate that the HGA can �nd a better placement for all replicas

generated. For example, for test problem 3, the di�erence in the number

of replicas created between the two algorithms is small: HGA generated 10

replicas on average while the greedy algorithm generated 13. However, the

HGA used only 8 computation servers to host these replicas with the cost of

VM being 30.3, while the greedy algorithm used 12 servers with the cost of

VM being 39.2. In this test problem, the HGA saved about 33% for the CS

used and 34% for VM cost. The highest saving was for test problem 5, which

has the highest number of Cloud servers. In this particular test problem, the

HGA solutions saved about 41% for CS and 44% for VM cost. This re�ects the

capability of the HGA to explore the search space e�ciently as the number of

servers grows, and to �nd the better placement for the replicas created, while

the greedy algorithm fails to do so. Comparisons using one-tailed t-tests were

also conducted between the HGA and the greedy algorithm for the number

of replica created, the number of computation servers used and the VM cost

used. The results con�rmed that the means are signi�cantly di�erent, with

99% con�dence level in all test problems.

To evaluate the overall performance of the algorithms reported in Table 5.7,

an overall objective function, F (X), is formulated based on the �tness function

in Equation 5.21. The overall objective function is de�ned in Equation 5.22.

158

5.5. Evaluation

Table5.7:

Experim

entalresultsof

theHGAandgreedyalgorithm

fortest

problemswithdi�erentnumbersof

Cloudservers

Test

Algorithm

Avg.

#Replica

Avg.

#CS

Avg.

VM

Cost

Problem

Best

Worst

Avg

Std

Dev

Best

Worst

Avg

Std

Dev

Best

Worst

Avg

Std

Dev

1HGA

1013

11

0.8

48

60.9

15.7

24.4

18.9

2.3

Greedy

1317

150.9

1116

141.1

36.2

53.4

45.1

4.2

2HGA

1324

17

2.6

816

11

1.6

26.6

51.9

36.3

6.3

Greedy

2240

274.2

1723

201.6

47.6

75.5

58.1

6.4

3HGA

1012

10

0.5

108

80.7

23.2

30.3

25.7

2.1

Greedy

1213

130.4

1212

120

3741.6

39.2

1.08

4HGA

1117

14

1.6

714

11

1.8

25.3

52.4

36.5

6.4

Greedy

1524

162.4

1419

151.4

43.4

65.2

50.2

4.5

5HGA

1217

14

1.3

912

10

0.9

28.8

43.9

35

4.1

Greedy

1529

193.7

1420

171.6

54.5

74.8

62.7

5.4

159


Figure 5.7: Comparison of the overall objective function, F (X), of the HGA and thegreedy algorithm for di�erent numbers of Cloud computation servers

The F (X) value is based on the sum of scores for each category multiplied by

its weightage. High values of F (X) indicate good solutions. The weightage

for CS used and VM cost is set to 0.4, while the number of replicas is set to

0.2. Figure 5.7 illustrate the value of F (X) for both algorithms for the �ve

test problems. The overall result is consistent with the result in the separate

category presented in Table 5.7. Based on the �gure, the HGA has higher

values of F (X) in all test problems, which indicates that it produced a better

replication plan for the problem.

F (X) =∑j∈3

Fobjj(X)× wobjj (5.22)

The growth trend of the computation time of both algorithms is shown

in Figure 5.8. From the �gure, it can be seen that there is no correlation

between the number of Cloud servers and the time taken by both algorithms.

Another important thing to note is the large gap between the time taken by

HGA and by the greedy algorithm: HGA took about 4 to 8 minutes to produce

the solutions, while the greedy algorithm took less than one second for each

test problem. Although the greedy algorithm is fast in computation time, the

quality of results produced are not convincing for the use of this algorithm for

solving the replication problems. For all test problems, the best result achieved

by the greedy algorithm for the number of replicas created, as well as for the

CS and VM cost, is still higher than the average result of the HGA.

160

5.5. Evaluation

Figure 5.8: Comparison of the computation time of the HGA and the greedy algo-rithm for di�erent numbers of Cloud computation servers

Experiments on the Number of Tenants

This experiment evaluated how the number of tenants a�ects the quality of

solutions as well as the computation times of both the proposed algorithm and

the comparison algorithm. Both algorithms were executed 30 times for each

test problem.

The comparison results of the solution quality found by both algorithms

for the three objectives are shown in Table 5.8. It can be seen that both

algorithms can always �nd feasible solutions for each test problem. The table

also shows that the HGA can always �nd a better solution (in bold) for all the

problem objectives in the �ve test problems, compared to the greedy algorithm.

The results were quite similar with the experiments on the number of Cloud

servers, in which the HGA outperformed the greedy methods in terms of the

number of replicas, as well as the placement cost. The t-tests also produced

similar results with the previous experiments, where the HGA and heuristic are

statistically di�erent (p < 0.01) in all test problems. The overall performance

of both algorithms based on the objective function de�ned in Equation 5.22 is

shown in Figure 5.9.

For this experiment, it should be highlighted that, compared to the HGA,

161


Table5.8:

Experim

ental

results

oftheHGAandgreed

yalgorith

mfor

testprob

lemswith

di�eren

tnumbers

often

ants

Test

Algorith

mAvg.

#Replica

Avg.

#CS

Avg.

VM

Cost

Prob

lemBest

Worst

Avg

Std

Dev

Best

Worst

Avg

Std

Dev

Best

Worst

Avg

Std

Dev

1HGA

1117

14

1.310

1412

1.128.5

44.635.3

4Greed

y14

2216

1.614

5117

6.542.6

60.551.1

4.3

2HGA

1132

13

3.99

1211

0.813

41.234.3

5Greed

y13

3918

5.912

2515

3.243.6

108.255.7

13.3

3HGA

1324

17

2.412

2115

1.835.2

63.847.2

6.3Greed

y18

3727

5.417

2420

1.954.1

8869.9

8.2

4HGA

1429

18

3.511

1814

1.637.8

62.349

5.8Greed

y15

3830

6.615

2920

353.9

3868.8

11.3

5HGA

1738

26

4.816

2319

1.752

80.664.6

7.2Greed

y29

6950

9.918

3226

3.564.5

158.8106.1

22

162

5.5. Evaluation

Figure 5.9: Comparison of the overall objective function, F (X), of the HGA and thegreedy algorithm for di�erent numbers of tenants

the greedy algorithm tends to generate more replicas as the number of tenants

increased. Figure 5.10 shows the pattern for the number of replicas generated

between these two algorithms. It can be seen that the gap between the two

algorithms is increasing as the number of tenants grows. With new tenants

added, the HGA manages to retain a minimal degree of replications, resulting

in a linear increment. This is due to the non-deterministic nature of the HGA

in deciding the replications. The greedy algorithm created far more replicas

for a larger number of tenants.

Unfortunately, the better performance and the large cost savings of the

HGA are achieved at the expense of a large execution time. As shown in

Figure 5.11, the HGA computation time is much higher compared to that of

the greedy algorithm. In addition, there is no correlation at all between the

number of tenants and the computation time taken.


This experiment was an evaluation of how the number of SaaS application

components a�ects the quality of solution and computation time of the HGA

compared with the greedy algorithm. In each test problem, both algorithms

were executed 30 times.

Table 5.9 presents the results of the best, worst, and average, as well as

the standard deviation, for the two algorithms for the three main criteria of

the problem, and Figure 5.12 presents the overall performance based on the

163


Figure 5.10: Comparison of the number of replica created of the HGA and the greedyalgorithm for di�erent numbers of tenant

Figure 5.11: Comparison of the execution time of the HGA and the greedy algorithmfor di�erent numbers of tenant

164

5.5. Evaluation

Figure 5.12: Comparison of the overall objective function, F (X), of the HGA andthe greedy algorithm for di�erent numbers of SaaS application components

objective function in Equation 5.22. The numbers in boldface in the table

indicate the best average results between the two algorithms. From these re-

sults, it can be seen that the HGA achieved better results than the greedy

algorithm. Further analysis via a series of one-tailed t-tests with level of si-

gni�cance 0.01 for the three main criteria indicated a statistically signi�cant

di�erence between HGA and the greedy algorithm. It is also observed that

the quality of the solutions obtained by the HGA is especially better than that

of the greedy algorithm in the test problems with a higher number of com-

ponents. As illustrated in Figure 5.12, the di�erence in the score for F (X)

for the test problem with 5 components is only about 5%, while in the test

problem with 20 components the di�erence is 40%. This overall result is also

consistent with the results for each criterion, and it is particularly obvious in

terms of the number of replicas created. Figure 5.13 shows the replication

trend for both algorithms; the gap between the two results increases as the

number of SaaS application component increases. This observation should

be attributed to the fact that, by having more components in the SaaS, the

algorithms have more options of components to be replicated, together with

additional dependency complexities caused by the communication between the

components. The HGA tackles these e�ects more successfully than the greedy

algorithm does, through its better exploration of which of the components are

worth replicating.

No trend was observed for the computation time for the HGA as the number

165


Table

5.9:Experim

ental

results

oftheHGA

andgreed

yalgorith

mfor

testprob

lemswith

di�eren

tnumbers

ofSaaS

application

components

Test

Algorith

mAvg.

#Replica

Avg.

#CS

Avg.

VM

Cost

Prob

lemBest

Worst

Avg

Std

Dev

Best

Worst

Avg

Std

Dev

Best

Worst

Avg

Std

Dev

1HGA

611

81.4

49

71

15.532.2

23.1

3.3Greed

y9

1410

18

119

0.632

45.537.4

3.1

2HGA

1217

14

1.39

1210

0.928.8

43.934.9

4Greed

y15

2919

3.614

2017

1.615

74.846.8

21.7

3HGA

1824

20

1.614

2217

1.746.6

8261.8

7.9Greed

y20

3024

2.819

2522

1.768.7

9179.6

5.5

4HGA

2131

25

2.515

2218

1.747.8

78.161.8

6.9Greed

y27

4531

3.625

3628

2.393.05

147.8107.5

11.1

166

5.5. Evaluation

Figure 5.13: Comparison of the number of replica created of the HGA and the greedyalgorithm for di�erent numbers of SaaS application components

of application components increases, as shown in Figure 5.14. The longest time

taken is around 6 minutes. On the other hand, the greedy algorithm took less

than one second for all test problems conducted.

Summary of experimental results

The experiments described in this section have shown how the proposed algo-

rithm, HGA, performs with three di�erent variable dimensions � the number

of Cloud servers, the total number of tenants and the size of the composite

SaaS. The performance is compared with that of the greedy algorithm.

In the above experiments, HGA achieves more cost savings in its replication

plan as well as the replica placement plan in all variable dimensions. Compared

to the greedy algorithm, HGA can save up to 46% in overall performance when

evaluated with a di�erent number of Cloud servers, and up to 43% and 40%

when evaluated with various numbers of tenants and SaaS components. It has

also been shown that the proposed algorithm achieves far better results than

the greedy method when the number of tenants and the number of application

components are both large. This shows that the algorithm can respond well

to changes of demands and to the increment of SaaS components. It also

demonstrates the exploring ability of the algorithm in a large and complex

search space with constraints.

167


Figure 5.14: Comparison of the execution time of the HGA and the greedy algorithmfor di�erent numbers of SaaS application components

However, the performance of the HGA is a trade-o� with its computation

time. The HGA did not exhibit any trends of computation time taken in all

the experiments conducted. The longest time it took is about eight minutes,

while the greedy method, on average, took less than one second for all the

experiments.

5.6 Conclusion

This chapter studied the composite SaaS scalability problem in Cloud infra-

structure by addressing the composite SaaS scalability issues. A new hybrid

genetic algorithm is proposed to address new challenges arising from the pro-

blems: the granularity of the scale, the evaluation of SaaS performance as a

composite entity, and the dependencies of a SaaS components in replication

process. The problem was formulated as a combination of the components'

scaling and placement problems, with the main objective being to minimise

the cost of resources with the minimum number of replicas possible while sa-

tisfying the problem's constraints. A hybrid genetic algorithm (HGA) was

developed in which the problem's domain knowledge of the application and

infrastructure levels was utilised in the initial population generation as well as

in the placement process.

168

5.6. Conclusion

The performance of the algorithm has been investigated in three sets of

experiments. The overall results show that the proposed algorithm constantly

outperforms a heuristic algorithm in terms of solution quality for all test pro-

blems. The HGA gives an impressive performance by achieving low cost re-

plication and placement plans compared to the performance of the greedy

algorithm. Although the results show that the computation times for HGA

are high, this is still acceptable as the algorithm is meant to be executed du-

ring the o�ine maintenance phase of the SaaS, which is carried out at di�erent

timescales from minutes to hours.

169

Chapter 6

Conclusion

This chapter summarises the research carried out in this thesis. It also dis-

cusses the research contributions, and indicates some possible future research

directions.

6.1 Summary

This thesis has studied various types of evolutionary algorithms for the resource

optimisation problem on composite SaaS in a Cloud environment. The overall

goal is to develop e�ective and scalable algorithms to optimise the resources

used by the composite SaaS while maintaining the performance, particularly

in these three technical problems: 1) the placement problem, 2) the clustering

problem, and 3) the scalability problem. These problems are characterised

as large-scale, complex and constrained optimisation problems. A set of evo-

lutionary algorithms have been developed and the experimental results have

demonstrated the e�ciency and scalability of the proposed algorithms in sa-

tisfying the overall goal.

The composite SaaS placement problem was described in Chapter 3. This

problem concerned the initial placement of the composite SaaS onto the Cloud

data centre. The composite SaaS consists of a number of application com-

ponents and a number of data components that work together in delivering

the SaaS functionality to users. The placement of the components is based on

their type: the application components are placed in computation servers, the

data components in storage servers. This placement problem is distinguishable

from two other closely related problems. One is the component placement pro-

171

CHAPTER 6. CONCLUSION

blem, which refers to the decision problem of choosing the right server for the

application component. Another is the task assignment problem, which refers

to the assignment of a set of tasks to a number of machines subject to a set of

constraints in order to minimise its throughput or total execution time. Both

problems do not address several challenges that arise from the composite SaaS

placement problem, including the involvement of heterogeneous components

and servers, as well as the dependencies between di�erent types of components.

Therefore, a classical GA (CGA) and a cooperative co-evolutionary algorithm

(CCEA) are developed for the problem. The major feature of these algorithms

is the way they handled the di�erent types of component: the CGA evolved the

solution in one population while the CCEA splits it into two subpopulations.

The latter is further developed using two versions, iterative CCEA and parallel

CCEA. The experimental results demonstrated the impressive performance of

all the proposed algorithms, especially the parallel CCEA.

Chapter 4 described the clustering approach that is used in the resource

optimisation problem of multiple composite SaaS in a dynamic Cloud. Due to

the dynamic environment of a Cloud, the initial placements of SaaS compo-

nents need to be modi�ed in order to accommodate the changing workloads

as well as to optimise the resources. A signi�cant amount of research has al-

ready been done in optimising the resources in the dynamic environment of

a Cloud. Among the approaches are migrating the service, recon�guring of

the service and clustering the service. However, most of these research focu-

sed on the IaaS level instead of on the SaaS level. In addition, the existing

solutions do not concern either the dependency between the services or the

other composite SaaS constraints while modifying the initial placement. This

problem is formulated as a combinatorial optimisation constrained problem

that aims to modify the initial placement of the SaaS components by cluster-

ing the components, such that the resources are optimised while satisfying all

SaaS constraints. Two grouping genetic algorithms (GGAs) were developed

in which the encoding and genetic operations were designed according to the

SaaS clusters. Each of the GGA has a di�erent approach in handling the

constraints of the problem. The �rst GGA uses the repair-based approach,

while the second uses the penalty-based approach. The performances of the

proposed GGAs are then compared with a common heuristic for the clustering

problem.

172

6.2. Major Contributions

Chapter 5 studied the composite SaaS scalability problem in a Cloud.

Three main new challenges speci�c to the composite SaaS scalability problem

were addressed � the granularity of the scaling level, the selection of com-

ponent for replication/deletion, and the communication dependencies between

the replicas. Existing works in the area have not fully addressed these chal-

lenges simultaneously. The problem consists of two main tasks: the task to

replicate (scaling up) or to delete (scaling down) the component, and the task

of placing the component onto the Cloud infrastructure. A hybrid GA was

developed, which addressed the challenges by exploring the search space to

determine the suitable number of replicas for each component. The explora-

tion was done through the genetic operators, where it was guided by the �tness

function to �nd the scaling plan with the minimum cost possible whilst meeting

the constraints. The algorithm also utilised the problem domain knowledge

in determining the upper bound number of replicas and their placement. The

experiments presented in this chapter demonstrated the good performance of

the proposed algorithm when compared with a heuristic algorithm, especially

for the problems with a large number of tenants as well as the problems with

SaaS that have many components.

6.2 Major Contributions

The contributions are made in respect of the introduction of three new and

important problems of composite SaaS: the placement problem, the clustering

problem and the scalability problem. Contributions have also been made to the

evolutionary computation �eld, through development of various types of evo-

lutionary algorithm in addressing composite SaaS resource management pro-

blems. In addition, the algorithms developed provide e�cient ways to handle

composite SaaS in Cloud by optimising the resources used. This leads to cost

saving for running the SaaS for users as well as for SaaS and Cloud providers.

The major contributions of this research are discussed here in detail based on

the core chapters.

1. The composite SaaS placement problem (Chapter 3)

Placing a composite SaaS component onto a Cloud data centre has to be

done strategically as the placement will directly a�ect the performance

173


of the SaaS. Present algorithms for component or task placement algo-

rithms did not fully address either the criteria of composite SaaS or the

attributes of a Cloud data centre, thus making the composite SaaS place-

ment problem a brand new problem. A new formulation of the problem

and two types of evolutionary algorithms are presented to address this

gap. Speci�cally, the main �ndings of this problem are listed as follows:

• The identi�cation of a signi�cant problem for composite SaaS which

is the component placement problem, together with its formulation.

The formulation developed addresses heterogeneous types of com-

ponent as well as the attributes of large scale and modern data

centre. This chapter presents a precise understanding of the com-

posite SaaS placement process on a Cloud data centre.

• Two evolutionary algorithms are developed to solve the problem.

The �rst uses a classical GA approach (CGA), and the second uses

the cooperative co-evolutionary algorithm approach (CCEA). The

latter is developed in both iterative and parallel models. All pro-

posed algorithms have outperformed a typical heuristic algorithm

for the placement problem. Based on the experimental results, the

parallel CCEA shows a clear advantage for solving large-scale pro-

blems, in terms of quality of solution as well as the computation

time, compared to the iterative CCEA, the CGA and the heuris-

tic algorithm. The algorithms demonstrated good scalability, es-

pecially the parallel model of the CCEA. This can be attributed

to the parallel bu�er designed in the algorithm that connects the

subpopulations. The contributions from the proposed algorithms

are twofold: 1) the design and development of algorithms for large-

scale and complex problems with multiple design variables, and 2)

the design and development of two di�erent behaviours of CCEA,

resulting in di�erent performances.

2. The composite SaaS clustering problem (Chapter 4)

The problem's objective is to optimise the resources used by the SaaS

while maintaining its performance by complying with the constraints

outlined. The key �ndings of this problem are as follows:

174

6.2. Major Contributions

• This chapter identi�ed new challenges in the resource optimisation

problem of composite SaaS and provided a novel formulation for

the problem. The formulation consists of elements that address the

problem's important issues: 1) addressing the constraints on inter-

component dependence and the constraints that exist in a composite

SaaS, and 2) using a suitable level of service granularity to handle

the composite SaaS recon�guration placement, which existing re-

search does not address.

• Two grouping genetic algorithms (GGAs) are presented for the pro-

blem in which the encoding scheme and the genetic operations for

the GGAs are based on genes grouping. The contribution from the

design and implementation of the GGAs lies in the area of develo-

ping suitable constraint handling methods for a large scale optimi-

sation problem with complex constraints. Two constraint handling

methods were applied: 1) a repair-based genetic algorithm that used

random and knowledge-based repairing procedures to repair the in-

feasible individuals, and 2) a penalty-based genetic algorithm that

used a penalty function method to handle the constraints. The ex-

periments revealed the high cost savings achieved by the proposed

algorithms, compared with a common heuristic used for the cluste-

ring problem.

3. The composite SaaS scalability problem (Chapter 5)

This chapter presents a scalability problem tailored to the scaling of

composite SaaS in a Cloud data centre. The detailed �ndings of this

chapter are as follows:

• The �rst contribution of this chapter is the identi�cation of a compo-

site SaaS scalability problem that consist of both di�erent features

and new challenges that have not been addressed by the existing

research. A comprehensive formulation for the problem is provided

in which composite SaaS features, such as its dependencies between

components, its shared component with other tenants, and its ove-

rall evaluation performance, are included.

• The second contribution is through the design and development of

175


a hybrid genetic algorithm that manipulates the domain knowledge

when solving the problem. Based on that knowledge, the algorithm

through its genetic operators and guided by its �tness function ex-

hibits a strong exploration capability, in which the solution was

produced without having to determine the scalability trigger rules.

This is an important feature to any scalability problem as, based on

the existing literature, de�ning the trigger rules is the most complex

and di�cult task. No other known algorithms have demonstrated

this ability. Experimental results con�rmed the e�ectiveness of the

proposed algorithm, as compared with a greedy algorithm, espe-

cially in solving large-scale problems where there are large numbers

of SaaS components and tenants.

6.3 Future Work

Throughout this thesis, several ideas for future work have been identi�ed.

First, the composite SaaS placement problem is a large-scale complex com-

binatorial optimisation problem. Thus, how to further improve its computa-

tion time by increasing its parallelism is an issue that needs to be investigated

in the future. One possible way to improve the parallelism is to break the

composite SaaS placement problem down into more subcomponents using the

random grouping techniques proposed in [144]. In addition, the cooperative

co-evolutionary algorithm always selects the best individual from the other

population, which may not be appropriate in some cases. Thus, the selection

strategy is another potential direction that needs to be explored.

The composite SaaS clustering and composite SaaS scalability problems

have more than one objective, but both were transformed into a single objective

problem in this thesis, in which the weighted aggregation approach is used

to determine the rank of each objective. Therefore, a possible extension for

both problems is to implement a multi-objective evolutionary algorithm to

address all the objectives without having to determine their weightage. Multi-

objectives GA can be applied, including a non-Pareto based approach such

as VEGA, and a Pareto based approach such as Non-dominated Sorting GA

(NSGA)[30]. However, in the context of this research, further works need to

be carried out, as the involvement of human administrators is not available in

176

6.3. Future Work

an automated SaaS resource management.

Since the implementation of evolutionary algorithms has produced impres-

sive results for these problems, another possible research direction is to apply

other meta-heuristic approaches, such as particle swarm optimisation and si-

mulated annealing [41].

The research presented in this thesis focuses on solving SaaS resource mana-

gement problems in an o�ine maintenance phase, done in the medium times-

cale maintenance (minutes) and long timescale maintenance (hours to day).

Another possible extension of this research is to explore another maintenance

timescale, which is the short time scale (seconds) that is carried out as an

online maintenance task. This kind of maintenance focuses on how to provide

continuous optimisation of the resources in real-time resource management

especially under dynamic workload and some server breakdowns.

177

Appendix A

List of Publications

Some of the material from this thesis has appeared previously in the following

peer-reviewed publications:

• Z.I. Mohd Yusoh and M. Tang. A cooperative co-evolutionary algorithm

for the composite saas placement problem in the cloud. Neural Informa-

tion Processing: Theory and Algorithms, pages 618-625. Springer-Link,

2010. (Tier A conference)

• Z.I. Mohd Yusoh and M. Tang. A penalty-based genetic algorithm for the

composite saas placement problem in the cloud. In Proceeding of IEEE

Congress on Evolutionary Computation (CEC), pages 600-607. IEEE,

2010. (Tier A conference)

• Z.I Mohd Yusoh and M. Tang. Clustering composite saas components

in cloud computing using a grouping genetic algorithm. In Proceeding of

IEEE Congress on Evolutionary Computation (CEC), pages 1727-1734.

IEEE, 2012. (Tier A conference)

• Z.I. Mohd Yusoh and M. Tang. Composite saas placement and re-

source optimization in cloud computing using evolutionary algorithms.

In Proceeding of IEEE 5th International Conference on Cloud Computing

(CLOUD), pages 590-597. IEEE, 2012. (Tier A conference)

• Z.I. Mohd Yusoh and M. Tang. A penalty-based grouping genetic al-

gorithm for multiple composite saas components clustering in cloud. In

Proceeding of IEEE International Conference on Systems, Man, and Cy-

bernetics (SMC), IEEE, 2012. (Tier B conference)

179

APPENDIX A. LIST OF PUBLICATIONS

• M. Tang and Z.I. Mohd Yusoh. A parallel cooperative co-evolutionary

genetic algorithm for the composite saas placement problem in cloud

computing. Parallel Problem Solving from Nature PPSN XII, pages 225-

234, 2012.(Tier A conference)

180

Bibliography

[1] E. Abreu. Down on the server farm. The Industry Standard, 4(7):4, 2001.

[2] S. Adabala, V. Chadha, P. Chawla, R. Figueiredo, J. Fortes, I. Krsul,

A. Matsunaga, M. Tsugawa, J. Zhang, and M. Zhao. From virtualized

resources to virtual computing grids: the in-vigo system. Future Gener-

ation Computer Systems, 21(6):896�909, 2005.

[3] B. Addis, D. Ardagna, B. Panicucci, and L. Zhang. Autonomic manage-

ment of cloud service centers with availability guarantees. In Proceedings

of the IEEE 3rd International Conference on Cloud Computing, pages

220�227. IEEE, 2010.

[4] S. Alaoui, O. Frieder, and T. El-Ghazawi. A parallel genetic algorithm for

task mapping on parallel machines. Parallel and Distributed Processing,

pages 201�209, 1999.

[5] A. Alexandrescu, I. Agavriloaei, and M. Craus. A genetic algorithm

for mapping tasks in heterogeneous computing systems. In Proceedings

of the 15th International Conference on System Theory, Control, and

Computing, pages 1�6. IEEE, 2011.

[6] M. Andreolini, S. Casolari, M. Colajanni, and M. Messori. Dynamic load

management of virtual machines in cloud architectures. Cloud Comput-

ing, 34:201�214, 2010.

[7] D. Ashlock, E. Y. Kim, and N. Leahy. Understanding representational

sensitivity in the iterated prisoner's dilemma with �ngerprints. IEEE

Transactions on Systems, Man, and Cybernetics, Part C: Applications

and Reviews, 36(4):464�475, 2006.

181

BIBLIOGRAPHY

[8] F. M. Aymerich, G. Fenu, and S. Surcis. An approach to a cloud comput-

ing network. In Proceedings of IEEE Applications of Digital Information

and Web Technologies, pages 113�118. IEEE, 2008.

[9] V. Bachelet, P. Preux, and E.G. Talbi. Parallel hybrid meta-heuristics:

application to the quadratic assignment problem. In Proceedings of the

Parallel Optimization Colloquium, pages 233�242. Citeseer, 1996.

[10] P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neuge-

bauer, I. Pratt, and A. War�eld. Xen and the art of virtualization. 37

(5):164�177, 2003.

[11] J.E. Beck and D.P. Siewiorek. Simulated annealing applied to multi-

computer task allocation and processor speci�cation. In Proceedings of

the 8th IEEE Symposium on Parallel and Distributed Processing, pages

232�239. IEEE, 1996.

[12] W. Bedin and M. Moinuddin. An overview of software as a service in

retail, 2007.

[13] A. Ben Hadj-Alouane and J. C. Bean. A genetic algorithm for the

multiple-choice integer program. Operations Research, pages 92�101,

1997.

[14] N. Bobro�, A. Kochut, and K. Beaty. Dynamic placement of vir-

tual machines for managing sla violations. In Proceedings of the 10th

IFIP/IEEE International Symposium on Integrated Network Manage-

ment, pages 119�128. IEEE, 2007.

[15] A. B. Bondi. Characteristics of scalability and their impact on perfor-

mance. In Proceedings of the 2nd International Workshop on Software

and Performance, pages 195�203. ACM, 2000.

[16] N. Bonvin, T. G. Papaioannou, and K. Aberer. An economic approach

for scalable and highly-available distributed applications. In Proceedings

of the IEEE 3rd International Conference on Cloud Computing, pages

498�505. IEEE, 2010.

[17] Lucinda Borovick and Rohit Mehra. Architecting the network for the

cloud [white paper], 2011. URL www.idc.com.

182

BIBLIOGRAPHY

[18] T.D. Braun, H.J. Siegel, N. Beck, L.L. Bölöni, M. Maheswaran, A.I.

Reuther, J.P. Robertson, M.D. Theys, B. Yao, D. Hensgen, et al. A

comparison of eleven static heuristics for mapping a class of independent

tasks onto heterogeneous distributed computing systems. Journal of

Parallel and Distributed computing, 61(6):810�837, 2001.

[19] R. Buyya, Yeo Chee Shin, and S. Venugopal. Market-oriented cloud com-

puting: Vision, hype, and reality for delivering it services as computing

utilities. In Proceedings of the 10th IEEE International Conference on

High Performance Computing and Communications., pages 5�13. IEEE,

2008.

[20] R. Buyya, C. S. Yeo, S. Venugopal, J. Broberg, and I. Brandic. Cloud

computing and emerging it platforms: Vision, hype, and reality for deliv-

ering computing as the 5th utility. Future Generation Computer Systems,

25(6):599�616, 2009.

[21] J. Caceres, L. M. Vaquero, L. Rodero-Merino, A Polo, and J. J. Hierro.

Service scalability over the cloud. Handbook of Cloud Computing, pages

357�377, 2010.

[22] K. Sel Candan, Wen-Syan Li, Thomas Phan, and Minqi Zhou. Frontiers

in information and software as services. In Proceeding of the IEEE 25th

International Conference on Data Engineering, pages 1761�1768. IEEE,

2009.

[23] E. Cantu-Paz. E�cient and accurate parallel genetic algorithms.

Springer, 2000.

[24] J. Carolan, S. Gaede, J. Baty, G. Brunette, A. Licht, J. Remmell,

L. Tucker, and J. Weise. Introduction to cloud computing architecture.

2009.

[25] L. Cherkasova and J. Rolia. R-opus: A composite framework for appli-

cation performability and qos in shared resource pools. In Proceedings

of the International Conference on Dependable Systems and Networks,

pages 526�535. IEEE, 2006.

183

BIBLIOGRAPHY

[26] T. C. Chieu, A. Mohindra, A. A. Karve, and A. Segal. Dynamic scaling

of web applications in a virtualized cloud computing environment. In

Proceedings of the IEEE International Conference on e-Business Engi-

neering, pages 281�286. IEEE, 2009.

[27] Frederick Chong and Gianpaolo Carraro. Architecture strategies for

catching the long tail, 2006. URL http://msdn.microsoft.com/en-us/

library/aa479069.aspx.

[28] P. Chootinan and A. Chen. Constraint handling in genetic algorithms

using a gradient-based repair method. Computers & operations research,

33(8):2263�2281, 2006.

[29] C. Clark, K. Fraser, S. Hand, J. G. Hansen, E. Jul, C. Limpach, I. Pratt,

and A. War�eld. Live migration of virtual machines. In Proceedings

of the 2nd conference on Symposium on Networked Systems Design &

Implementation-Volume 2, pages 273�286. USENIX Association, 2005.

[30] C. A. Coello Coello. Theoretical and numerical constraint-handling tech-

niques used with evolutionary algorithms: a survey of the state of the

art. Computer methods in applied mechanics and engineering, 191(11):

1245�1287, 2002.

[31] Ron Condon. Forecast: Cloudy. 1(3):15�19, 2011.

[32] International Data Corporation. Saas revenue to grow �ve times faster

than traditional packaged software through 2014, 2010. URL http://

www.idc.com/about/viewpressrelease.jsp. [Online; accessed 2-June-

2010].

[33] T. Cucinotta, L. Palopoli, L. Abeni, D. Faggioli, and G. Lipari. On the

integration of application level and resource level qos control for real-

time applications. IEEE Transactions on Industrial Informatics, pages

479�491, 2010.

[34] Y. Davidor. Genetic Algorithms and Robotics: A heuristic strategy for

optimization. World Scienti�c Pub Co Inc, 1991.

[35] L. Davis and M. Mitchell. Handbook of genetic algorithms. Van Nostrand

Reinhold, 1991.

184

BIBLIOGRAPHY

[36] R. Drezewski and K. Obrocki. Co-operative co-evolutionary approach

to multi-objective optimization. Hybrid Arti�cial Intelligence Systems,

pages 277�284, 2009.

[37] A. Dubey and D. Wagle. Delivering software as a service. The McKinsey

Quarterly, pages 1�12, 2007.

[38] A. E. Eiben and J. E. Smith. Introduction to evolutionary computing,

volume 2. Springer Berlin, 2010.

[39] A. E. Eiben, J. K. van der Hauw, and J. I. van Hemert. Graph coloring

with adaptive evolutionary algorithms. Journal of heuristics, 4(1):25�

46�, 1998.

[40] T. A. El-Mihoub, A. A. Hopgood, L. Nolle, and A. Battersby. Hybrid

genetic algorithms: A review. Engineering Letters, 13(2):124�137, 2006.

[41] A. P. Engelbrecht. Computational intelligence: an introduction. Wiley,

2007.

[42] H. Erdogmus. Cloud computing: Does nirvana hide behind the nebula?

IEEE Software, 26(2):4�6, 2009.

[43] J. Espadas, D. Concha, and A. Molina. Application development over

software-as-a-service platforms. In Proceedings of the Third International

Conference on Software Engineering Advances, pages 97�104. IEEE,

2008.

[44] E. Falkenauer. A hybrid grouping genetic algorithm for bin packing.

Journal of heuristics, 2(1):5�30, 1996.

[45] P. Fan, J. Wang, Z. Zheng, and M.R. Lyu. Toward optimal deployment

of communication-intensive cloud applications. In Proceedings of the

IEEE International Conference on Cloud Computing (CLOUD), pages

460�467. IEEE, 2011.

[46] C.M. Fonseca and P.J. Fleming. An overview of evolutionary algorithms

in multiobjective optimization. Evolutionary computation, 3(1):1�16,

1995.

185

BIBLIOGRAPHY

[47] I. Foster, Zhao Yong, I. Raicu, and S. Lu. Cloud computing and grid

computing 360-degree compared. In Proceedings of the Grid Computing

Environments Workshop, pages 1�10. IEEE, 2008.

[48] Pezze M. Young M. Gambi, A. Sla protection models for virtualized

data centers. In Proceedings of the Workshop on Software Engineering

for Adaptive and Self-Managing Systems, pages 10�19. IEEE, 2009.

[49] Q. Gao, P. Tang, T. Deng, and T. Wo. Virtualrank: A prediction based

load balancing technique in virtual computing environment. In Pro-

ceedings of the IEEE World Congress on Services (SERVICES), pages

247�256. IEEE, 2011.

[50] D. Gmach, J. Rolia, and L. Cherkasova. Satisfying service level objectices

in a self-managing resource pool. In Proceedings of the Third IEEE

International Conference on Self-Adaptive and Self-Organizing Systems,

pages 243�253. IEEE, 2009.

[51] D. E. Goldberg. Genetic algorithms in search, optimization, and machine

learning. Addison-wesley, 1989.

[52] Changjie Guo. Study of web delivered services support platform. In

Proceedings of the IEEE 25th International Conference on Data Engi-

neering, pages 1757�1758, 2009.

[53] P. Hancock. An empirical comparison of selection methods in evolution-

ary algorithms. Evolutionary Computing, pages 80�94�, 1994.

[54] F. Hermenier, X. Lorca, J. M. Menaud, G. Muller, and J. Lawall. En-

tropy: a consolidation manager for clusters. In Proceedings of the ACM

SIGPLAN/SIGOPS International Conference on Virtual Execution En-

vironments, pages 41�50. ACM, 2009.

[55] Hewlett-Packard. Hp servers, 2009. URL http://h71028.www7.hp.

com/enterprise/cache/418226-0-0-14-121.html. [Online; accessed

9-November-2010].

[56] W. D. Hillis. Co-evolving parasites improve simulated evolution as an

optimization procedure. Physica D: Nonlinear Phenomena, 42(1-3):228�

234, 1990.

186

BIBLIOGRAPHY

[57] T. Hirofuchi, H. Nakada, H. Ogawa, S. Itoh, and S. Sekiguchi. Eliminat-

ing datacenter idle power with dynamic and intelligent vm relocation.

Distributed Computing and Arti�cial Intelligence, pages 645�648, 2010.

[58] J. H. Holland. Adaptation in natural and arti�cial systems. University

of Michigan press, 1975.

[59] A. Homaifar, C. X. Qi, and S. H. Lai. Constrained optimization via

genetic algorithms. Simulation, 62(4):242�253, 1994.

[60] Z. Hu, Y. Ding, and Q. Shao. Immune co-evolutionary algorithm based

partition balancing optimization for tobacco distribution system. Expert

Systems with Applications, 36(3):5248�5255, 2009.

[61] Anand V. Hudli, Balasubrahmanya Shivaradhya, and Raghu V. Hudli.

Level-4 saas applications for healthcare industry. In Proceedings of the

2nd Bangalore Annual Compute Conference, pages 1�8. ACM, 2009.

[62] P. Husbands and F. Mill. Simulated co-evolution as the mechanism

for emergent planning and scheduling. In Proceedings of the Fourth In-

ternational Conference on Genetic Algorithms, pages 264�271. Morgan

Kaufmann Publishers, 1991.

[63] IBM. System & servers, 2009. URL http://www-07.ibm.com/storage/

au/. [Online; accessed 9-November-2010].

[64] Amazon Inc. Amazon elastic compute cloud� 2011. URL http://aws.

amazon.com.ec2/.

[65] Cisco System Inc. Cisco service-oriented network architecture: Support

and optimize soa and web 2.0 applications, 2008. URL http://www.

cisco.com/. [Online; accessed 9-March-2010].

[66] Facebook Inc. Open compute project, 2011. URL http://opencompute.

org/.

[67] Gartner Inc. Introducing saas-enabled application platforms: Features,

roles and futures, 2007.

187

BIBLIOGRAPHY

[68] Gartner Inc. Gartner says worldwide software-as-a-service revenue to

reach $14.5 billion in 2012, 2012. URL http://www.gartner.com/it/

page.jsp?id=1963815.

[69] Google Inc. Google data centers, 2011. URL http://www.google.com/

about/datacenters/.

[70] Google Inc. Googleapps for business, 2012. URL http://www.google.

com/apps/intl/en/business/index.html.

[71] Sun Microsystem Inc. Open source & cloud computing: On-demand,

innovative it on a massive scale, 2009.

[72] Luit Infotech. Di�erence between the asp model and the

saas model, 2009. URL http://www.luitinfotech.com/kc/

saas-asp-difference.pdf.

[73] D. H. Janzen. When is it coevolution? Evolution, 34(3):611�612, 1980.

[74] D. Jayasinghe, C. Pu, T. Eilam, M. Steinder, I. Whally, and E. Snible.

Improving performance and availability of services hosted on iaas clouds

with structural constraint-aware virtual machine placement. In Proceed-

ings of the IEEE International Conference on Services Computing, pages

72�79. IEEE, 2011.

[75] E. Jendrock. The Java EE 5 Tutorial: For Sun Java System Application

Server Platform Edition 9. Addison-Wesley Professional, 2006.

[76] Steuard Jensen. An introduction to lagrange multipliers2012,

2004. URL http://www.slimy.com/~steuard/teaching/tutorials/

Lagrange.html.

[77] P. Jogalekar and M. Woodside. Evaluating the scalability of distributed

systems. IEEE Transactions on Parallel and Distributed Systems, 11(6):

589�603, 2000.

[78] H. JohnsonChristos and S. David. How easy is local search? Journal of

computer and system sciences, 37(1):79�100, 1988.

188

BIBLIOGRAPHY

[79] J. A. Joines and C. R. Houck. On the use of non-stationary penalty func-

tions to solve nonlinear constrained optimization problems with ga's. In

Proceedings of the First IEEE Conference on Evolutionary Computation,

pages 579�584. IEEE, 1994.

[80] Tim M Jones. Anatomy of a cloud storage infrastructure: models, fea-

tures, and internals, 2010. URL ibm.com/developerworks.

[81] M. Ka�l and I. Ahmad. Optimal task assignment in heterogeneous dis-

tributed computing systems. IEEE Concurrency, 6(3):42�50, 1998.

[82] Q. Kang and H. He. A novel discrete particle swarm optimization al-

gorithm for meta-task assignment in heterogeneous computing systems.

Microprocessors and Microsystems, 35(1):10�17, 2011.

[83] M. Karlsson and C. Karamanolis. Bounds on the replication cost for qos.

Technical report, Citeseer, 2003.

[84] A. Karve, T. Kimbrel, G. Paci�ci, M. Spreitzer, M. Steinder, M. Sviri-

denko, and A. Tantawi. Dynamic placement for clustered web appli-

cations. In Proceedings of the 15th International Conference on World

Wide Web, pages 595�604. ACM New York, 2006.

[85] B.S. Khosrowshahi and P. Graham. Component placement and location

for a dynamic software composition system. In Proceedings of the 2nd

Canadian Conference on Computer Science and Software Engineering,

pages 127�130. ACM, 2009.

[86] T. Kichkaylo. Timeless planning and the component placement prob-

lem. In Proceedings of the 14th International Conference on Automated

Planning and Scheduling. IEEE, 2004.

[87] T. Kichkaylo, A. Ivan, and V. Karamcheti. Constrained component de-

ployment in wide-area networks using ai planning techniques. In Proceed-

ings of the Int'l. Parallel and Distributed Processing Symposium, pages

10�19. ACM, 2003.

[88] Hiroyuki Kitagawa, Yoshiharu Ishikawa, Qing Li, Chiemi Watanabe, Se-

ungseok Kang, Jaeseok Myung, Jongheum Yeon, Seong-wook Ha, Tae-

hyung Cho, Ji-man Chung, and Sang-goo Lee. A general maturity model

189

BIBLIOGRAPHY

and reference architecture for saas service. In Lecture Notes in Computer

Science, pages 337�346. Springer Berlin / Heidelberg, 2010.

[89] T. Knauth and C. Fetzer. Scaling non-elastic applications using virtual

machines. In Proceedings of the IEEE International Conference on Cloud

Computing, pages 468�475. IEEE, 2011.

[90] V. Kumar, PC Saxena, and CP Katti. A clustering approach for task

assignment problem. International Journal of Computer Applications,

47(7):46�49, 2012.

[91] T. Kwok and A. Mohindra. Resource calculations with constraints, and

placement of tenants and instances for multi-tenant saas applications.

In Proceedings of the Sixth International Conference on Service-Oriented

Computing, pages 633�648. Springer, 2008.

[92] H.J. La, S.W. Choi, and S.D. Kim. Technical challenges and solution

space for developing saas and mash-up cloud services. In IEEE Inter-

national Conference on e-Business Engineering, pages 359�364. IEEE,

2009.

[93] P. A. Laplante, Zhang Jia, and J. Voas. What's in a name? distinguishing

between saas and soa. IT Professional, 10(3):46�50, 2008.

[94] J. Y. Lee and S. D. Kim. Software approaches to assuring high scala-

bility in cloud computing. In Proceedings of the IEEE 7th International

Conference on e-Business Engineering, pages 300�306. IEEE, 2010.

[95] K.S. Lee and Z.W. Geem. A new meta-heuristic algorithm for continu-

ous engineering optimization: harmony search theory and practice. Com-

puter methods in applied mechanics and engineering, 194(36):3902�3933,

2005.

[96] Renai Lemay. Westpac deploys vce private cloud,

2010. URL http://delimiter.com.au/2010/10/12/

westpac-deploys-vce-private-cloud/.

[97] W. Li. Qos assurance for dynamic recon�guration of component-based

software systems. IEEE Transactions on Software Engineering, 38(3):

658�676, 2012.

190

BIBLIOGRAPHY

[98] HanCheng Liao and ChangQi Tao. An anatomy to saas business mode

based on internet. In Proceedings of the International Conference on

Management of e-Commerce and e-Government, pages 215�220. IEEE,

2008.

[99] H.C. Lim, S. Babu, and J.S. Chase. Automated control for elastic stor-

age. In Proceeding of the 7th International Conference on Autonomic

computing, pages 1�10. ACM, 2010.

[100] A. Lodi, S. Martello, and D. Vigo. Heuristic algorithms for the three-

dimensional bin packing problem. European Journal of Operational Re-

search, 141(2):410�420, 2002.

[101] J.D. Lohn, W.F. Kraus, and G.L. Haith. Comparing a coevolutionary

genetic algorithm for multiobjective optimization. In Proceedings of the

2002 Congress on Evolutionary Computation, pages 1157�1162. IEEE,

2002.

[102] T. Loukopoulos and I. Ahmad. Static and adaptive distributed data

replication using genetic algorithms. Journal of Parallel and Distributed

Computing, 64(11):1270�1285, 2004.

[103] C. Low. Decentralised application placement. Future Generation Com-

puter Systems, 21(2):281�290, 2005.

[104] A. Mahmood. Replicating web contents using a hybrid particle swarm op-

timization. Information processing & management, 46(2):170�179, 2010.

[105] G. V. Mc Evoy and B. Schulze. Using clouds to address grid limitations.

In Proceedings of the 6th International Workshop on Middleware for Grid

Computing, pages 1�8. ACM, Leuven, Belgium, 2008.

[106] P. Mell and T. Grance. The nist de�nition of cloud computing:

Recommendations of the national institute of standards and technol-

ogy, 2011. URL http://csrc.nist.gov/publications/nistpubs/

800-145/SP800-145.pdf.

[107] Z. Michalewicz. Genetic algorithms + data structures. Springer, 1996.

191

BIBLIOGRAPHY

[108] R. Mietzner and F. Leymann. Towards provisioning the cloud: On the

usage of multi-granularity �ows and services to realize a uni�ed provi-

sioning infrastructure for saas applications. In Proceedings of the IEEE

Congress on Services - Part I, pages 3�10. IEEE, 2008.

[109] Rich Miller. Inside microsoft chicago data center,

2009. URL http://www.datacenterknowledge.com/

inside-microsofts-chicago-data-center/.

[110] M. Mitchell. An introduction to genetic algorithms. The MIT press,

1998.

[111] D. E. Moriarty and R. Mikkulainen. E�cient reinforcement learning

through symbiotic evolution. Machine learning, 22(1):11�32, 1996.

[112] H. R. Motahari-Nezhad, B. Stephenson, and S. Singhal. Outsourcing

business to cloud computing services: Opportunities and challenges.

IEEE Internet Computing, 10, 2009.

[113] A.B. Nassif and M.A.M. Capretz. Moving from saas applications to-

wards soa services. In Proceedings of the 6th World Congress on Services

(SERVICES-1), pages 187�188. IEEE, 2010.

[114] H. D. Nguyen, I. Yoshihara, K. Yamamori, and M. Yasunaga. Imple-

mentation of an e�ective hybrid ga for large-scale traveling salesman

problems. IEEE Transactions on Systems, Man, and Cybernetics, Part

B: Cybernetics,, 37(1):92�99, 2007.

[115] Nitu. Con�gurability in saas (software as a service) applications. In

Proceedings of the 2nd India Software Engineering Conference, pages

19�26. ACM, 2009.

[116] S.C.S. Porto and C.C. Ribeiro. A tabu search approach to task scheduling

on heterogeneous processors under precedence constraints. International

Journal of high speed computing, 7(1):45�72, 1995.

[117] M. Potter and K. De Jong. A cooperative coevolutionary approach to

function optimization. Parallel Problem Solving from Nature III, pages

249�257, 1994.

192

BIBLIOGRAPHY

[118] M.A. Potter. The Design and Analysis of a Computational Model of

Cooperative Coevolution. PhD thesis, George Mason University, 1997.

[119] M.A. Potter and K.A. De Jong. Evolving neural networks with collabo-

rative species. In Proceedings of the 1995 Summer Computer Simulation

Conference, pages 340�345. The Society for Computer Simulation, 1995.

[120] M.A. Potter and K.A.D. Jong. Cooperative coevolution: An architecture

for evolving coadapted subcomponents. Evolutionary computation, 8(1):

1�29, 2000.

[121] I. Pune and N. Issa. In Proceedings of the 2nd India Software Engineering

Conference, pages 19�26. ACM, 2009.

[122] B. Rochwerger, D. Breitgand, E. Levy, A. Galis, K. Nagin, I. Llorente,

R. Montero, Y. Wolfsthal, E. Elmroth, and J. Caceres. The reservoir

model and architecture for open federated cloud computing. IBM Sys-

tems Journal, 53(4), 2009.

[123] L. Rodero-Merino, L. M. Vaquero, V. Gil, F. Galan, J. Fontan, R. S.

Montero, and I. M. Llorente. From infrastructure delivery to service

management in clouds. Future Generation Computer Systems, 26(8):

1226�1240, 2010.

[124] S.J. Russell and P. Norvig. Arti�cial intelligence: a modern approach.

Prentice hall, 2010.

[125] S. Salcedo-Sanz and X. Yao. A hybrid hop�eld network-genetic algorithm

approach for the terminal assignment problem. IEEE Transactions on

Systems, Man, and Cybernetics, Part B: Cybernatics, 34(6):2343�2353,

2004.

[126] Salesforce.com. Salesforce, 2012. URL http://www.salesforce.com.

[127] K. Satake. Fujitsu's approach to saas in japan fujitsu saas platform.

Fujitsu Scienti�c and Technical Journal, 45(3):265�274, 2009.

[128] A. Silberschatz, P. B. Galvin, and G. Gagne. Operating system concepts.

Addison-Wesley, 1998.

193

BIBLIOGRAPHY

[129] W.M. Spears. Evolutionary Algorithms: the role of mutation and recom-

bination. Springer, 2000.

[130] H.S. Stone. Multiprocessor scheduling with the aid of network �ow al-

gorithms. IEEE Transactions on Software Engineering, (1):85�93, 1977.

[131] C. Tang, M. Steinder, M. Spreitzer, and G. Paci�ci. A scalable appli-

cation placement controller for enterprise data centers. In Proceedings

of the 16th International World Wide Web Conference, pages 331�340.

ACM, 2007.

[132] K. S. Tang, K. F. Man, S. Kwong, and Q. He. Genetic algorithms and

their applications. Signal Processing Magazine, IEEE, 13(6):22�37, 1996.

[133] F. Tenzakhti, K. Day, and M. Ould-Khaoua. Replication algorithms for

the world-wide web. Journal of Systems Architecture, 50(10):591�605,

2004.

[134] M. Turner, D. Budgen, and P. Brereton. Turning software into a service.

Computer, 36(10):38�44, 2003.

[135] B. Urgaonkar, A. L. Rosenberg, P. Shenoy, and A. Zomaya. Application

placement on a cluster of servers. International Journal of Foundations

of Computer Science, 18(5):1023�1041, 2007.

[136] L. M. Vaquero, L. Rodero-Merino, and R. Buyya. Dynamically scaling

applications in the cloud. ACM SIGCOMM Computer Communication

Review, 41(1):45�52, 2011.

[137] Luis M. Vaquero, Luis Rodero-Merino, Juan Caceres, and Maik Lindner.

A break in the clouds: Towards a cloud de�nition. SIGCOMM Computer

Communication Review, 39(1):50�55, 2009.

[138] Anil Vasudeva. Sas, nas, san: Past, present and future., 2000. URL

http://www.imexresearch.com/pdfs/sasnassan.pdf.

[139] A. Verma, P. Ahuja, and A. Neogi. pmapper: power and migration cost

aware application placement in virtualized systems. In Proceedings of

the 9th ACM/IFIP/USENIX International Conference on Middleware,

pages 243�264. Springer-Verlag, 2008.

194

BIBLIOGRAPHY

[140] Y. Wang and X. Wang. Power optimization with performance assurance

for multi-tier applications in virtualized data centers. In 39th Inter-

national Conference on Parallel Processing Workshops, pages 512�519.

IEEE, San Diego, CA.

[141] C. D. Weissman and S. Bobrowski. The design of the force. com multi-

tenant internet application development platform. In Proceedings of the

35th SIGMOD International Conference on Management of Data, pages

889�896. ACM, 2009.

[142] J. Wu, Q. Liang, and E. Bertino. Improving scalability of software cloud

for composite web services. In Proceedings of the IEEE International

Conference on Cloud Computing, pages 143�146. IEEE, 2009.

[143] J. Xiao, Z. Michalewicz, L. Zhang, and K. Trojanowski. Adaptive evo-

lutionary planner/navigator for mobile robots. IEEE Transactions on

Evolutionary Computation,, 1(1):18�28, 1997.

[144] Z. Yang, K. Tang, and X. Yao. Large scale evolutionary optimization

using cooperative coevolution. Information Sciences, 178(15):2985�2999,

2008.

[145] W. Zhu, T.Y. Liang, and C.K. Shieh. A hop�eld neural network based

task mapping method. Computer Communications, 22(11):1068�1079,

1999.

[146] X. Zhu, C. Santos, D. Beyer, J. Ward, and S. Singhal. Automated

application component placement in data centers using mathematical

programming. International Journal of Network Management, 18(6):

467�483, 2008.

[147] B. Zimmerova. Component placement in distributed environment wrt

component interaction. In Proceedings of the Doctoral Workshop on

Mathematical and Engineering Methods in Computer Science, pages 260�

267. FIT VUT Brno, 2006.

[148] D. Zou, L. Gao, S. Li, J. Wu, and X. Wang. A novel global harmony

search algorithm for task assignment problem. Journal of Systems and

Software, 83(10):1678�1688, 2010.

195

Documents

Composite SaaS Resource Management in Cloud Computing ... · Cloud computing is an emerging computing paradigm in which IT resources are provided over the Internet as a service to