=Paper=
{{Paper
|id=Vol-1242/paper6
|storemode=property
|title=Towards Pattern-Based Optimization of Cloud Applications
|pdfUrl=https://ceur-ws.org/Vol-1242/paper6.pdf
|volume=Vol-1242
|dblpUrl=https://dblp.org/rec/conf/models/FleckTLW14
}}
==Towards Pattern-Based Optimization of Cloud Applications==
https://ceur-ws.org/Vol-1242/paper6.pdf
Towards Pattern-Based Optimization of
Cloud Applications?
Martin Fleck, Javier Troya, Philip Langer, and Manuel Wimmer
Vienna University of Technology, Business Informatics Group, Austria
{lastname}@big.tuwien.ac.at
Abstract. With the promise of seemingly unlimited resources and the flexible
pay-as-you-go business model, more and more applications are moving to the
cloud. However, to fully utilize the features offered by cloud providers, the exist-
ing applications need to be adapted accordingly. To support the developer in this
task, different cloud computing patterns have been proposed. Nevertheless, se-
lecting the most appropriate patterns and their configuration is still a major chal-
lenge. This is further complicated by the costs usually associated with deploying
and testing an application in the cloud.
In this paper, we encode the pattern selection problem as a model-based opti-
mization problem to automatically compute good solutions of configured pattern
applications. Particularly, we propose a two-phased approach, which is guided
by user-defined constraints on the non-functional properties of the application.
In the first phase, a preliminary set of promising solutions is computed using a
genetic algorithm. In the second phase, this set of solutions is evaluated in more
detail using model simulation. We demonstrate the proposed approach and show
its feasibility by an initial case study.
Keywords: Cloud Computing, Goal Modeling, Model Simulation, Genetic Al-
gorithm, Cloud Computing Patterns
1 Introduction
The seemingly unlimited resource offerings and the flexible pay-as-you-go business
model are, amongst others, the main driver of the adoption of the cloud computing
paradigm. As a result, many different cloud providers have emerged. This has also
sparked a major interest in the migration of existing applications to the cloud [17]. Be-
sides the cloud provider selection, adapting the application to make the best out of the
cloud provider offerings is often very challenging. Cloud computing patterns [6, 13, 18]
have been introduced as cloud provider-independent solutions to reoccurring problems
in cloud computing. Developers can use these patterns in their design decisions and op-
erationalize them in the context of a specific cloud provider. This step, however, requires
detailed insight of the software architecture, the cloud computing paradigm, the offer-
ings of specific cloud providers, and the usage of the given application. Furthermore,
the developers have to deal with a possibly infinite search space of pattern applications
and a solution has to satisfy multiple, probably conflicting, objectives [11].
?
This work is co-funded by the European Commission under the ICT Policy Support Pro-
gramme, grant no. 317859.
In this paper, we present a model-based approach aimed to support developers in
selecting the most appropriate cloud patterns and their configurations. Particularly, the
approach consists of two phases and is guided by user-defined constraints on the non-
functional properties of the application. In the first phase, a preliminary set of promising
solutions is computed using a multi-objective genetic algorithm which uses estimates
to determine the fitness of a solution due to the huge search space. In the second phase,
this set of solutions is evaluated in more detail using model simulation to better support
the final decision by the user, i.e., selecting the most appropriate solution.
The rest of the paper is organized as follows. In Section 2, we describe our proposed
approach as well as the necessary input from the stakeholders. Section 3 showcases the
applicability of our approach in a case study, while Section 4 discusses related work.
The paper concludes in Section 5 with an outlook on future work.
2 Approach
The central aim of our approach is to find a configuration of patterns that best satisfies
the needs of the application stakeholder, i.e., the reason why the application is moved to
the cloud in the first place.GoalsWe therefore provide the stakeholder with a goal modeling
language that is capable to express these needs in terms of non-functional properties
(NFPs). Based
Original
on theseEvolutionary
goals, we approach
Fine-grained
the pattern selection problem with two
Cloudified
subsequent steps, as shown
Application in Figure 1.Evaluation
Exploration In the first step, a multi-objective evolutionary
Application
algorithm is used to calculate a preliminary set of good solutions. A solution is a set of
configured cloud optimization patterns andCloud
NFP-Influence evaluated based on estimates on how certain
Estimates Patterns
patterns impact properties of the applications. In the second step, each solution returned
by the evolutionary algorithm is additionally ranked based on the more detailed analysis
performed by model simulation. The resulting ranked set of solutions together with their
approximated success to fulfill the goals is then presented to the stakeholders.
Cloudified
Cloudified Cloudified
Original Evolutionary Cloudified Fine-grained
Application
Application Application
Application Exploration Application Evaluation
[ranked]
NFP-Influence Cloud Pattern
Goals
Estimates Templates
Fig. 1. Approach Overview
2.1 Goal Modeling
Goal modeling originally stems from early phases of requirements engineering, where
a goal is an objective for the system from the perspective of a stakeholder. In the goal
modeling language we provide, the goals are based on a set of (non-functional) proper-
ties. More concretely, a goal defines a target value or target range for a specific property
in the context of the software application, e.g., the response time of a request or the
9
utilization of a specific component. These target values must be set in the range of the
property under consideration, e.g., utilization can only take floating point values be-
tween zero and one. Each goal must be set into the context of a specific workload or
usage scenario, as it is not feasible to show that a goal holds in all possible cases. Fur-
thermore, the importance of a goal is given by a numeric priority, whereby a smaller
Problem The same entities are Not all day-to-day user Not all user requests can be handled due to a lack of resources.
retrieved multiple requests can be handled However, the resource demand changes often resulting in low times
times from the due to a lack of resources. and high peaks.
database.
Effect The frequently- Deploy multiple instances Start with a certain number of nodes and dynamically adjust the
accessed entities are of one node to provide number depending on certain monitored properties, thus providing
stored in a Cache, more resources. more resources only if necessary.
improving the
retrieval of data
(reads).
Template
Caching Horizontal Scaling Auto-Scaling
Problem: The same entities Problem: Not all day-to-day Problem: Not all user requests Template:
are retrieved multiple times user requests can be handled can be handled due to a lack of
from the database. due to a lack of resources. resources. However, the Auto‐Scaling
resource demand changes often
Effect: The frequently- Effect: Deploy multiple Application: Service
resulting in low times and high
accessed entities are stored instances of one node/service MinInstances: Int[1, ∞]
peaks.
in a Cache, improving the to provide more resources.
MaxInstances: Int[1, ∞]
retrieval of data (reads). Effect: Start with a certain
Template: ScalingVariable: Variable[*]
Template: number of nodes and
Horizontal Scaling dynamically adjust the number ScaleInThreshold: Real[‐∞, ∞]
Cache depending on certain monitored ScaleOutThreshold: Real[‐∞, ∞]
Application: Service
properties, thus providing more
Application: Entity NrInstances: Int[2, ∞] resources only if necessary.
Fig. 2. Example Patterns and their Pattern Templates in a UML class-like notation
number indicates a higher priority. Summarizing, we consider goals to be Boolean con- 8
ditions concerning NFPs in the context of a software system under a specific workload
with a user-defined priority.
Example: The most important objective (priority 1) is that the average response time
of a log in-request is less than 2 seconds when ten users log in at the same time.
2.2 Cloud Computing Patterns
Cloud computing patterns provide a generic solution to a reoccuring problem in a spe-
cific context in the cloud computing domain and need to be concretized by the developer
when used. In the ARTIST project [1] we have collected over 30 of these cloud com-
puting patterns from different sources [6, 13, 18]. In this work we focus on patterns that
are applied in order to optimize the properties of an application that is to be deployed
on the cloud. We therefore assume that the base architecture of the application is al-
ready suitable for the cloud and no major architectural refactorings need to be done. To
use the informally described patterns in our approach, we translate them into so-called
pattern templates, which specify where the pattern can be applied and how it can be
configured. Figure 2 shows a small excerpt of the collected patterns and the resulting
pattern templates.
Caching can be applied on any entity class that is persisted in a datastore, while scal-
ing can be applied on any service class. In horizontal scaling, the number of instances of
a service is fixed from the beginning and can range from two instances to a theoretically
unlimited number of instances – in practice this number is limited by the specific cloud
provider. By contrast, auto-scaling provides a lower and upper bound on the number
of instances, and the actual number is adapted during the application runtime based on
the value of the ScalingVariable and the two variable-specific scaling thresholds. If the
value of the variable is less or equal than the specified ScaleInThreshold, one service
instance is removed; if the variable value is greater or equal than the ScaleOutThresh-
old, an additional instance is created. Any numerical variable which can be evaluated
during runtime can serve as auto-scaling variable, e.g., utilization.
When applying a cloud computing pattern in a concrete use case, we create an in-
stance of the respective pattern template, i.e., we provide concrete values for all the
parameters defined in the template. The set of the concrete values for a pattern is called
a pattern configuration. Each applied pattern configuration has an impact on the (non-
functional) properties of the system. This impact is usually specific to the software
system. Estimations about the gained impact on the properties may be gained from
more detailed pattern descriptions, experience, and cloud benchmarking services. An
example can be found in Table 1.
2.3 Evolutionary Algorithms
The aim of our approach is to select a sequence of pattern applications that satisfies the
goals modeled by the stakeholder. The pattern selection problem consists of a possibly
infinite search space of configurations and a solution has to satisfy multiple, probably
conflicting, objectives [11]. We therefore categorize our problem as a multi-objective
combinatorial optimization (MOCO) problem, for which several methods have been
discussed in the literature (cf. [5]). For our approach, we choose an evolutionary al-
gorithm for the pattern selection problem, namely the nondominated sorting genetic
algorithm II (NGSA-II) [4], guided by the estimated impact of a pattern on the NFPs.
Search Space. The search space consists of all possible patterns configurations as de-
fined by the pattern templates and may be infinite, e.g., when considering floating point
values. Therefore it is not possible to produce the complete search space in advance,
but rather generate new random configurations based on the templates, if necessary.
Solution Space. A genetic algorithm maintains a set of solutions, called a population,
and deploys selection, re-combination, and mutation operators to improve the quality of
the solutions in the population in each iteration. In our approach, a (candidate) solution
is a selected sequence of pattern configurations. To ensure the validity of candidate
solutions, solution constraints requiring domain knowledge about the different patterns
can be used to specify how configurations can be combined. As an example, it makes
no sense to apply both, horizontal scaling and auto-scaling, on the same service, thus a
constraint classifying such a solution as invalid may be specified. One drawback when
using NSGA-II is that the length of the solution (n) must be fixed in advance, i.e.,
the number of pattern configurations appearing in a solution. To allow the calculation
of solutions with less or equal than n pattern configurations, we introduce a pattern
configuration placeholder, which may take one or more places in the solution, but has
no influence on any of the NFPs.
Objective Space. To evaluate the quality (fitness) of a solution, the solution needs to
be mapped to the objective space. In multi-objective optimization, this objective space
consists of multiple dimensions, each dimension referring to one objective. Usually
these objectives are competing, so that no single point in the objective space exists
that dominates all other points, resulting in a set of optimal solutions. In our approach,
the objective space is not pre-defined, but specified by the stakeholder implicitly by
defining the goals. Each property that has a goal specified upon is one dimension in the
objective space that needs to be evaluated. The evaluation of a solution candidate for
each of these dimensions in the objective space is done by a so-called fitness function.
This fitness function guides the algorithm into good areas of the solution space.
Fitness. We define the fitness of a solution in a specific dimension to be the sum of
the weighted, relative distance between the property value resulting from applying the
solution and the target value or target range set by the user for each goal of this property.
The relative distance of a goal is the difference between the resulting property value and
the user-defined target value or target range in relation to the target value or range. For
target ranges, the mean of the range is taken as target value, however a fulfilled goal
always results in a relative distance of zero. An additional penalty (weight) for each
goal that has not been achieved is calculated by multiplying the relative distance with
the proportional goal priority, resulting in a higher penalty for higher priority goals. The
goal of the algorithm is to find a solution that minimizes the fitness values.
2.4 Model Simulation
Running NSGA-II gives us a set of solutions which form the Pareto front from the pre-
viously infinite solution space. These solutions can be evaluated in more detail using the
more execution expensive, but also more precise, model simulation. For this, we build
on our previous work [16] that is based on graph transformations supported by the e-
Motions framework [15]. By using e-Motions, we run the modeled system and perform
a more detailed evaluation also considering additional properties such as the contention
of resources. The results from the model simulation are used to rank the solution set
calculated by NSGA-II. The ranked solution set together with the approximate success
of each solution to fulfill the goals is then presented to the stakeholders for the final
decision about which configurations of the cloud computing patterns should be applied.
3 The Petstore Case Study
In this paper, we show the applicability and feasibility of our approach based on the Pet-
store case study. The case study is executed with the Java prototype we have developed
using the NSGA-II implementation provided by the MOEA Framework1 . The Petstore
is a small web application allowing potential customers to create an account, log into
this account, and order pets from a pre-defined pet catalogue. Previously the Petstore
has been running on the local web server of the company, however now the company
wants to move the Petstore application to the cloud to improve scalability and reduce
cost. The Petstore architecture is realized with three entity classes and five services.
Entity Classes. The Petstore application maintains three entity classes, namely Item,
Customer, and Order. All products in the Petstore are stored in the form of an item
entity. Customers can create an account at the Petstore, log in, search for items, and
place orders. An order consists of the registered contact information of a customer as
well as the items and the quantity the customer has put into the shopping cart. Available
service functionality is depicted in Figure 3, as explained later.
Services. Internally the Petstore uses different services to provide the necessary func-
tionality to customers. The Application Service is the only service that a customer di-
rectly interacts with. It uses the Customer Service, Catalog Service and Order Service
to handle the customer data, item data, and order data, respectively. All of these three
services use the Entity Service to handle the persistence and the retrieval of data from a
permanent data store.
3.1 Setup
Patterns. For this case study, we select the three patterns already introduced in Sec-
tion 2.2: Caching, Horizontal Scaling, and Auto-Scaling. Considering the application
conditions, caching can be applied on any of the three entity classes, while scaling can
be applied on any of the five service classes. We assume that both scaling patterns im-
prove performance (the more instances, the faster they process data) and worsen cost
(each instance is billed by the cloud provider). Estimations about the gained speedup or
utilization can be partially retrieved from a more detailed pattern description, but can
also be gained from experience or dedicated cloud benchmarking services. Pricing in-
formation can be gathered from the website of the specific cloud provider. The resulting
estimated impact for each pattern is summarized in Table 1.
1
MOEA Framework, Version 2.1: http://moeaframework.org/
sd BuyItemWorkload(open(5000ms))
«Service» «Service» «Service» «Service» «Service»
: Client : ApplicationService : CustomerService : CatalogService : OrderService : EntityService
login(login, pw)
login(login, pw)
findAllCustomers()
customer = customer = findAllCustomers()
id =
login(login, pw)
login(login, pw)
findItem(name) findItem(name)
findAllItems()
item = allItems = findAllItems()
item = findItem(name)
findItem(name)
addItemToCart
(id, item) addItemToCart(customer, item) persist(cart)
confirmOrder(id)
confirmOrder(customer) persist(order)
Caching Price per TimeUnit Fig. 3. The Petstore0.0015
Scenario Workload
SpeedUp Item 5.0000
Furthermore,SpeedUpweCustomer
define application constraints
3.0000 to guarantee that a pattern is not ap-
plied on theSpeedUp
same entity
Order or service multiple times and that the two scaling patterns are
1.0000
Price per TimeUnit and Auto‐Scaling
ScalingCache service instances 0.0010 «Cache» «Service»
not applied on the same service at the same time. «Service» «AutoScaling»
Application: EntityClass Application: Service { MinInstances
= 3,
MyEntity
MinInstances: Int[1, ∞] MaxInstances = 7,
Table 1. Estimated
MaxInstances: Int[1, ∞] impact of considered patterns
ScalingVariable= Utilization,
Horizontal Scaling «HorizontalScaling»
ScalingVariable: Variable[*] ScaleInThreshold = 3,
Caching Impact { NrInstances = Scaling
3 } Impact
Application: Service ScaleOutThreshold = 7 }
ScaleInThreshold: Real[‐∞, ∞] «Service»
Price
NrInstances: per TimeUnit
Int[2, ∞] SpeedUp SpeedUp
ScaleOutThreshold: Real[‐∞, SpeedUp
∞] Price per TimeUnit SpeedUp
MyOtherService
MyService
Item Customer Order and service instances n Instances
0.0015 5 3 1 0.0010 n
6
Goals. As mentioned in the previous section, all goals must be set in the context of a
specific workload, as it is not feasible to show that certain goals hold in all possible use
cases. For this case study, we consider a scenario where a single user connects to the
Petstore application, logs into his or her account, searches for a specific item by name
and then places an order on this item. Ten requests arrive in the application (modeling
the connection of ten users) with an exponential distribution of five seconds (5000 time
Pattern Problem Effect Impact Auto‐Scaling
units). Caching
The scenario is summarized in Figure
The same entities are retrieved
3 with a sequence diagram. The main
The frequently-accessed entities are stored Price per TimeUnit 0.0015 Application: Service
reason for moving thetimes
multiple Petstore application to
from the database. in a the cloud
Cache, is tothereduce
improving cost
retrieval of data and improve
SpeedUp Item 5.0000
(reads). MinInstances: Int[1, ∞]
scalability, or more precisely, to reduce the overall cost and improve the response SpeedUptime
Customer 3.0000 MaxInstances: Int[1, ∞]
of customer requests and the utilization of different services. Cost and responseSpeedUp time are
Order 1.0000 ScalingVariable: Variab
both properties which
Horizontal Not can have
all day-to-day uservalues
requests in
canthe Deploy of [0.0,
rangemultiple ∞], with
instances of one a lower
node to value being ScaleInThreshold: Real[
Scaling be handled due to a lack of resources. provide more resources. ScaleOutThreshold: Real
considered better than a higher value. Utilization has a value range of [0.0,Price 1.0]perwith
TimeUnit
Auto- Not all user requests can be handled Start with a certain number of nodes and and service 0.0010
neitherScaling
lower values
due to anor higher
lack of values
resources. beingdynamically
However, clearly adjust
better,
the making utilization
number depending suitable
instances
the resource demand changes often on certain monitored properties, thus
for a target range instead of a single target value. Too low utilization can suggest an idle
resulting in low times and high peaks. providing more resources only if necessary.
resource, which produces cost and brings no benefit. Too high utilization can indicate an
overloaded resource, Cache resulting in a slower performance or a situation where consumers
c1 = Cache(Item)
c2 = Cache(Order)
of the application
Application: are not served.
EntityClass
h1 = HorizontalScaling(Orderservice, 2)
In this case study we assume that the following goals should be fulfilled within
h2 = HorizontalScaling(EntityService, 4)
the contextHorizontal Scaling scenario. The application of a property
of the Petstore is indicated by the
a1 = AutoScaling(CustomerService, 3, 6,
Utilization, 0.6, 0.9)
property name andService
Application: the applied element in parenthesis, an asterisk ... *
( ) marks the whole
NrInstances: Int[2, ∞]
application. The priority of a goal is given in square brackets after the condition.
Goal 1: Cost(*) <= 900 [3]
Goal 2: ResponseTimePerRequest(*) <= 30000 [2]
Goal 3: 0.15 <= Utilization(EntityService) <= 0.25 [1]
Goal 4: 0.15 <= Utilization(CustomerService) <= 0.25 [3]
NSGA-II Configuration. As mentioned in the previous section, genetic algorithms
use selection, re-combination, and mutation operators to evolve the population into a
good area of the solution and thus objective space. For selecting candidate solutions,
we use a so-called tournament selection strategy, which takes n random candidate so-
lutions from the population and allows the best one to be considered for re-combination
(in our case, n = 4). Two candidate solutions are re-combined into two new candi-
date solutions by means of a single point crossover operator. This operator splits each
solution at a random point into two parts and merges the first part of the first solution
with the second part of the second solution and vice versa. After re-combination the
validity of the resulting solutions is checked and mutation can take place. Invalid so-
lutions are given the worst possible fitness and should eventually be removed from the
population. Mutation occurs at a low rate (1.5%) in a solution and changes one of the
pattern configurations concrete values slightly. In our case, this means that each param-
eter of a pattern configuration has a slight chance of being modified, e.g., the number
of instances for horizontal scaling. Furthermore, we define a solution length of eight, as
there are only eight classes on which at most one pattern can be applied. The algorithm
should maintain 200 solutions per population and continue for at most 1000 iterations.
Fitness Function. To evaluate the quality of the solutions produced by the NSGA-II,
we need to provide values for response time, cost and utilization by incorporating the
impact estimations. As the fitness function is executed many times, we use a very simple
model analysis technique, which may not be very precise, but is very fast to execute.
First, we retrieve the configured number of instances for each of the services. Then
we execute the scenario for all requests and services and calculate the runtime of each
service by summing up the reduced execution times (original execution time divided by
number of instances) of each operation call that has been made to this service during the
execution. The sum of all operation executions is the total runtime of the application.
Each request is seen as independent and no contention of resources is considered. Based
on the runtime, we calculate both the utilization and the cost for each service using the
provided pricing and speedup information. The resulting response time for each request
is the total runtime divided by the number of requests.
3.2 Results
After running the NSGA-II algorithm, we are faced with 3 solutions, one of which is
depicted in Figure 4. On this set of solutions, we run the model simulation as described
in Section 2.4 to gain more detailed information about how close the solutions are to
fulfilling the goals set by the user. For this, we need to define a metamodel and be-
havioral in-place rules that model the system at runtime. For each solution, an instance
of this metamodel containing the applied patterns must be created and executed. The
result of the model simulation is shown in Table 2. The first line presents the original
configuration (no patterns applied), while the other three have some patterns applied.
The left-hand side of the table shows the values for the NFPs of interest, while the mid-
dle part shows the distance to each goal, and the right-hand side displays the overall
distance to the goals and the rank of the solutions.
Regarding the solutions, (1) and (2) use four patterns, while (3) uses three. Solution
(1) auto-scales the Entity Service and the Application Service depending on the queue
length. The first service ranges between 3 and 7 instances, while the second one does
«Service»
«Service» «AutoScaling»
«Entity»
«HorizontalScaling» { MinInstances = 2, MaxInstances = 4,
«Cache» «PlaceHolder» ...
{ NrInstances = 4 } ScalingVariable = QueueLength,
Item ScaleInThreshold = 3, ScaleOutThreshold = 7 }
EntityService
CustomerService
«Service»
«Service» «AutoScaling»
«Entity»
«HorizontalScaling» { MinInstances = 2, MaxInstances = 4,
«Cache» «PlaceHolder» ...
{ NrInstances = 4 } ScalingVariable = QueueLength,
Item ScaleInThreshold = 3, ScaleOutThreshold = 7 }
EntityService
CustomerService
6
Fig. 4. Solution (3) with pattern configurations and placeholders
between 1 and 4. Solution (1) also has horizontal scaling for Customer Service and Or-
der Service, with two instances for each one. Solution (2) auto-scales the Order Service
depending on the queue length between 1 and 4 instances, and it also applies horizontal
scaling in the Entity Service and Customer Service, with 4 and 3 instances, respectively.
Caching on Item is applied as well. Finally, Solution (3), also depicted in Figure 4,
applies caching on Item and horizontal scaling for Entity Service with 4 instances. It
auto-scales the Customer Service between 2 and 4 instances depending on the queue
length.
Table 2. The Petstore Scenario Workload Results
# Cost RespT Util ES Util CS G1 G2 G3 G4 Sum Rank
B 921 134500 0.95 0.217 0.024 5.225 7.5 0 12.749 ‐
(1) 935 29018 0.176 0.257 0.039 0 0 0.284 0.322 3
(2) 992 31698 0.215 0.168 0.102 0.085 0 0 0.187 1
(3) 948 32845 0.243 0.187 0.053 0.142 0 0 0.196 2
While we have a clear ranking according to the model simulation and the calculated
distances, we still provide the user with all possible solutions and their detailed eval-
uation values to allow additional human reasoning. A user could still decide to apply
solution (1) instead of the other solutions if she wanted the utilization of the Entity Ser-
vice to be closer to the smallest target value or she could also decide to apply solution
(3) instead of solution (2), because cost may still be the driving factor of the migration.
Despite the ranking, we can note that none of the solutions is surprising and they prob-
ably could have been found by an expert using the estimated impact on the patterns and
the knowledge about the system execution. However, we assume that with a more com-
plex application and a higher number of goals and/or patterns, the manual derivation of
solutions becomes harder.
4 Related Work
In software engineering, patterns are important ingredients to document knowledge on
how to solve reocurring problems since the well-known book by the Gang of Four [9]
describing patterns in the context of object-oriented design. With the appearance of the
cloud computing paradigm, the community has already started working on cloud com-
puting patterns [6, 13, 18]. For our approach, we studied different pattern descriptions,
created pattern templates, and estimated the effect of each pattern on the different NFPs.
Optimization techniques are used to solve a variety of different problems [3]. Re-
search in metaheuristics for combinatorial optimization problems aims to optimize
the techniques applied in evolutionary algorithms [19]. At the same time, the focus
of research has shifted from being rather algorithm-oriented to being more problem-
oriented [2]. This is also reflected in the emerging search-based software engineering
paradigm [10, 12], which considers cloud computing as one of its application fields to
tackle several multi-objective optimization problems [11]. Furthermore, the combina-
tion of model-driven engineering with search-based techniques is also investigated in
several studies [14]. Following this path, we have applied a specific genetic algorithm
to our optimization problem. To the best of our knowledge, there is only one prior
work that applies optimization techniques to come up with an optimal configuration of
a cloud application. In [8], the authors also use a combination of multi-objective search
and simulation for finding an optimal deployment strategy for a given set of compo-
nents of an application. In our approach, we go one step further and aim to optimize not
only the deployment of the components, but also the usage of cloud computing patterns
that are applicable on class-level granularity, what is of major interest when moving to
PaaS providers.
An orthogonal optimization of cloud applications is targeted in the MODAClouds2
and Passage3 projects, where the multi-cloud deployment of applications is studied by
the application of the models@runtime notion [7]. Our approach currently does not
foresee any support for the multi-cloud deployments, but may be extended by additional
patterns supporting such scenarios as well in the future.
5 Conclusions and Future Work
In this paper we have introduced a pattern-based optimization approach for cloud appli-
cations. We follow a model-based approach to select configurations of cloud optimiza-
tion patterns that satisfy some restrictions in terms of non-functional properties, and we
determine the best configuration using model simulation.
Currently, our approach faces some limitations, some of which we want to address
in the future. First of all, we have assumed that the base architecture is suitable for
the cloud. This might not be the case for all applications and additional architectural
refactoring patterns may be applied before our approach. Also, the simulation of the
results through e-Motions is not straightforward as we need to create a new meta-model
for each system the approach is applied upon. Furthermore, e-Motions presents some
scalability issues when the models to be simulated grow in size. Other simulation tools
might not have these drawbacks and might be more easy to use. For now, we have not
evaluated the scalability of our approach in detail. More use cases, also industrial-sized
use cases, need to be evaluated to experiment with more complex patterns as well as a
larger number of patterns, goals, and trade-offs involved. Regarding the input, we need
initial estimates on the impact a pattern has on an application. It may prove difficult to
get these estimates manually from experts. Automation support based on benchmarks,
partial application execution or log analysis could be integrated to support the user in
collecting the estimates.
In the paper we have presented a proof-of-concept of our approach, from which we
will address several future lines of work next. Firstly, we will apply benchmarks to mea-
sure the improvement associated with optimization patterns in large-scale applications
provided as use cases in the ARTIST project. Secondly, we also plan to consider more
optimization patterns from our catalogue, as well as study their influence after the ap-
2
MODAClouds: http://www.modaclouds.eu/
3
Passage: http://www.paasage.eu
plication is deployed on the cloud. This would allow us to evaluate the feasibility and
scalability of our approach in a more realistic setting. Thirdly, we plan to extend our
goal modeling language to represent NFPs that are not taken into account in the current
version, such as security properties. Finally, we plan to further study the application
of different evolutionary algorithms for selecting the best configuration of optimization
patterns.
References
1. Bergmayr, A., Brunelière, H., Canovas Izquierdo, J.L., Gorronogoitia, J., Kousiouris, G.,
Kyriazis, D., Langer, P., Menychtas, A., Orue-Echevarria, L., Pezuela, C., Wimmer, M.: Mi-
grating Legacy Software to the Cloud with ARTIST. In: Proc. of CSMR. pp. 465–468 (2013)
2. Blum, C., Puchinger, J., Raidl, G.R., Roli, A.: Hybrid metaheuristics in combinatorial opti-
mization: A survey. Applied Soft Computing 11(6), 4135–4151 (2011)
3. Coello, C.A.C.: A Comprehensive Survey of Evolutionary-Based Multiobjective Optimiza-
tion Techniques. Knowl. Inf. Syst. 1(3), 129–156 (1999)
4. Deb, K., Pratap, A., Agarwal, S., Meyarivan, T.: A Fast and Elitist Multiobjective Genetic
Algorithm: NSGA-II. Trans. Evol. Comp 6(2), 182–197 (2002)
5. Ehrgott, M., Gandibleux, X.: A survey and annotated bibliography of multiobjective combi-
natorial optimization. OR-Spektrum 22(4), 425–460 (2000)
6. Fehling, C., Leymann, F., Retter, R., Schupeck, W., Arbitter, P.: Cloud Computing Patterns:
Fundamentals to Design, Build, and Manage Cloud Applications. Springer (2014)
7. Ferry, N., Rossini, A., Chauvel, F., Morin, B., Solberg, A.: Towards Model-Driven Provision-
ing, Deployment, Monitoring, and Adaptation of Multi-cloud Systems. In: Proc. of CLOUD.
pp. 887–894 (2013)
8. Frey, S., Fittkau, F., Hasselbring, W.: Search-based genetic optimization for deployment and
reconfiguration of software in the cloud. In: Proc. of ICSE. pp. 512–521 (2013)
9. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable
Object-Oriented Software. Addison-Wesley Professional, 1 edn. (1994)
10. Harman, M.: The current state and future of search based software engineering. In: Proc. of
ICSE. pp. 342–357 (2007)
11. Harman, M., Lakhotia, K., Singer, J., White, D.R., Yoo, S.: Cloud engineering is search
based software engineering too. Journal of Systems and Software 86(9), 2225–2241 (2013)
12. Harman, M., Mansouri, S.A., Zhang, Y.: Search-based software engineering: Trends, tech-
niques and applications. ACM Comput. Surv. 45(1), 11:1–11:61 (2012)
13. Homer, A., Sharp, J., Brader, L., Narumoto, M., T., S.: Cloud Design Patterns: Prescriptive
Architecture Guidance for Cloud Applications. Microsoft Patterns & Practices (2014)
14. Kessentini, M., Langer, P., Wimmer, M.: Searching models, modeling search: On the syner-
gies of SBSE and MDE. In: Proc. of CMSBSE@ICSE. pp. 51–54 (2013)
15. Rivera, J., Duran, F., Vallecillo, A.: A graphical approach for modeling time-dependent be-
havior of DSLs. In: Proc. of VL/HCC. pp. 51–55 (2009)
16. Troya, J., Vallecillo, A., Duran, F., Zschaler, S.: Model-driven performance analysis of rule-
based domain specific visual models. Inf. and Soft. Technology 55(1), 88–110 (2013)
17. West, D.M.: Saving Money Through Cloud Computing. Brookings Institution (2010)
18. Wilder, B.: Cloud Architecture Patterns. O’Reilly (2012)
19. Zitzler, E., Deb, K., Thiele, L.: Comparison of Multiobjective Evolutionary Algorithms: Em-
pirical Results. Evolutionary Computation 8, 173–195 (2000)