In this chapter, we described the background and definitions for cloud autoscaling, self- aware and self-adaptive systems in general. Subsequently, we outlined the major re- quirements for the key logical aspects of autoscaling in the cloud, and discuss the key state-of-the-art developments proposed for each of the logical aspects. Furthermore, we explicitly discussed the differences of this thesis to the related work and identified the gap in this area of research.
In the next chapter, we propose a self-aware architecture for autoscaling in the cloud, which is enabled and driven by mapping the necessary components to different levels of self-awareness capabilities.
Chapter 3
An Architecture for Self-Aware
and Self-Adaptive Autoscaling in
Cloud
3.1
Introduction
Engineering and design autoscaling system in the cloud is a complex process due to the dynamic and uncertain nature of cloud environment. As discussed in Chapter 2, most of the prior work e.g., [141] [23], tend to be limited in one or more logical aspects of the autoscaling process. This can be attribute to the fact that their approaches, especially their architectures, lack to capture the necessary knowledge for optimising the QoS and cost objectives of all cloud-based services. These knowledge can be well-represented and acquired through self-awareness at runtime, and thus render self-awareness as a neat solution to overcome the limitation in existing work.
The autoscaling architecture, being the skeleton of an autoscaling system, is a fun- damental element that blueprints the necessary components and their interactions. We argue that incorporating the principles of self-awareness at the architecture level is likely
to advance the way we engineer self-aware and self-adaptive autoscaling system.
3.1.1
Motivation
Given the definition of autoscaling presented in Chapter 1 and our discussion in Chapter 2, it is clear that autoscaling systems are essentially self-adaptive systems. One general task for architecting self-adaptive systems is to determine what is the necessary knowledge that the system maintains, and how the knowledge can be acquired. Designing autoscal- ing system in the cloud is not an exception. As mentioned in Chapter 2, the inadequacy of necessary knowledge can resulted in various limitations of the system. This includes, for examples, the absence of accurate QoS models causing the system not be able to reason about the likely effects of adaptation and the possible trade-offs; or ignoring QoS interference can degrade the effectiveness of the autoscaling. The difficulty lies in how to classify the necessary knowledge of an autoscaling system and more importantly, how to acquire such knowledge and how they can improve the adaptation. As we mentioned in Chapter 1, given the heterogeneous, elastic and on-demand nature of cloud, autoscaling in the cloud exhibits high dynamics and uncertainty related to QoS modelling, granularity of control and the trade-off decision making. These unique problems are within the scope of self-awareness principle and its capabilities [18], and hence rending it as a promising solution for autoscaling in the cloud. However, the challenge now becomes how to in- corporate and map the principles of self-awareness to autoscaling in the cloud, how the architecture can be enriched and how we can carefully justified benefits of self-awareness capabilities.
As we have extensively surveyed in Chapter 2, existing autoscaling architectures have heavily relied on traditional styles (e.g., MAPE [84] and OAD [74] based) for self-adaptive systems, which are focus mainly on the interactions among different logical aspects of a system and their degree of centralisation. However, these architecture styles lack in cap-
turing different levels of knowledge in a fine-grained representation. In particular, the widely adopted MAPE style in autoscaling architecture only model the knowledge in a coarse grained manner. Therefore, the MAPE is only capable to implicitly consider the self-awareness of the knowledge that the system requires. From an architecture perspec- tive, this is not immediately intuitive to deduce which concerns the system addresses in the adaptation. OAD is another style that claimed to be self-aware, however, instead of explicitly model different levels of knowledge, it emphases on a separation or decoupling between the representation of the knowledge and the decision making process. Autoscaling architecture based on feedback loop control that embedded with computational intelli- gence or control theory techniques are also exist, e.g., [141]. Nevertheless,they either do not consider self-awareness and how it can be used to strength the adaptation or such con- sideration is implicit. In addition, they are problem specific and do not model the generic concern of knowledge, e.g., with respect to goal, time and interaction. The absence of fine-grained representation of knowledge in the architecture can mislead the design and application of the underlying computational intelligence and/or economic driven tech- niques. As a result, all those limitations call for novel autoscaling architecture, which should encapsulate fine-grained information about what levels of knowledge are required; how they can be acquired and how they can be beneficial for the adaptation.
3.1.2
Contributions
In this chapter, we present an autoscaling architecture leverages on the principles of self- awareness and its mapping to various self-awareness capabilities. By doing so, we obtain an enriched architecture with detailed information about what are the necessary levels of knowledge and their interplay. These levels of knowledge and their interplay promotes better self-adaptivity through bi-directional adaptation in the architecture, in which the autoscaling process is not only able to adapt the underlying cloud-based services and
Figure 3.1: The Components of Autoscaling Architecture.
VMs, but also capable to further consolidate itself by acquiring the knowledge about itself and the environment. It is worth noting that we only focus on high level view of the architecture in this chapter, the details of each component in the architecture and the related algorithms will be explained in the subsequent chapters.