Cloud elasticity is a unique feature of cloud environments, which allows for the on demand (de-)provisioning or reconfiguration of the resources of cloud deployments. The efficient handling of cloud elasticity is a challenge that attracts the interest of the research community. This work constitutes a survey of research efforts towards this direction. The main contribution of this work is an up-to-date review of the latest elasticity handling approaches and a detailed classification scheme, focusing on the elasticity decision making techniques. Finally, we discuss various research challenges and directions of further research, regarding all phases of cloud elasticity, which can be deemed as a special case of autonomic behavior of computing systems (This research has been co-financed by the European Union (European Social Fund - ESF) and Greek national funds through the Operational Program “Education and Lifelong Learning of the National Strategic Reference Framework (NSRF) - Research Funding Program: Thales. Investing in knowledge society through the European Social Fund.
Cloud computing forms a deployment model, which aims to reduce the momentary cost of the computing resources through the leasing of dynamically adjusted virtual resources, which can be occupied on-demand. Virtual resources are virtual versions of actual resources, most commonly in the form of Virtual Machines (VMs), which leverage the virtualization technology . The offered pay-as-yougo pricing model accompanied by the elastic resource handling, has assisted the wide adoption of the cloud deployments, as the client is obliged to pay only for the used resource. As such, cloud computing has managed to make the provision of remote computing resources (e.g., VMs) the main option not only for scientific institutions but any size of organizations and enterprises. However, the efficient resource handling is a key aspect to the deployment cost reduction.
There are numerous works that propose various cloud elasticity handling mechanisms. In this work, our focus is on all aspects of elasticity, but we particularly aim to shed light on the decision making mechanisms in relation with the underlying models employed. Additionally, through our taxonomy, we aim to render the various techniques, which nowadays tend to be developed in isolation, more comparable with each other.
We regard elasticity techniques as an interdisciplinary field of two main areas: distributed/cloud computing and autonomic computing. As a field of autonomic computing, it comprises all four phases of the MAPE loop , namely Monitoring, Analysis, Planning and Execution. Each distinct phase presents unique research challenges, which are addressed by the presented works with various approaches. In this work, we mostly focus on the last three phases.
Some efforts to create an overview of the cloud elasticity area have been made in the past, for example  is complementary to our work, but it focuses more on the tools, the benchmarks and the workloads. We present elasticity strategies in a more broader fashion as we elaborate more on the elasticity decision mechanism.  is also complementary to our work, but we present more up-to-date proposals and cover a more extended range of elasticity actions and objectives. An older and narrower survey has also appeared in . A general systematic review about commercial cloud services is conducted in , where the authors present the main challenges regarding the elasticity property. As such, our work fills an important gap on a timely issue.
The structure of this survey paper is as follows. In Sect. 2, we present the taxonomy and the classification table. In Sect. 3, we delve into more details for each classification dimension of our taxonomy and we outline the main findings. We conclude in Sect.
2 Taxonomy and Classification
In order to provide a concise classification of the existing approaches to cloud elasticity, we first propose a taxonomy that will enable our work to shed light on the differentiating aspects of the various proposals. The taxonomy is summarized in Fig. 1 and consists of the following dimensions:
– Scope. This aspect is divided into two classification categories (i) the Enactor and the (ii) Application Type. The former indicates whether the elastic technique is applied by the cloud infrastructure provider (Cloud Provider (CP)) or the user of the cloud infrastructure, who deploys and manages cloud applications on top of the cloud infrastructure (Service Provider (SP)). Application Type indicates whether the proposal refers to the elastic handling of a particular type of cloud application from the following list: relational databases (DBs), NoSQL databases (NoSQL DBs), Multi-tier Applications (e.g., typical business web applications), Generic (if the tool is application-agnostic) or Storage.
– Purpose. In this dimension, we classify the techniques according to the purpose of elasticity actions. The purpose can be one of the following: (i) Performance, (ii) Availability, (iii) Cost, (iv) Energy. Performance, refers to the maintenance or guarantee of acceptable, either user or Service Level Agreement (SLA) specified, application performance. Availability refers to the degree to which applications and resources are in an operable and committable state at the time point when they are needed by end users . Cost refers either to the reduction of the operational cost of the application deployed in the cloud, commonly also maintaining the Performance goal, or to the maintenance of cost thresholds under specific performance constraints. Finally, the Energy category, is closely related to the Cost one but covers elastic techniques, which directly aim at minimizing the energy footprint.
– Decision Making. There are four distinct categorization criteria that characterize the decision making procedure of every work in our taxonomy, namely (i) Trigger, which indicates whether the elasticity mechanism is triggered in a reactive or proactive manner; (ii) Mechanism, which refers to the decision making methodology; (iii) Prediction Model (PM), which denotes the utilization of a model to predict future incoming load variations or specific measurement values; and (iv) System Model (SM), which refers to the utilization of a model to represent the (elastic) behavior of the system, on top of which the complete elasticity policy is built (e.g., queues). Elasticity mechanisms are further classified into the following categories: (1) Rule Based, (2) Mathematical/Statistical Optimization, (3) Machine Learning, (4) Control Theory and (5) Model Checking according to the main field to which the elasticity policy belongs.
– Elastic Action. Cloud resource elasticity may be applied in different forms and can refer to modifications in (i) the size (Vertical Scaling (VS)), (ii) the location (VM Live Migration (VMLM)) or (iii) the number of VMs employed (Horizontal Scaling (HS)). Examples of these three elasticity types are the allocation of more memory or CPU to a VM, moving a VM to a less loaded physical machine and increasing the number of VMs of an application cluster, respectively. Elastic Action additionally includes two other elasticity types, (iv) the Application Reconfiguration (AR), where the elastic tool is capable of handling specific application aspects (e.g., DB cache size) and (v) Application Live Migration (ALM), where only application-specific components are migrated instead of the full VM, such as database instances.
– Provider. This classification category refers to the number of cloud infrastructure providers that the elastic tool supports simultaneously. The possible values are (i) Single, which denote that only one cloud provider is supported, (ii) Single*, which denotes that more than one providers are supported, however not simultaneously and (iii) multiple, where the elasticity control is spread across multiple cloud providers simultaneously.
– Evaluation. Finally, the last aspect refers to the type of the Evaluation of every work. The possible values are: (i) Simulation, where the results are obtained based on computations on a simulated artificial environment (e.g., OMNeT++), (ii) Emulation where the evaluations results are obtained in an artificial environment that behaves according to real-world traces, and (iii) Real, where the elastic tool is applied on a real cloud infrastructure.
Based on the taxonomy above, we classify the existing proposals for cloud elasticity as shown in Table 1. The taxonomy above does not cover the type of the feedback information collected by the environment to drive the elasticity decision making and enforcement, because the type of the feedback seems to play a less important role in classifying the proposals. More specifically, all proposals utilize a mechanism to monitor specific system/network/application-specific metrics to assist the decision making. To deal with possible load spikes or measurement instabilities, many works utilize smoothing techniques like Exponential Weighted Moving Average (EWMA), Exponential Moving Average (EMA) or just Moving Average (MA). Further details are omitted due to space constraints.