Advertisement

Soft Computing

, Volume 22, Issue 12, pp 4025–4045 | Cite as

A composite particle swarm optimization approach for the composite SaaS placement in cloud environment

  • Mohamed Amin Hajji
  • Haithem Mezni
Methodologies and Application

Abstract

Cloud computing has emerged as a new powerful service delivery model to cope with resource challenges and to offer on-demand various types of services (e.g., software, storage, network). One of the most popular service models is Software as a Service (SaaS). To allow flexibility and reusability, SaaS can be offered in a composite form, where a set of interacting application and data components cooperate to form a higher-level functional SaaS. However, this approach introduces new challenges to resource management in the cloud, especially finding the optimal placement for SaaS components to have the best possible SaaS performance. SaaS Placement Problem (SPP) refers to this challenge of determining which servers in the cloud’s data center can host which components without violating SaaS constraints. Most existing SPP approaches only addressed homogenous SaaS components placement and only considered one type of constraints (i.e., resource constraint). In addition, none of them has considered the objective of maintaining a good machine performance by minimizing the resource usage for the hosting machines. To allow finding the optimal placement of a composite SaaS, we adopt a new variation of PSO called ’Particle Swarm Optimization with Composite Particle (PSO-CP).’ In the proposed PSO-CP-based approach, each composite particle in the swarm represents a candidate SaaS placement scheme. Composite particles adopt a collective behavior to explore and evaluate the search space (i.e., data center) and adjust their structures by collaborating with other composite or independent particles (i.e., servers). The implementation and experimental results show the feasibility and efficiency of the proposed approach.

Keywords

Cloud computing Software as a service Composite SaaS Resource management SaaS placement Particle swarm optimization Composite particles 

1 Introduction

Cloud computing has risen in the last decade as novel, revolutionary computing paradigm in which computational resources and various types of services are available for on-demand, ubiquitous network access for its users (Mell and Timothy 2011). Other characteristics of the cloud include the elasticity of offered services so that they can be proportionate with the demand of users (Mell and Timothy 2011), and the pay-per-use model where users are only charged for what they have used from the cloud offering instead of a single unified subscription cost.

One type of the services that can be offered by cloud computing is Software as a Service (SaaS). The National Institute of Standards and Technology (NIST) defines it as the capability to use a (customized) software hosted on the cloud’s provider infrastructure (Mell and Timothy 2011). This SaaS is accessible via internet by various client devices (mobile phones, laptops...) using Web browsers or programs interfaces on either a pay-per-use model or free of charge, depending from the provider’s policy.

Many researchers claim that SaaS existed before cloud computing (Bhardwaj 2015; Kumar 2014; Yusoh 2013), and the increasing demand for it has led SaaS vendors to deploy it on cloud environments because the latters offer the scalability needed by SaaS (Candan et al. 2011). Despite this possibility of making a SaaS available without using cloud computing, this type of cloud service has gained a wide popularity in the last few years while compared to other cloud services like PaaS and IaaS according to many analysts firms studies (RightScale 2016; Statista 2016). The study from Statista1 confirms that SaaS subscription revenues went from approximately 42 billion US dollars in 2012 to 107 billion US dollars in 2016 (Statista 2016).

To further improve the SaaS flexibility and elasticity, this type of service can be offered in a composite form. A composite SaaS is composed of loosely coupled communicating subsystems each with specific business function to form a higher-level functional system (Cisco 2008). Those components are generally Application Components (AC) that may need access to one or many data chunks, or Data Components (DC) that are also considered as part of the composite SaaS. This form of offering SaaS in a composite model allows more flexibility of the SaaS to be proportionate for user demands by combining, isolating, and recombining the components when needed. It also allows reusability by the ability of using a SaaS component in multiple other SaaS when its specific business functionality is needed and can be “assembled” with another set of components. Both of these two advantages can lead to important cost and time savings for the cloud provider (Cisco 2008; Yusoh 2013).

However, adopting the composite model to offer SaaS may introduce several challenges to the cloud provider in terms of resource management. For instance, finding a placement (deployment) strategy for the composite SaaS that can optimize its performance by minimizing its execution time. The performance of the machines in the cloud’s data center should also be maintained to offer optimal processing. Data components also must be placed strategically in a way that they can be accessed by the application components in a minimal data transfer time.

This aforementioned problem is known as SaaS placement problem (SPP) and it is considered as cloud computing’s resource management problem. Resource management was always a challenge for cloud computing especially in 2016 when the lack of resources and expertise has supplanted security as the top concern for cloud providers (RightScale 2016) as more and more workload is being transferred to cloud computing. Many research works addressed the different challenges of resource management in cloud computing with Computational Intelligence (CI) and different optimization techniques (Talbi et al. 2015).

However, only a few research works have addressed the SPP despite its importance especially after observing that the demand of SaaS is highly increasing each year. Even among these works that have addressed the SPP, there exist some that did not consider optimizing data components’ placement which is important, especially in case of data intensive services where the amount of data produced or consumed by SaaS components is very high. In addition, none of these works have considered maintaining the performance of servers hosting the composite SaaS. It is expected that maintaining a moderate usage of the hosting servers (its RAM and CPU) will not degrade their performance and can even host additional data or applications needed for other services (PaaS, IaaS...). Power consumption costs can be also reduced by maintaining a moderate machine usage (Minas and Ellison 2015).

This research acknowledges the importance of resource management as a major concern to cloud providers and the increasing popularity and interest of SaaS by users. Therefore, SPP is considered as an important new problem that PSO seems very suitable to solve it to finally obtain a performing SaaS that can satisfy the users demands and optimize the cloud’s resource utilization.

The motivation behind adopting a PSO variant to solve the SPP is its successful application to several optimization problems such as image processing, artificial neural network training, vehicle routing problem, power allocation (Rosendo and Pozo 2010). Moreover, compared to other population-based methods such as Genetic Algorithm (GA) and Ant Colony Optimization (ACO), PSO has several notable advantages (Tang et al. 2011; Yang et al. 2007), which makes it a good candidate to solve the SPP. PSO has a simple search mechanism allowing it to be implemented easily, without being expensive in terms of running speed and memory capacity. PSO also does not require advanced functions to continue the search process, which makes it less sensitive to the optimization problems characteristics, unlike other population-based methods. Another advantage offered by PSO is the collective behavior of particles and the individual memory of each of them, which allows particles to exchange and retain the knowledge of good solutions during the optimization process, while jumping out of the local optima.

Based on the above motivations, this paper will address the SPP by proposing a Composite Particle Swarm Optimization (CPSO or PSO-CP)-based approach. The objective that we aim by our approach is not only finding a placement of application and data components of the composite SaaS such that the total execution time is minimal but, as a second objective, maintaining a good performance within the hosting machines . To the best of our knowledge, this is the first work related to SPP that has considered the latter optimization objective. PSO-CP is also known by well performing in Dynamic Optimization Problems (DOPs) thanks to its composite form of particles and their Velocity-Anisotropic Reflection (VAR) that have replaced the classical particles and velocities of the original PSO  (which is not known to be well performing in DOPs) (Liu et al. 2010).

The remainder of this paper is organized as follows:

Section 2 discusses the related work and the existing techniques for composite SaaS placement. Section 3 further explains the SPP in more details alongside with its mathematical formulation. Section 4 discusses the adopted PSO variant. Section 5 will present the proposed PSO-CP-based approach to solve the SPP. An experimental study of the approach is presented in Sect. 6. This paper ends with concluding remarks and perspectives in Sect. 7.

2 Related works

SPP was addressed by several research works in last six years where several researchers proposed different computational intelligence approaches to optimize the SaaS performance and minimize SaaS execution time. Some others Bhardwaj (2015), Kumar (2014) treat the SPP with the optimization objective of reducing deployment costs of the SaaS in servers and increasing the profit for cloud provider.

2.1 Searching for SaaS placement while minimizing execution time

Yusoh and Tang elaborated series of works for SPP using evolutionary computation (Tang and Yusoh 2012; Yusoh and Tang 2010a, b), and they were the first to formulate the SPP with heterogenous components (Application and Data components).

Their first work in Yusoh and Tang (2010a) solved the SPP by implementing a penalty-based genetic algorithm (GA) approach where it starts with a randomly generated population that represents different placement candidates for AC and DC in Computation Servers (CS) and Storage Servers (SS), respectively. Applying genetic operators like crossover and mutation on the current population of placements (chromosomes) will serve to obtain a newer, better population of candidate placements that are then evaluated based on the Estimated Total Execution Time (ETET) of the SaaS. If a generated solution is non-feasible and violates resource constraints, their algorithm “penalizes” it instead of fully discarding it.

The proposed algorithm generated acceptable solutions, but its computation time to find the optimal solutions was unacceptably long.

Yusoh and Tang (2010b) further improved their first work by using a new approach based on Cooperative Co-Evolutionary Algorithm (CCEA) to find the optimal placement for SaaS application and data components. The main difference with their previous work (Yusoh and Tang 2010a) is that this CCEA approach divides the SPP into two collaborating inter-dependent subproblems, namely, application component placement (1) and data component placement (2). Those two subpopulations of candidate solutions evolve using the classical GA with its genetic operators. The collaboration method and the fitness cost calculation occur when evaluating fitness of both individuals from the two different evolving subpopulations. A solution is evaluated on how well it “cooperates” with members in other subpopulation in solving the problem.

A parallel model of the previous CCEA work (Yusoh and Tang 2010b) was presented in Tang and Yusoh (2012) by the same authors to improve the quality of solutions and computation time. In this parallel model, they decomposed the computation into two unsynchronized and parallel subcomputations. The communication between the evolving subpopulations (evolved by GA) is asynchronous through a buffer. A buffer is a memory that holds the best two solutions found in the two subproblems. The two solutions are updated after each generation and will be used as a ’representative’ for its original subpopulation. Both of them will be used for the cooperative evaluation later by the solution from the other subpopulation. Experimental studies have shown that parallel CCEA has outperformed GA and iterative CCEA in terms of produced solutions’ qualities and computation time. But just like the two previous works, the parallel CCEA only considered resource constraints.

Ni et al. (2012) proposed an ant colony optimization (ACO) based algorithm for SPP. Their approach uses artificial ants to construct possible placement solutions by moving between nodes which is the equivalent of placing a single component in a server. Then, the ant chooses the next placement of the next component with a certain probability depending from the deposited pheromone in the environment and the desirability. Those two parameters are used typically in ACO algorithms. Their ACO-based approach has outperformed GA, but it did not perform very well while increasing the number of SaaS components. Also, they did not consider any difference between placing ACs or DCs in their paper.

Bowen and Shaochun (2012) used an adaptive hybrid algorithm which combines GA with Simulated Annealing (SA). Crossover and mutation rate are set to adaptively change depending on the convergence of proposed solutions’ fitness values. The simulated annealing part in this algorithm is used to accept generated solutions with a certain probability depending from a varying temperature, just like the original SA algorithm. It was claimed that the introduction of the latter algorithm accelerated the optimization.

The objective for them was to minimize the total execution time of the SaaS and to guarantee the load balancing of the data center. Their algorithm treated both AC and DC placement and has produced good-quality placements. However, the solution’s encoding scheme they used only permits one AC to have access to a single DC which is not the case in most composite SaaS.

Liu et al. (2014) were the second to use an ACO approach which tries finding a placement solution for components of the SaaS while minimizing their ETET. It was assumed that the number of artificial ants is equal to the number of components in the SaaS. Those ants construct candidate solutions one by one by moving in a directed graph that symbolizes both components and their hosting machines to be placed into. The construction process is of course guided by desirability and pheromone depositing. The desirability of placing a SaaS component in a certain machine is affected by a Performance Matching Degree (PMD) equation that stands for proximity degree between the component resource requirement and virtual machine performance. This PMD equation will help for the deployment of the current component in the machine with the strongest performance. Although ACO outperformed the classical GA, the researchers only considered resource requirements and treated homogenous SaaS components.

Recently in 2015, Huang and Shen (2015) considered the SaaS deployment problem as a dual-objective optimization problem for (1) reducing inter-task communication costs and (2) increasing parallelism. The authors identified those two as important factors that affect the SaaS execution performance. To address this problem, they presented a strategy based on designing two types of undirected graphs: Service Dependencies Graph (SDG) that illustrates dependencies between different components and Service Concurrence Graph (SCG) where an edge between two nodes (services) means that they have no direct or indirect interdependencies between them, and thus, they can run concurrently and benefit from parallelism of execution. The two graphs are then combined in one graph that shows both dependency and parallelism. Hence, the SPP can transform into minimum k-cut problem that is later solved with greedy algorithm. Finding the minimum k-cuts means finding the minimum k number of virtual machines that can deploy those components especially after observing from the obtained graphs which components are highly inter-dependent to be put in close (same) virtual machines and which components can run concurrently in different machines. Experimental results showed that their dual-objective approach is efficient but they should have considered the difference between AC and DC placement as they only treated homogenous SaaS components.

Perhaps, the most common limit of research works classified in this category is that aiming for a minimal execution time needs powerful and robust servers to execute the composite SaaS. High costs may be incurred while operating those machines or deploying in them as mentioned in Bhardwaj (2015). Considering only resource requirements is also a common disadvantage of this category.

2.2 Searching for SaaS placement while minimizing costs and increasing profits

This category considers costs saving and profit increasing for the SaaS provider as optimization objectives. It is assumed in those research works that for each component placed in a particular VM there is a cost of deployment that the SaaS provider must cover  (Bhardwaj 2015). This cost is a combination of processing cost, memory cost, storage cost, bandwidth cost...  Only two works have modified SPP to serve these objectives.

Kumar (2014) used a repair-based GA to find candidate placements for SaaS in the cloud’s data center. The population for this GA is initialized by randomly generated solutions that are encoded as chromosomes. Genetic operators (crossover and mutation) are applied to modify these solutions and obtain another, more fitted population. Any generated solution that violates resource constraints is ’repaired’ by randomly regenerating a part (gene) of the solution in the correct search space. The research objective was maximizing the profit for the SaaS provider by finding an optimal solution that will not violate resource and SaaS execution time established in Service-Level Agreement (SLA) contract. In this contract, SaaS users can provide the maximum response time of the SaaS as an input for its provider.

The author compared his approach with a First-Fit Decreasing (FFD) heuristic and obtained better results (more profit for the SaaS provider) but in a longer computation time. However, he did not also consider the difference between AC and DC placement and only treated homogenous components that he called “SaaS components.”

Bhardwaj (2015) presented a Particle Swarm Optimization (PSO)-based approach for the SPP and considered resource constraints and SLA constraints. Their objective was to minimize the total cost incurred to the SaaS provider while deploying the SaaS. The PSO algorithm is somewhat similar to GA as it begins with a random population that will evolve to produce a better population. But no genetic operators is applied in PSO as the “particles” are the ones scattered in the search space to search the optimal solutions by moving with certain velocities.

In this particular SPP, each particle represents a placement solution for all the SaaS components. After updating their velocities and positions, the newly positioned particles present another new population of placement solutions. Based on their new fitness values, the local and global best solutions are also updated if changed. Finally, the algorithm produces the global best solution in the population which represents the least expensive placement scheme of the SaaS. This PSO approach produced lower-cost results and showed better scalability than a GA developed also by Bhardwaj for comparison. But there were no experimental studies on the algorithm’s processing time, and just like the previous work of Kumar (2014), the author only used homogenous components and servers.

The idea proposed by Bhardwaj (2015) and the one proposed here may seem somewhat similar because of the common use of swarm intelligence techniques. Yet the differences between our approaches is that he considers reducing placement costs in servers as an optimization objective. While in this research, the goal is minimizing SaaS execution time and preserving machine performance. Bhardwaj used PSO that is not suitable for DOPs, but in this work we use PSO-CP that was designed by Liu et al. (2010) to deal with such type of problems. A particle, as used in his approach, represents a complete solution, while in this research, a particle is considered as a partial solution from the complete solution presented by composite particles.

The works in this category are cost-aware and their optimization objectives need to be more user-oriented, because reducing costs and maximizing profits for the SaaS provider may cause service-level degradation for the users. An SLA constraint, where the maximum total execution time is given as an input by the user, is indeed considered by those works, but that does not guarantee the availability and the quality of service offering while hosting a SaaS on a set of low-cost servers.

2.3 Discussion

It should be noted that the existing literature for SPP is not that rich, and only nine works have treated this problem as it is. Several other research works (generally before 2010) have treated similar problems to SPP like Component Placement Problem (CPP). CPP consists of choosing for each application component a hosting physical (virtual) machine such that the users’ requirements are satisfied and the usage of resources is minimized (Kichkaylo et al. 2003; Urgaonkar 2004). Task-Assignment Problem (TAP) is also somewhat similar to SPP as it consists of having a number of tasks that needs to be assigned to a number of machines such that the total execution time and communication costs between differently located tasks is minimized.

However, the main differences between CPP and TAP with SPP is that the latter is only concerned with SaaS components placements in cloud’s data center environment. SPP is also classified under the cloud’s resource management optimization problems unlike TAP and CPP.

Moreover, two types of components (application and data, generally) are considered and their placement should be optimized in SPP, while TAP and CPP only deal with homogenous components that are not even related to a SaaS.

Based on our study, we have observed that we can classify each of SPP solving approaches depending from:
  • Optimization objective: Either the approach aims to optimize SaaS performance (see Sect. 2.1) or to reduce costs for the SaaS provider and increase his profits (see Sect. 2.2). Other works treated the SPP as a dual-objective optimization: in order to finally obtain a performing SaaS by increasing parallelism and reducing communication time (Huang and Shen 2015), or in order to guarantee load balancing and obtain a performing SaaS at the same time (Bowen and Shaochun 2012).

  • Considered constraints: Most of the existing approaches consider resource constraints where a component cannot be deployed in a machine only if the machine can have enough storage space and can satisfy the component’s requirements (CPU and RAM) if there is any. Some others added SLA constraints (Bhardwaj 2015; Kumar 2014).

  • Type of SaaS components: It is very common that in a composite SaaS there exist two types of components, (1) application components (AC) and (2) data components (DC). There is a difference between the deployment strategies of the two types of components: ACs should be placed in available computation servers (CS) that have powerful CPU devices and RAM memories in order to execute in minimal time. While DCs should be stocked in available storage servers (SS) while only utilizing their storage spaces. Those DCs must be placed such that the Data Transfer Time (DTT) between them and ACs is minimal, and thus, total execution time is minimal.

    Despite this importance of both types of components, 5 out of the 9 existing techniques consider SaaS components as homogenous components and did not explain how their approaches handle the placement of DC (the placement could be given as input or not even considered...).

2.4 Requirements for an efficient SaaS placement

Based on the study of the previous works characteristics and considerations, and based on the disadvantages and advantages of each one, an efficient SaaS placement approach needs to consider the following:
  1. 1.

    The optimization objective is mainly minimizing the SaaS total execution time. However, if a solution is once found, it needs to be cost-effective where the SaaS provider can minimize deployment costs in the hosting machines. Therefore, in this research, a second optimization objective aside with minimizing execution time is added: Maintaining a good machine performance. It is expected that maintaining a moderate usage of the hosting servers will not degrade their performance and can even become candidates for the placement of other data or applications needed for other services (PaaS, IaaS...).

    This idea can save costs of deployment in servers by maximizing the residual capacity after deploying the composite SaaS and make it available for other needs of the cloud provider. Power consumption costs can be also reduced by applying this moderate machine usage as stated in Minas and Ellison (2015).

     
  2. 2.

    The placement scheme of data components (DC) is essential for having a well-performing SaaS. The interdependencies and data exchange between AC and DC is important especially in case of data intensive services where the amount of data produced or consumed by SaaS components is very high.

    Both of these types of components in a SaaS must be placed strategically such that the reading/writing of data is not only possible but needs to be done as fast as possible. Having components collaborate in a minimal period of time will also lead to minimizing the ETET.

     
  3. 3.

    Resource constraints must be respected, they consist of the necessity to only deploy a component in a server (VM) if the former’s requirements (CPU, RAM, storage...) can be satisfied by the latter’s available capacity. Also, the SLA constraint where the maximum execution time is given as an input by the user in the SLA contract is important to consider also.

     

3 The SaaS placement problem

An abstracted example of multiple-composite SaaS deployed and executed on a set of computation and storage servers is illustrated in Fig. 1. Different data and application components are distributed on different servers. Those ACs and DCs may cooperate in order to form a higher-level functional composite SaaS. The latter can be composed of only application components like composite SaaS 3.
Fig. 1

An example of three composite SaaS deployed in different computation and storage servers (Yusoh 2013)

A formal definition of SPP was presented in Yusoh (2013). But in this present work, some simple alterations will be integrated to the original SPP definition based on how the problem will be treated here:
  1. 1.

    For simplicity, a SaaS is considered to have only one workflow in this research instead of many workflows.

     
  2. 2.

    One more optimization objective is added in this research, which is maintaining an acceptable performance of the server (VM) that will contain the SaaS component(s). This is reached by maintaining a moderate resource usage by the SaaS components.

     
So the statement of the problem that will be treated here is below:

Given a set of computing and storage servers with their resource capacities, a cloud communication network, and a composite SaaS with its resource requirements, the goal is to determine which SaaS application component (respectively data component) should be placed on which computing server (respectively storage server), such that the performance of the SaaS is optimal based on its total execution time and the performance of hosting machines is maintained while satisfying the resource requirements and SLA constraints.

SPP can be formulated as follows (Yusoh 2013):
Input
  1. 1.
    A cloud data center, \(\hbox {DC} = \langle \hbox {CS} \cup \hbox {SS}, E \rangle \) with n computing servers \(\hbox {CS} = \{\hbox {cs}_{1}, \hbox {cs}_{2},\ldots , \hbox {cs}_{n} \}\), m storage servers \(\hbox {SS} = \{ \hbox {ss}_{1}, \hbox {ss}_{2},\ldots , \hbox {ss}_{m}\}\) and a set E of undirected edges denoting the coud communication network:
    • Resource capacities and Virtual Machines (VMs) for each computation server \(\hbox {cs}_i\), \( 1 \le i \le n \), are represented by \(\langle \hbox {pc}_{i}, \hbox {RAM}_{i}, \hbox {disk}_{i}, \hbox {VMC}_{i} \rangle \) denoting the processing, RAM, storage capacities and the set of VMs inside \(\hbox {cs}_i\), respectively.

    • Resource capacities of each storage server \(\hbox {ss}_i\), \( 1 \le i \le m \), are represented by only \( \langle \hbox {diskSS}_{i} \rangle \) denoting the disk storage capacity.

    • Communication links transmitting information between two servers \(v_{i}\) to \(v_{j}\) , where \(v_{i}, v_{j} \in \hbox {CS} \cup \hbox {SS}\), are modeled as a set of undirected edges connecting vertices \(v_{i}\) and \(v_{j}\). \(B_{v_{i},v_{j}}\) is the bandwidth of the link between the two servers \(v_{i}, v_{j}\).

     
  2. 2.
    A set of composite SaaS, \(S = \langle \hbox {AC} \cup \hbox {DC}, \hbox {DAG} \rangle \), with x application components \(AC = \{ \hbox {ac}_{1}, \hbox {ac}_{2},\ldots ,\hbox {ac}_{x} \}\) and y data components \(\hbox {DC} = \{ \hbox {dc}_1, \hbox {dc}_2,\ldots , \hbox {dc}_y \}\).
    • Resource requirements for each application component \(\hbox {ac}_i\), \( 1 \le i \le x \), are represented by \(\langle \hbox {pcReq}_i, \hbox {mReq}_i, \hbox {size}_i, \hbox {amountRW}_i \rangle \), denoting the required processing, RAM and storage capacities of the component \(\hbox {ac}_i\), respectively. The last value of \(\hbox {amountRW}_i\) is the amount of read/write to other connected application/data components.

    • Resource requirements of each data component \(\hbox {dc}_j\), \(1 \le j \le y\), are represented by \( \langle \hbox {sizeDC}_j \rangle \), denoting the required storage space for component \(\hbox {dc}_j\).

    • SaaS workflow is modeled as a directed acyclic graph \(\hbox {DAG} = \hbox {DAC} \cup \hbox {DDC}\) representing the dependencies between ACs \((\hbox {DAC} = \hbox {AC} * \hbox {AC})\) and the dependencies between ACs and DCs \((\hbox {DDC} = \hbox {AC} * \hbox {DC})\).

     
Objective
The objective is finding a placement for all application components in virtual machines:
$$\begin{aligned} P: \hbox {AC} \rightarrow \hbox {VM} \end{aligned}$$
(1)
And \(P(\hbox {ac}_i)=\hbox {vm}_j\) means that component \(\hbox {ac}_i\) is placed in the virtual machine \(\hbox {vm}_j\), \( 1 \le i \le x \) and \( 1 \le j \le w\). The number of all virtual machines inside all physical machines in the data center is represented by w.
Also, finding a placement for all data components in storage servers:
$$\begin{aligned} D: \hbox {DC} \rightarrow \hbox {SS} \end{aligned}$$
(2)
And \(D(\hbox {dc}_i)=\hbox {ss}_j\) means that component \(\hbox {dc}_i\) is placed in storage server \(\hbox {ss}_j\), \( 1 \le i \le y \) and \( 1 \le j \le m\).
Those two previous placement schemes are constructed such that the estimated total execution time (ETET) is minimal and the performances of the hosting machines are maintained by using the RAM and CPU resources at a moderate level:
$$\begin{aligned} \hbox {min}(I_T\cdot \hbox {ETET(SaaS)}*I_U\cdot \hbox {ResUsage(SaaS)}) \end{aligned}$$
(3)
where ResUsage(SaaS) is the percentage of usage of all the involved virtual machines’ computation and RAM capacities. A VM is involved if it contains one or more AC from the deployed SaaS.
Calculations of ResUsage(SaaS) and ETET(SaaS) will be presented in Sect. 5.2. \({I_T}\) and \({I_U}\) are the importance factors of the execution time of the SaaS and the resource usage from machines, respectively, such that \( 0 \le {I_T} \le 1\) and \(0 \le {I_U} \le 1\) and \({I_T}+{I_U}=1\). We tend to have a small importance factor \({I_U}\) for machine usage to avoid promoting underusage of the machine and achieve the fastest execution time of the SaaS as we can, because the latter objective is the most important objective aimed for in the previous works, as mentioned in Sect. 2.3.
Fig. 2

Composite PSO steps: a construction, b self-adjustment, c pioneer particle selection, d swarm updating, e integral movement (Liu et al. 2010)

Constraints

It should be noted that many types of constraints may occur while finding a placement for a composite SaaS. However, in this present work, only two types of constraints are considered, namely resource constraints and SLA constraints.
  1. 1.
    Resource constraints:
    • The deployment of ACs in the VM depends on available capacities of the VM. Equations (4)–(6) depict those constraints for processing, RAM, and disk capacities, respectively.
      $$\begin{aligned}&\displaystyle \sum _{\mathrm{ac}_j \in AC} \hbox {pcReq}_{\mathrm{ac}_j} \le \hbox {pc}_{\mathrm{vm}_i} | P(\hbox {ac}_j)=\hbox {vm}_i ,\quad \forall \,\hbox {vm}_i \in \hbox {VM}\nonumber \\ \end{aligned}$$
      (4)
      $$\begin{aligned}&\displaystyle \sum _{\mathrm{ac}_j \in \mathrm{AC}} \hbox {mReq}_{\mathrm{ac}_j} \le \hbox {RAM}_{\mathrm{vm}_i} | P(\hbox {ac}_j)=\hbox {vm}_i,\quad \forall \,\hbox {vm}_i \in \hbox {VM} \nonumber \\\end{aligned}$$
      (5)
      $$\begin{aligned}&\displaystyle \sum _{\mathrm{ac}_j \in \mathrm{AC}} \hbox {size}_{\mathrm{ac}_j} \le \hbox {disk}_{\mathrm{vm}_i} | P(\hbox {ac}_j)=\hbox {vm}_i,\quad \forall \,\hbox {vm}_i \in \hbox {VM}\nonumber \\ \end{aligned}$$
      (6)
      For an application component \(\hbox {ac}_j\) to be placed in a virtual machine \(\hbox {vm}_i\) (\(P(\hbox {ac}_j)=\hbox {vm}_i\)), it will be mandatory to have its processing requirements \(\hbox {pcReq}_{\mathrm{ac}_j}\), RAM requirements \(\hbox {mReq}_{\mathrm{ac}_j}\) and storage requirements \(\hbox {size}_{\mathrm{ac}_j}\) inferior to the respective available capacities of processing \(\hbox {pc}_{\mathrm{vm}_i}\), RAM \(\hbox {RAM}_{\mathrm{vm}_i}\) and storage \(\hbox {Disk}_{\mathrm{vm}_i}\) in the hosting VM \(\hbox {vm}_i\).
    • The deployment of DCs in the storage servers (SS) must be proportionate to the available storage capacity of the SS. Equation (7) depicts this constraint of disk capacity.
      $$\begin{aligned} \displaystyle \sum _{\mathrm{dc}_j \in \mathrm{DC}} \hbox {sizeDC}_{\mathrm{dc}_j} \le \hbox {diskSS}_{\mathrm{ss}_i} | D(\hbox {dc}_j)=\hbox {ss}_i,\quad \forall \,\hbox {ss}_i \in \hbox {SS}\nonumber \\ \end{aligned}$$
      (7)
      For a data component \(\hbox {dc}_j\) to be placed in a storage server \(\hbox {ss}_i\) (\(D(\hbox {dc}_j)=\hbox {ss}_i\)), it will be mandatory to have its storage size \(\hbox {sizeDC}_{\mathrm{dc}_j}\) inferior to the available disk space \(\hbox {DiskSS}_{\mathrm{ss}_i}\) in the hosting server \(\hbox {ss}_i\).
     
  2. 2.
    SLA constraints: The SaaS provider should respect this constraint under any circumstances and provide a SaaS with an ETET that must not exceed the maximum response time agreed on with the user in the SLA. Equation (8) denotes this constraint.
    $$\begin{aligned} \hbox {ETET(SaaS)} = \hbox {mtrt}_{\mathrm{SLA}} \end{aligned}$$
    (8)
    where \(\hbox {mtrt}_{\mathrm{SLA}}\) means maximum total response time provided in the SLA.

    Bhardwaj (2015), however, considers that every single SaaS component has a maximum execution time defined by the user in the SLA. This very unlikely to occur in because the user is generally not aware of the back end of the composite SaaS. This unawareness includes not knowing which or how many components are used to satisfy his customized demands from the SaaS. Therefore, a total maximum response time for the SaaS is considered in this research.

     

4 Swarm intelligence and particle swarm optimization with composite particles

In this present work, a recent meta-heuristic algorithm is used for solving the SPP. It is a new variant of the original PSO and it’s called “PSO with composite particles”(PSO-CP) (Liu et al. 2010).

Inspired from physics, composite particles in PSO-CP are a particular kind of solutions that consist of two or more elementary particles composed via chemical actions. This composition technique allows particles to have new superior properties like resistance to oxidation and stability. So the developers of PSO-CP wish to bring those advantages of composition technique from physics branch to the optimization process in order to tackle dynamic environments that classic PSO cannot handle well. PSO-CP model has the following three characteristics.
  1. 1.

    Composite particles are constructed from two or more (generally three) similar elementary particles.

     
  2. 2.

    The information-sharing mechanism among different composite particles is the same in the classic PSO model (through lbest and gbest values). A chosen pioneer particle from each composite particle will be in charge of those inter-communications.

     
  3. 3.

    Elementary particles share information between them using a specific reflection method and an integral movement scheme.

     
The following subsections will describe the construction and operations of PSO-CP. Figure 2 illustrates them.

4.1 Construction of the composite particles

Initially, a swarm is given as an input, all particles are made individually such that each particle has its own velocity, position and fitness value. The composition process begins by defining firstly the size of each composite particle. In the original work for instance, the authors have chosen three elementary particles for each composite particle. Hence, a composite particle will form a triangle. Any particles that failed to form a composite particle at the end of this process will be referred to as ’independent particles’ (see Fig. 2).

Before the composition process, all particles are sorted in the order of increasing fitness values to apply a ’worst first’ idea in the construction that considers the worst particles as a priority. Each composite particle is constructed by taking the ’worst’ particle and then, the two other ’closest’ particles are selected and added to the composite particle in terms of the Euclidean distance. This iteration keeps repeating until no enough particles left to construct any composite particle (less than three).

4.2 Self-adjustment for composite particles

In the original PSO-CP work in Liu et al. (2010), it is assumed that each composite particle in PSO-CP should adjust its internal structure to enhance the efficiency of search in dynamic environments, just like in physics when a composite particle behaves better when its elementary particles interact. There are two major concerns for each composite particle:
  1. 1.

    The first concern is how to develop an interaction method among elementary particles.

     
  2. 2.

    The other concern is selecting an elementary particle that will play the role of a representative of the composite particle that is responsible of sharing valuable information with other composite and independent particles.

     
For the first concern, a velocity-anisotropic reflection (VAR) scheme is introduced in Liu et al. (2010). This scheme helps particles to explore the search space more extensively. The idea is to replace the “worst”-fitted elementary particle in the composite particle with another reflection point toward a better search space and keep the other two elementary particles (see Fig. 2b).

Initially, a composite particle is composed of three elementary particles \(\langle P,Q,W \rangle \). The position of the worst particle is denoted as W and a point M is randomly generated on the straight line between particles P and Q and will be used for the reflection. The resulting reflection point R is generated. If the new particle R is fitter than W, a reflection of the composite particle occurs and the new composite particle is composed of \(\langle P,Q,R \rangle \). The composite particle will stay the same if R is worst than W.

The reflection point R is calculated using Eq. 9:
$$\begin{aligned} \overrightarrow{\hbox {WR}} = \overrightarrow{\hbox {WM}} + R_{\mathrm{step}}\overrightarrow{\gamma } * \overrightarrow{\hbox {WM}} \end{aligned}$$
(9)
where \(R_{\mathrm{step}}\) is the reflection step size that controls the degree that the worst particle moves from point M in the direction of \(\overrightarrow{\gamma } * \overrightarrow{\hbox {WM}}\), \(\overrightarrow{\gamma }\) is the VAR vector. To avoid a rapid convergence within the composite particle, \(R_{\mathrm{step}}\) prevents the reflection point R from moving too close to M. The VAR vector can drive composite particles to explore the D-dimensional search space. Each element in the VAR vector is generated using the following equation:
$$\begin{aligned} \gamma _{ij} = \hbox {rand}(0,\hbox {e}^{-|v_{ij}/v_{\mathrm{max}}|}),\quad i \in 1,\ldots ,N_c,\quad j \in 1,\ldots ,N \end{aligned}$$
(10)
where \(\gamma _{ij}\) and \(v_{ij}\) denote the reflection factor and the velocity of the ith composite particle in the jth dimension, respectively, and \(N_c\) is the number of composite particles.

Figure 2b shows an example of a VAR application.

As for the second concern, a simple idea is adopted by Liu et al. (2010) which is selecting the elementary particle with the best fitness value to be the ‘pioneer’ particle that is responsible for information-sharing from within the composite particle and to the whole remaining particles in the swarm (see Fig. 2c). The information-sharing mechanism between pioneer particles is similar to the classic PSO’s mechanism. To further enhance diversification, a scattering operation may be applied to prevent the particles in a composite particle from converging. A repulsion technique is applied when the distance between the worst two particles is less than a threshold limit.

Another limit for PSO is the potential loss of valuable information since particles movement is driven by the swarm and particle attractors and, in result, some regions of search space may be skipped. This can lead to diversity loss (Liu et al. 2010). Therefore, an integral movement (see Fig. 2d, e) is proposed in PSO-CP where the elementary particles inside the composite particles move with the same velocity as the pioneer particle after the latter is updated. This movement scheme is adopted so that the elementary particles can move under the right guidance toward a better search space while valuable information is preserved for the next iteration.

5 Proposed PSO-CP approach to solve the SPP

For the sake of brevity, the proposed approach in this paper is referred to as ’SPP-CPSO’ in this section and onwards. SPP was proven to be NP-hard just like its ancestor CPP (Kwok and Mohindra 2008; Urgaonkar 2004; Yusoh 2013). So a meta-heuristic algorithm like PSO-CP should be fitted to solve the problem.

Table 1 shows how the PSO-CP will fit to the treated problem.
Table 1

Adapting PSO-CP parameters to SPP

PSO-CP concept

Intended use in the proposed approach

Swarm

All servers in the data center (CS and SS)

Particle

A candidate computation or storage server to place SaaS components into

Composite particle

A candidate placement scheme for all SaaS components (either AC and DC)

Elementary particle

A candidate placement for some of the components in the SaaS (partial solution)

Independent particle

Left-out unused servers after construction of placements

Position of particle

Currently deployed components in the candidate server and current resource usage

Velocity of particle

Rate of variations to the fitness value for a candidate server

Fitness of a particle

Evaluation function (execution time \(+\) resource usage) for the candidate partial placement in the server

Fitness of a composite particle

Evaluation function (execution time \(+\) resource usage) for the full placement

Worst particle

Elementary particle with the worst fitness in the composite particle

pBest

Best full placement found so far by a single composite particle

gBest

Best full placement found so far by any composite particle in the swarm

Fig. 3

Flowchart diagram of the SPP-CPSO

The proposed solution can be summarized in five steps (see Fig. 3).
  1. 1.

    Initialization: First of all, the swarm of particles or what is referred to as the initial solutions should be constructed by assigning components (AC or DC) into different sets of particles (CS or SS) and selecting those to form the composite particles (full placement scheme of all SaaS components) and those to stay as independent particles (unused servers).

     
  2. 2.

    Evaluation: In order to know what are the candidate servers most fitted for good SaaS placement, an evaluation procedure based on total execution time and resource usage rate is executed in each iteration.

     
  3. 3.

    Selection of worst particles: From each candidate placement, there is always two candidate servers (CS and SS) that have the worst fitness cost. Those two costs play a great factor for affecting the overall quality of the solution. So these two worst candidate servers (particles) must be selected and may be replaced by other servers.

     
  4. 4.

    Sorting of worst and independent particles: After selecting worst computation and storage servers from the candidate placement schemes, they are joined to the unused servers (independent particles) and sorted in a decreasing order based on their overall capacity.

     
  5. 5.

    Reallocation: From the obtained list of worst and independent particles, composite particles can acquire one or more particles to include. The SaaS components that were hosted in the recently eliminated worst particles (CS or SS or both) will now be assigned in the recently acquired particle(s).

     
In the following subsections, the proposed approach SPP-CPSO is explained in details by presenting the different steps.

5.1 Construction of the initial candidate placements

This module presents the initial phase of the composite SaaS placement using the SPP-CPSO technique. Algorithm 1 presents the different steps of the initial placements construction. The algorithm takes the list of computation and storage servers and the composite SaaS’s application and data components as an input. This list of servers is sorted in a decreasing order of their overall capacities. Overall capacity of a server \(S_i\) (\(\hbox {OC}(S_i)\)) is calculated using formula 11.
$$\begin{aligned} \hbox {OC}(S_i)= \left\{ \begin{array}{ll} (\hbox {pc}_i + \hbox {RAM}_i + \hbox {disk}_i)/3,&{} [\hbox {if}\quad S_i\,\hbox {is a CS}] \\ \hbox {diskSS}_i,&{} [\hbox {if}\quad S_i\,\hbox {is a SS}.] \end{array}\right. \nonumber \\ \end{aligned}$$
(11)
The algorithm should produce the list of composite particles \(L_{\mathrm{cp}}\) and independent particles \(L_{\mathrm{ind}}\) if there is any.

In [Lines 1–4] of Algorithm 1, the algorithm simply makes for each CS or SS server in the given list a particle to represent it.

After initializing the counters and starting with empty lists of composite and independent particles, for each particle \(P_j\) the algorithm checks what set of components from \(L_C\) can be deployed in \(P_j\). If \(P_j\) can at least hold one component (AC or DC according to the type of server represented by \(P_j\)), it’s added to a temporary composite particle \(\hbox {tempCP}\) [Lines 12–17]. The reason behind using temporary composite particle is anticipating the case when a set of servers (with low capacities generally) were not able to host all of SaaS components, and hence, they are emptied and considered as independent particles (unused servers). The temporary composite particle is considered as an actual one otherwise.

The proposed algorithm constructs the composite particle and adds it to the list \(L_{\mathrm{cp}}\) in [Lines 20–31]. When all of the composite SaaS is deployed on different computation and storage servers, other placement schemes are later tried in other sets of servers. This construction process repeats until no servers in the decreasing list are left to check.

After all possible placement schemes are constructed and represented by composite particles in \(L_{\mathrm{cp}}\), those remaining particles (representing all CS and SS) that do not belong to any composite particles are considered as ’independent’ and added to the list \(L_{\mathrm{ind}}\), [Lines 32–34].

Figure 4 shows an example of initial placements construction. In this figure, x shall be the number of particles representing n computation servers \(+\) m storage servers. Let AC1, AC2, AC3, D1, D2 the application/data components of the composite SaaS that need to be placed strategically. From the list of x particles, we were able to select different y sets of servers   \(\hbox {CP}1,\hbox {CP}2,\ldots ,\hbox {CPy}\) that can place all the components included in the SaaS. The remaining servers P20, P29, P30 were not able to participate in a full placement scheme. Subsequently, they will remain unused and referred to as “independent particles.”
Fig. 4

A swarm of particles and the initial candidate placements in SPP-CPSO

The initial placements are now ready to be evaluated and altered until an optimal solution is obtained.

5.2 Evaluation process

In this step, the “fitness” of each candidate solution is calculated, and hence, each used server will be evaluated in order to calculate the fitness of the containing placement scheme. Those obtained fitness values will be useful to know which are the “worst” servers in each placement scheme, the local and global optimas in the search space.

It was mentioned in the SPP formulation presented in Sect. 3 that the objective is finding a placement with a minimal total execution time while maintaining machine performance. In this research, the total execution time of the composite SaaS is based on three attributes : (a) the time taken for transferring data between different servers (CS–CS) or (CS–SS), (b) the processing time of application components in computation servers, (c) the sum of execution time of all components in a SaaS.
  1. (a)
    Data transfer time (DTT) The estimated time to transfer data between components in a given placement scheme is based on the amount (in bytes) of Read/Write \(\hbox {amountRW}_i\) for each application component \(\hbox {ac}_i\) to another AC or data components in storage servers. DTT is also based on the bandwidth \(B_{v_{j},v_{k}}\) strength between the hosting server \(v_{j}\) and the server which hosts the communicating other component \(v_{k}\). The bandwidth is calculated by “bytes per second,” e.g., \(B_{v_{1},v_{2}}= 20~\hbox {GB}/s\) . DTT is calculated using Eq. 12:
    $$\begin{aligned} \hbox {DTT}(\hbox {ac}_i)= \frac{\hbox {amountRW}_i * 8}{B_{v_{j},v_{k}}} \end{aligned}$$
    (12)
    For simplicity reasons, several works in the literature (Kumar 2014; Liu et al. 2014; Tang and Yusoh 2012; Yusoh and Tang 2010a) considered a single unified value of \(\hbox {amountRW}_i\) for a component \(\hbox {ac}_i\) toward any other connected (dependent) component in the SaaS. In this research, we assign a \(\hbox {amountRW}_i\) a random value between 100 and 500 MB/s.

    Nevertheless, this value is not a big factor for calculating the execution time if the composite SaaS is deployed in a modern, average cloud data center where the average bandwidth is about 10–20 GB/s according to a study by Cisco in Cisco (2016). A component will rarely reach 10 GB (1250 MB) of exchanged data. So in general, a DTT will not reach more than 1 s or maybe tenths of a second.

     
  2. (b)
    Processing Time (PT) The calculation of processing time of an application component \(\hbox {ac}_i\) placed in a computation server \(\hbox {cs}_j\) is based on the processing requirement (or task size) of the component (\(\hbox {pcReq}_i\)), the processing capacity of the server \(\hbox {pc}_{j}\), and the value of DTT for the component (if there is any) (Yusoh 2013). But if a component has different data exchanges with different other ACs or DCs, only the maximum DTT will be considered. Equation 13 is used to calculate the processing time of a component:
    $$\begin{aligned} \hbox {PT}(\hbox {ac}_i)= \frac{\hbox {pcReq}_i}{\hbox {pc}_{j}} + \hbox {max}(\hbox {DTT}(\hbox {ac}_i)) \end{aligned}$$
    (13)
     
  3. (c)
    Estimated total execution time (ETET) The ETET of the SaaS S is simply the sum of processing time of all the components (ACs) in the SaaS. The ETET is defined as:
    $$\begin{aligned} \hbox {ETET}(S)= \displaystyle \sum _{\mathrm{ac}_i \in S} \hbox {PT}(\hbox {ac}_i) \end{aligned}$$
    (14)
    This value is very important and will be used to obtain the optimal placement solution.
     
Now to relate to the proposed approach SPP-CPSO where a particle represents a server (either CS or SS), the calculation of the processing time inside a single particle \(\hbox {PT}(P_j)\) is needed. Another objective is considered in this work, which is maintaining the performance of the hosting machines \(\hbox {Usage}(P_j)\) at a moderate level, that is, keeping the CPU and RAM utilization at a moderate level. Since storage servers (SS) will not host any components that need processing or RAM access, those two attributes are only valid if \(P_j\) represents a CS, and they are calculated using the following two equations:
$$\begin{aligned} \hbox {Usage}(P_j)= & {} \frac{\sum _{\mathrm{ac}_i \in P_j} \hbox {pcReq}_i + \hbox {mReq}_i}{\hbox {pc}_j + \hbox {RAM}_j} \end{aligned}$$
(15)
$$\begin{aligned} \hbox {PT}(P_j)= & {} \displaystyle \sum _{\mathrm{ac}_i \in P_j} \hbox {PT}(\hbox {ac}_i) \end{aligned}$$
(16)
with \(P_j\) is the elementary particle which represents the hosting CS in a placement solution, \(\hbox {PT}(\hbox {ac}_i)\) is the processing time of every component \(\hbox {ac}_i\) placed in the CS represented by \(P_j\), \(\hbox {mReq}_i\) and \(\hbox {pcReq}_i\) are the RAM memory and processing capacity requirements for every component \(\hbox {ac}_i\) assigned to the CS of \(P_j\), and \(\hbox {pc}_j\) and \(\hbox {RAM}_j\) are the processing and the RAM capacity for the CS of particle \(P_j\).
Both optimization objectives calculations can now be combined to calculate the fitness value \(F(P_j)\) of each elementary particle based on the processing time inside the CS and its RAM and CPU usage percentage. As for a particle \(P_j\) that represents a SS included in the solution, \(F(P_j)\) will be calculated using another equation. Both fitness calculations of those two cases are represented in Eqs. 17 and 18:
$$\begin{aligned} \begin{aligned} \hbox {Min} (F(P_j)) =&{I_T} \left( \frac{\hbox {PT}(P_j)}{N_c}\right) * {I_U} (\hbox {Usage}(P_j)) \\&\quad [\hbox {if}\,P_j\,\hbox {is CS}] \end{aligned} \end{aligned}$$
(17)
With \({I_T}\) and \({I_U}\) are numerical values between [0,1] which present the importance factors of the execution time and resource usage, respectively, and \(N_c\) is the number of components inside the particle \(P_j\). To discourage the underutilization of the resources and encourage having a minimal execution time as the most important objective, we should set a \({I_U}\) value that is smaller than \({I_T}\).
$$\begin{aligned} \begin{aligned} \hbox {Max} (F(P_j))&= \frac{\sum _{P_i \in \hbox {SR}(P_j)}\hbox {Bandwidth}(P_i,P_j)}{\text {Number of SR } (P_j)}\\&\quad [\hbox {if}~P_j\,\hbox {is SS}] \end{aligned} \end{aligned}$$
(18)
With \(P_i \in \hbox {SR}(P_j)\) means that the CS represented by \(P_i\) is on the list \(\hbox {SR}(P_j)\) of servers requiring access to the SS represented by \(P_j\). A CS requiring access to a SS means that there are some application components in the former that need data components deployed in the latter. So in order to access a server, we need the communication links provided by the data center between the two servers. The communication link between \(P_i\) and \(P_j\) has a certain bandwidth value \(B{p_i,p_j}\) that is used for the calculation of this fitness cost. \(\hbox {SR}(P_j)\) is the number of all the servers that need access to \(P_j\).

With those parameters, \(F(P_j)\) symbolizes how ’adjacent’ (or ’close’) is the SS represented by \(P_j\) to the other computation servers that needs access to it in the current placement scheme based on the bandwidth of the involved communication links. Therefore, this value should be maximized in order to guarantee choosing the SS with the strongest average bandwidth value with the ACs needing access to it.

After calculating the processing time inside each participating CS, the Total Execution Time (TET) of the placement scheme \(\hbox {CP}_k\) can be calculated. It should be noted that this TET should not exceed the maximum execution time \(\hbox {mtrt}_{\mathrm{SLA}}\) agreed on in the SLA contract:
$$\begin{aligned} \hbox {TET}(\hbox {CP}_k) = \displaystyle \sum _{P_j \in \hbox {CP}_k} \hbox {PT}(P_j)<\hbox {mtrt}_{\mathrm{SLA}} \end{aligned}$$
(19)
Using the same method for evaluating a participating server, calculating the global fitness of the candidate placement scheme represented by a composite particle is now possible using:
$$\begin{aligned}&\hbox {Min} (F(\hbox {CP}_k))\nonumber \\&\quad = {I_T} ( \hbox {TET}(\hbox {CP}_k)) * {I_U} \left( \frac{\sum _{P_j \in \hbox {CP}_k} \hbox {Usage}(P_j)}{N_p}\right) \end{aligned}$$
(20)
With \({I_T}\) and \({I_U}\) are the importance factors. The first segment multiplied by \({I_T}\) is equivalent to \(\hbox {ETET}(S)\) where S is the composite SaaS placed using the \(\hbox {CP}_k\) placement scheme. The second factor of the evaluation multiplied by \({I_U}\) is the average resource usage for all \(N_p\) elementary particles that represent CS inside \(\hbox {CP}_k\).

5.3 Selection of worst particles

Just like the original PSO-CP algorithm (Liu et al. 2010) where a composite particle becomes composed of \(\langle A,B,R \rangle \) instead of \(\langle A,B,W \rangle \) if a point R is fitter than the worst point W, the SPP-CPSO selects the worst computation server and the worst storage server in a placement scheme based on their fitness values (calculated by Eqs. 17 and 18 respectively). Those two “worst” CS and SS may or may not be replaced with other unused servers in the reallocation. This procedure is important to improve the solutions’ quality. Figure 5 shows a possible scenario of this step.
Fig. 5

Selecting the worst computation and storage servers from placement schemes based on their individual fitness value

In the proposed example shown in Fig. 5 and all other examples below, the SaaS is composed of four application components \(\langle \hbox {AC}1,\hbox {AC}2,\hbox {AC}3,\hbox {AC}4 \rangle \) and three data components \(\langle D1,D2,D3 \rangle \). Initial placement schemes were already constructed in the first procedure (see Sect. 5.1). Each server in a placement scheme is evaluated. A fitness value of a particle is calculated with the Eq. 17 if it represents a CS or Eq. 18 if it represents a SS. The fitness values \(F(P_j)\) are then associated with each computation or storage server.

The CS with the maximal value \(F(P_j)\) gets selected as the ’worst’ in the composite particle since the objective here is minimizing. This is not the case for particles representing SS. The storage server with the minimal value \(F(P_j)\) gets selected as the “worst” because \(F(P_j)\) in formula 18 depicts the average bandwidth value between the SS and the computation servers requiring access to it. Those two selected servers \(W_{\mathrm{cs}}\) and \(W_{\mathrm{ss}}\) (marked by red crosses in Fig. 5) are then added to the list of independents and they may be used in a new placement scheme, remain in the current composite particle or become unused. Therefore, they are not emptied and reinitialized like other independent particles as there is a possibility that they will not be eliminated from the current placement.

The reallocation of a worst server to another placement scheme can be useful for improving its fitness value by (a) hosting another set of components if reallocated to another placement scheme, or (b) transferring to a better set of collaborating servers (other elementary particles). This reallocation step will be described further in Sect. 5.5.

5.4 Sorting the worst and independent particles

After selecting those worst computation and storage servers in the previous step, they join the list of (independent) servers that are ready for deployment of the SaaS components if needed. The obtained list is divided into two sets:
  • List of worst and independent particles that represent computation servers (CS)

  • List of worst and independent particles that represent storage servers (SS)

Both of the lists are sorted in a decreasing order using formula 11 that was used in the initial phase of construction (see Sect. 5.1).
Figure 6 shows an example of this step. It should be observed that the worst particle is not necessarily the particle with the lowest overall capacity. Particle P6 for example represents a stronger server than P4 but placing those certain components AC2 and AC4 in P6 and being affected to the other elementary particles in the candidate placement \(\hbox {CP}_2\) gave that particle the worst fitness value.
Fig. 6

Selecting the worst CS and SS particles and sorting them with independent particles

5.5 Reallocation of particles to new composite particles

After selecting the worst computation and storage servers from each candidate placement scheme, the composite particle will need to replace the worst servers with new ones. After that, the non-affected SaaS components (ACs and DCs) that were previously placed in the eliminated servers need to be assigned to the new ones. There will be no reallocation when the acquired new servers fail to improve the solution quality. Figure 7 illustrates the reallocation step.
Fig. 7

Reallocation of particles

This process takes as an input the obtained two sorted lists of ’worsts’ and independent CS and SS in the previous step. From those two lists, composite particles will acquire one or many elementary particle(s) to host the on-hold components. The main objective of this step is to improve the quality of solutions in the next iterations. In Fig. 7. We have three candidate placements CP1, CP2 and CPy. They are using different sets of computation and storage servers. Three types of scenarios are shown in this figure:
  1. 1.

    Exchanging of the worst particles between two composite particles: Take CP1 and CP2 for example, they have exchanged their worst CSs: P2 and P6, respectively, and both of their solutions’ qualities have improved by this reallocation step.

     
  2. 2.

    No reallocation: Like CP1 and CPy, the first placement scheme represented by CP1 did not find in the current list of storage servers any SS that can improve its global fitness of the solution. CPy also failed to find any CS better for its solution quality than P13. Therefore, no reallocation will occur in this iteration and could possibly occur in next iterations when both lists of CS and SS servers are updated.

     
  3. 3.

    Replacing one worst by two or more servers: Like CP2 and CPy, both of their worsts servers have big capacities that they can’t be replaced by less than two servers of the same type (CS or SS). CP2 has acquired the two storage servers P24 and P25 to replace P23. CPy has acquired the two SS P28 and P29 that were unused to replace P26. The same procedure will happen if those servers were computation servers.

     
It should be noted that after the reallocation, we have new independent particles because the reallocation phase has used some of the old ones in candidate placement schemes (two independents were used in CPy) and some worst servers were eliminated and became unused (like P23). The independent particles in Fig. 7 are illustrated by the white circles namely: \(\langle P17, P18, P19 \rangle \) as independent CS particles and \(\langle P23, P30 \rangle \) as independent SS particles. This reallocation step is repeated for multiple iterations alongside with the evaluation, selection, and sorting of the worst particles (as shown in the flowchart diagram in Fig. 3) until no improvement in terms of fitness can be reached for all existing placement schemes and no reallocation occurred in an iteration t. This means that the proposed approach has found the optimal solution (gbest) in one of the last obtained placement schemes.

6 Experimental studies

To evaluate the efficiency and the quality of solutions produced by the proposed SPP-CPSO algorithm, it was implemented using a java eclipse IDE (implementation is available on this URL: https://goo.gl/yuhvsu) and several experiments were executed in an ASUS laptop computer with 2.0 GHz Intel Core i7-4750 CPU and 8 GB RAM. Generally, the best way to evaluate the quality and efficiency of the algorithm is to compare it with solutions obtained by existing techniques on the same problem. However, there is no existing benchmark with which to compare this problem. Every research work treating the SPP is using different, randomly generated simulation and parameters.

The proposed SPP-CPSO approach is then compared to a GA similar to the one proposed by Yusoh and Tang (2010a) that we developed and adjusted with our own parameters, objectives and random simulation of the data center. Both of them are then compared to a first-fit decreasing (FFD) heuristic algorithm that is developed to solve the SPP. FFD is a simple and commonly used for bin-packing problem. A bin-packing problem is a problem of placing a set of items into a set 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 (Lodi et al. 2002).

The FFD developed here will address the SPP constraints and complexities.

Table 2 shows the simulation parameters used for FFD, GA, and the proposed SPP-CPSO algorithm.
Table 2

Simulation parameters for FFD, GA, and SPP-CPSO algorithms

Parameter

Value

Amount of data read/write for components

100–500 MB

Bandwidth between servers

5–30 GB/s

Termination condition

One iteration of reallocation that did not improve any solution

\({I_T}\) (importance factor of SaaS execution time)

0.8

\({I_U}\) (importance factor of capacity usage)

0.2

Table 3

Experimental results of the first-fit decreasing (FFD), genetic algorithm (GA), and the SPP-CPSO for test problems with different numbers of cloud servers (CS and SS)

Number of servers

Algorithm

ETET (ms)

Capacity usage (%)

Computation time (ms)

CS

SS

Min

Max

Avg

Min

Max

Avg

100

50

SPP-CPSO

2197

2733

2496

54.75

52

68

63.25

FFD

2666

3231

2946.75

73.37

28

29

28.5

GA

2288

3179

2787.12

53

90

130

109

200

100

SPP-CPSO

2174

2973

2517.31

49.12

110

206

167.625

FFD

2782

3614

3143.25

67.87

51

79

67.8

GA

2325

3456

3028.87

51.22

180

310

211.25

400

200

SPP-CPSO

2086

2638

2317.25

47

459

571

514.25

FFD

2814

3309

3128.62

74

71

75

72.37

GA

2475

3699

2968.87

46.75

480

750

603.5

600

300

SPP-CPSO

1920

2791

2322.37

46.12

1033

1825

1390.75

FFD

2841

3765

3269,87

71.5

102

173

137

GA

2247

3201

2750.12

54.2

779

2709

1383.5

1000

500

SPP-CPSO

1823

2690

2256.12

48.87

2975

4418

3724.87

FFD

2915

3624

3293.25

65.5

200

317

276.12

GA

2515

3074

2782,75

50.62

1380

3110

1915.1

1500

750

SPP-CPSO

1800

2688

2180.87

52

6342

11,822

8195.37

FFD

2929

3697

3228.75

68

481

498

491.25

GA

2249

3228

2833.75

48.62

3081

7780

4428

Two sets of experiments were conducted to evaluate the three algorithms and investigate the quality of the produced solutions alongside with the scalability of the algorithms:
  • Experiments on the number of servers: A varying number of servers and a fixed number of SaaS components will be the parameters of testing the algorithms.

  • Experiments on the number of SaaS components: The parameters for the algorithms here will have a changing number of SaaS components but the number of servers will stay the same all along the set of experiments.

Since all three algorithms consisted of some stochastic elements in their implementation (random capacities of servers, random requirements of components, bandwidth...), each of the test problems was executed 10 times. The solution is evaluated based on the whole execution time of the SaaS (ETET) and the capacity usage of the hosting servers.

6.1 Experiments on the number of servers

These experiments on the number of servers are to investigate the impact of the data center’s size on the solutions’ quality and the computation times of the algorithms. A fixed number of SaaS components 15 (with 10 AC and 5 DC) and 6 test problems with different number of servers for each test problem were used for these experiments.

Table 3 shows the best, worst and average quality of produced solutions based on ETET, the average percentage of resource usage from the hosting servers and the quickest, lowest and average computation time taken to achieve the optimal solution for six test problems. The number of servers differs in each test problem: \(\langle 150,300,600,900,1500,2250\rangle \). For each number of servers, about 1/3 of it are storage servers (SS) and the other 2/3 of those servers are computation servers (CS). The best average values for all test problems are highlighted in boldface.

The experimental results presented in Table 3 show that the shortest execution time for each test problem were always achieved by the SPP-CPSO. The lowest percentage of capacity usage is mostly obtained by SPP-CPSO except for only two test problems (case of 600 servers and 2250 servers). The SPP-CPSO, for all test problems, produced the best placements which are better than FFD solutions by approximately 500 up to 1000 ms and better than GA by 300 up to 700 ms. As for the usage of the CS capacities within the machines hosting the composite SaaS, candidate placements produced by SPP-CPSO uses in average 19.6% less than the ones produced by FFD.

Results in Figs. 8 and 9 show that the performance of the composite SaaS for the optimal placements obtained by SPP-CPSO doesn’t degrade with an increasing number of servers. It should also be noted that the gap of solutions’ execution time between SPP-CPSO and FFD enlarges when the data center size gets bigger. This means that composite particles behave and cooperate better when searching the optima in the search space when the latter expands.
Fig. 8

Average ETET for solutions produced by SPP-CPSO, GA, and FFD with a varying number of servers (CS and SS)

Fig. 9

Variations on the ETET of solutions produced by SPP-CPSO, GA, and FFD while increasing the size of the data center

The solution quality is also based on the resource usage of the hosting machines, Fig. 10 shows how much the solutions produced by the three algorithms use from the machines that host the different components of the composite SaaS in average. The ones produced by SPP-CPSO are generally the most economic solutions.
Fig. 10

Average machine usage percentage of the solutions produced by SPP-CPSO, GA, and FFD while increasing the size of the data center

Using those two objectives (ETET, machine usage), the quality (fitness) of the solution can be calculated using the importance factors \({I_T}\) and \({I_U}\) that were explained in Table 2. To normalize the values between the ETET and the percentage of machine usage, the percentage of the gap between the obtained ETET and the SLA maximum response time (\(\hbox {SLA}_{\mathrm{mtrt}}\)) is used as shown in Eq. 21.
$$\begin{aligned} \hbox {Fitness} = \left( {I_T} * \frac{\hbox {ETET}*100}{\hbox {SLA}_{\mathrm{mtrt}}}\right) + ({I_U} * \hbox {Usage}) \end{aligned}$$
(21)
The average fitness for each of the test problems while increasing the number of servers are illustrated in Fig. 11. Results indicate that SPP-CPSO outperformed both GA and FFD in terms of solutions’ qualities.
Fig. 11

Average quality of the solutions produced by SPP-CPSO, GA and FFD while increasing the size of the data center

Regarding the computation time of the analyzed algorithms, Fig. 12 illustrates the increasing of the time needed to find the optimal solution by SPP-CPSO, the GA and the heuristic FFD. Results indicate that the latter recorded fast and stable computation time. The GA growth was somewhat linear as the number of servers enlarges. The proposed algorithm’s computation time recorded an exponential growth while searching for optima in the range of [900...2250] servers despite being stable and growing in a linear fashion while the number of servers where between [150...900]. This is understandable because the search space increased radically by more than 1200 servers and the composite particles execute their search in a very wide region from this large search space of 1500 and 2250 servers. But in the end, the search is often rewarded with good-quality solutions obtained by the composite particles due to their diverse exploration of the search space.
Table 4

Experimental results of the first fit decreasing (FFD), genetic algorithm (GA) and the SPP-CPSO for test problems with different numbers of SaaS components

Number of components

Algorithm

ETET (ms)

Capacity usage (%)

Computation time (ms)

AC

DC

Min

Max

Avg

Min

Max

Avg

6

3

SPP-CPSO

1078

1553

1263.87

42.25

438

644

546.8

FFD

1491

2375

1904.62

72.37

70

77

73.5

GA

1344

1933

1670.25

52.37

366

596

421

10

5

SPP-CPSO

1578

2830

2390.37

47.25

415

855

694.12

FFD

2409

3838

3199.12

71.87

70

77

71.8

GA

2329

3199

2787.87

51.25

354

547

429.25

20

10

SPP-CPSO

4443

5954

5067.37

55.92

879

1579

1130.25

FFD

6433

7729

7198.12

72.87

71

76

77.16

GA

5452

6193

5959.12

54.7

366

716

503.5

30

15

SPP-CPSO

6953

8634

7893.5

58.9

948

1816

1360.25

FFD

9124

11,079

10,480.6

77.37

75

81

77.37

GA

8177

10,319

9072.37

62.5

379

1200

636.5

40

20

SPP-CPSO

10,208

11,286

10,658.2

60.25

1025

2217

1743.8

FFD

13,489

15,188

14,028.8

78.37

76

85

79.39

GA

11,089

13,769

12,658.7

59.62

593

907

738

Fig. 12

The effect of the data center’s size on the computation time for SPP-CPSO, GA and FFD

6.2 Experiments on the number of SaaS components

In this set of experiments and similar to the previous set, the SPP-CPSO, GA and FFD algorithms are tested with different test problems with a varying number of SaaS components and a fixed number of servers 600 (400 CS and 200 SS). The objective is to study the impact of varying the number of SaaS components on the quality of the solution produced by the algorithms as well as on the computation time.

Table 4 shows the best, worst and average quality of produced solutions based on ETET, the average percentage of resource usage from the hosting servers and the quickest, lowest, and average computation time taken to achieve the optimal solution for five test problems. Each one of the five has a different number of SaaS components \(\langle 9, 15, 30, 45, 60 \rangle \). We adopted the strategy of having 1/3 of those components as data components (DC) and the other 2/3 are application components (AC). The best average values for all test problems are highlighted in boldface.

The experimental results presented in Table 4 show that the shortest execution time and lowest percentage of capacity usage for each test problem were always achieved by the proposed algorithm. The SPP-CPSO produced the best placements which are better than FFD solutions by approximately 700–3500 ms and better than GA solutions by approximately 400–2000 ms. The difference between solutions quality and superiority of SPP-CPSO is more obvious for large numbers of SaaS components.

Regarding the capacity usage for the hosting machines, the obtained candidate placements produced by SPP-CPSO use in average 23% which is less than the ones produced by FFD and slightly better than GA’s candidate placements’ resource usage.
Fig. 13

Average ETET for solutions produced by SPP-CPSO, GA and FDD with a varying number of SaaS components (AC and DC)

Fig. 14

Variations on the ETET of solutions produced by SPP-CPSO, GA and FDD while increasing the number of SaaS components (AC and DC)

Results in Figs. 13 and 14 illustrate the effect of increasing the number of SaaS components (AC and DC) on the three algorithms: SPP-CPSO, GA, and FFD. The average ETET of candidate placements grows linearly when the number of SaaS components grows. This is understandable since every SaaS application component has a processing time and data transferring time to other ACs or DCs and both of these two amounts are included in the calculation of ETET. We can also see that the difference regarding the quality of solutions between SPP-CPSO and the other two techniques GA and FFD gets more obvious when the number of SaaS components increases, especially the gap between SPP-CPSO and FFD. This returns to the fact that the heuristic FFD’s search gets stuck in a local optima by deploying the most requiring components in the most powerful available servers and disregarding the strength of dependency between components (AC and DC) and the strength of communication links between computation and storage servers (bandwidth value in Gbps). It was mentioned in the Sect. 5.2 that the amount of data exchange will not strongly affect the ETET, but with a large number of components, the sum of those amounts of time becomes an important value. The SPP-CPSO, however, explores a wide range of the search space and can find the optimal or suboptimal placements which consist of placing the SaaS AC and DC components in a set of powerful (or medium power) servers that have strong communication links allowing the components to interact and execute rapidly. The GA also scales well according to the results.

Since the solution quality is also evaluated on the resource consumption for the hosting machine, just like the previous set of experiments, Fig. 15 shows how much, in average, the solutions obtained by all the used algorithms use from the machines that host the different components of the composite SaaS. The ones obtained from our approach SPP-CPSO generally consume less resources.
Fig. 15

Average machine usage percentage of the solutions produced by SPP-CPSO, GA, and FFD while increasing the number of SaaS components (AC and DC)

The quality of the solution is based on the two objectives, ETET and Machine usage. Calculation of the fitness uses the importance factors for those two objectives \({I_T}\) and \({I_U}\), respectively. The percentage of the gap between the obtained ETET and the SLA maximum response time (\(\hbox {SLA}_{\mathrm{mtrt}}\)) is used the same way in the previous set of experimental studies as shown in Eq. 21 in Sect. 6.1.

While increasing the number of SaaS components, we observe that SPP-CPSO outperforms the two other algorithms regarding the quality of solutions. The average fitnesses obtained from the three algorithms are shown in Fig. 16.
Fig. 16

Average quality of the solutions produced by SPP-CPSO, GA and FFD while increasing the number of SaaS components (AC and DC)

Figure 17 illustrates the computation time needed for the approaches to find the optimal solution. It can be seen that both SPP-CPSO an GA exhibit a linear growth over time while the FFD executes within [71...79] ms for all test problems. The FFD was the fastest algorithm. This pattern is different from (Fig. 12) obtained in the previous set of experiments on number of servers. The reason is that there is no sudden exponential growth in this set of experiments because the search space enlargement by increasing the number of components from 15 to 60 is not as important as adding 1000\(+\) servers like the previous set.
Fig. 17

The effect of the number of SaaS components on the computation time for SPP-CPSO, GA and FFD

7 Conclusion and future works

This paper focused on the SPP which is one of the resource management optimization problems in cloud computing environment. The objective of SPP is to optimize the performance of the SaaS based on its estimated execution time. A detailed mathematical formulation of the SPP was presented here and an approach based on PSO-CP was proposed to solve the SPP and find not only the placement of the software (or application) components of a SaaS, but the placement of data components of the composite SaaS as well. Another objective was considered here and it is related to the servers that will host the composite SaaS which is maintaining them with an acceptable performance by keeping the usage the machine’s resources (RAM and CPU) at a moderate level.

Experimental results have shown that PSO-CP is not only applicable to SPP but can produce good-quality solutions with an acceptable computation time. The proposed algorithm showed superiority over GA and FFD in terms of solution’s quality especially while searching for the optima in a large search space.

Several ideas of improvements of this work were identified throughout elaborating this research. First of all, improving the quality of the produced solutions, the computation time and the scalability of the algorithm should be in concern.

Reconfiguring a current placement even if it is optimal is something SaaS providers can do all the time due to the dynamic nature of the cloud environment (Yusoh 2013). For that, SaaS Clustering Problem (SCP) has emerged. It refers to reconfiguring the current placement of the SaaS components by clustering suitable components to be with each other in one VM such that the cluster and the new placement will minimize the migration costs and maintain the SaaS performance as well (Yusoh 2013). It should be interesting to investigate how PSO-CP is applied in SaaS clustering and how it will perform.

Finally, security risk is one of the most major obstacles that affects the acceptance of Cloud services. None of the existing SaaS placement approaches have considered security constraints and most attacks strongly depend on the placement strategies in the cloud. In order to minimize the overall security risks in a cloud data center, it is necessary to develop security-aware SaaS placement strategies in which SaaS components with high risks will be separated from SaaS with low risks. In the future, we will extend our proposed approach by evaluating the security risks of the SaaS components based on the sensitivity of data as well as the dependencies among these SaaS components. We also will compute the probability of exploitation of a host machine based on their offered security levels as well as the SaaS security requirement and their users preferences. The security score for each hosting machine will be inferred based on the risk of the hosted SaaS components and will be used to select the most secure server.

Footnotes

Notes

Compliance with ethical standards

Conflict of interest

The authors declare that they have no conflict of interest.

Ethical approval

This article does not contain any studies with human participants or animals performed by any of the authors.

References

  1. Bhardwaj S (2015) Service level agreement aware SaaS placement in cloud. Master’s thesis, National Institute of Technology Rourkela, India, May 2015. Supervised by: Bibhudatta SahooGoogle Scholar
  2. Bowen Y, Shaochun W (2012) An adaptive simulated annealing genetic algorithm for the data placement problem in SaaS. In: Industrial control and electronics engineering (ICICEE), 2012 international conference on. IEEE, pp 1037–1043Google Scholar
  3. Candan KS, Li W-S, Phan T, Zhou M (2011) At the frontiers of information and software as services. In: New Frontiers in information and software as services. Springer, pp 283–300Google Scholar
  4. Cisco (2008) Cisco service-oriented network architecture: support and optimize soa and web 2.0 applications. Technical report, Cisco IncGoogle Scholar
  5. Cisco (2015) IDC report, the new need for speed in the datacenter network. Technical report, Cisco Inc. Accessed 24 May 2016Google Scholar
  6. Huang K-C, Shen B-J (2015) Service deployment strategies for efficient execution of composite SaaS applications on cloud platform. J Syst Softw 107:127–141CrossRefGoogle Scholar
  7. Kichkaylo T, Ivan A, Karamcheti V (2003) Constrained component deployment in wide-area networks using AI planning techniques. In: Parallel and distributed processing symposium, 2003. Proceedings of the International. IEEEGoogle Scholar
  8. Kumar A (2014) Placement of software-as-a-service components in cloud computing environment. Master’s thesis, National Institute of Technology Rourkela, India, June 2014. Supervised by: Bibhudatta SahooGoogle Scholar
  9. Kwok T, Mohindra A (2008) Resource calculations with constraints, and placement of tenants and instances for multi-tenant saas applications. In: Service-oriented computing—ICSOC 2008. Springer, pp 633–648Google Scholar
  10. Liu L, Yang S, Wang D (2010) Particle swarm optimization with composite particles in dynamic environments. IEEE Trans Syst Man Cybern B Cybern 40(6):1634–1648CrossRefGoogle Scholar
  11. Liu Z, Hu Z, Jonepun LK (2014) Research on composite SaaS placement problem based on ant colony optimization algorithm with performance matching degree strategy. J Digit Inf Manag 12(4):225–234Google Scholar
  12. Lodi A, Martello S, Vigo D (2002) Heuristic algorithms for the three-dimensional bin packing problem. Eur J Oper Res 141(2):410–420MathSciNetCrossRefMATHGoogle Scholar
  13. Mell P, Timothy G (2011) The NIST definition of cloud computing. Technical report, National Institute of Standards and TechnologyGoogle Scholar
  14. Minas L, Ellison B (2015) The problem of power consumption in servers. Technical report, Intel Corporation. Accessed 08 June 2016Google Scholar
  15. Ni ZW, Pan XF, Wu ZJ (2012) An ant colony optimization for the composite saas placement problem in the cloud. In: Applied mechanics and materials, volume 130. Trans Tech Publications, Switzerland, pp 3062–3067Google Scholar
  16. RightScale I (2016) Rightscale 2016 state of the cloud report. Technical report, RightScale IncGoogle Scholar
  17. Rosendo M, Pozo A (2010) Applying a discrete particle swarm optimization algorithm to combinatorial problems. In: Neural Networks (SBRN), 2010 Eleventh Brazilian Symposium on. IEEE, pp 235–240Google Scholar
  18. Statista I (2016) Software as a service (SaaS) subscription revenue from 2012 to 2016 by category (in billion u.s. dollars). http://www.statista.com/statistics/468649/saas-software-subscription-revenue-by-category/. Accessed 22 March 2016
  19. Talbi E-G, Guzek M, Bouvry P (2015) A survey of evolutionary computation for resource management of processing in cloud computing [review article]. IEEE Comput Intell Mag 10(2):53–67CrossRefGoogle Scholar
  20. Tang M, Yusoh ZIM (2012) A parallel cooperative co-evolutionary genetic algorithm for the composite saas placement problem in cloud computing. In: Parallel Problem Solving from Nature-PPSN XII. Springer, pp 225–234Google Scholar
  21. Tang K, Yang J, Chen H, Gao S (2011) Improved genetic algorithm for nonlinear programming problems. J Syst Eng Electron 22(3):540–546CrossRefGoogle Scholar
  22. Urgaonkar B, Rosenberg A, Shenoy P (2004) Application placement on a cluster of servers. Int J Found Comput Sci 18:1023–1041MathSciNetCrossRefMATHGoogle Scholar
  23. Yang X, Yuan J, Yuan J, Mao H (2007) A modified particle swarm optimizer with dynamic adaptation. Appl Math Comput 189(2):1205–1213MathSciNetMATHGoogle Scholar
  24. Yusoh ZIM (2013) Composite SaaS resource management in cloud computing using evolutionary computation. PhD thesis, Science and Engineering Faculty Queensland University of Technology Brisbane, AustraliaGoogle Scholar
  25. Yusoh ZIM, Tang M (2010a) A penalty-based genetic algorithm for the composite SaaS placement problem in the cloud. In: Evolutionary Computation (CEC), 2010 IEEE Congress on. IEEE, pp 1–8Google Scholar
  26. Yusoh ZIM, Tang M (2010b) A cooperative coevolutionary algorithm for the composite saas placement problem in the cloud. In: Neural Information Processing. Theory and Algorithms. Springer, pp 618–625Google Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2017

Authors and Affiliations

  1. 1.Higher Institute of Management (ISG)TunisTunisia
  2. 2.Department of Computer ScienceJendouba UniversityJendoubaTunisia

Personalised recommendations