Mapping Self-Awareness in Decision Maker

Once the QoS models and regions are defined, we are faced with trade-offs when au- toscaling in the cloud. In the Decision Maker, we take a multi-objective representation to model the trade-offs of QoS and cost objectives for different cloud-based services, and the problem is resolved by a self-aware and self-adaptive process. At this level, ’self’ refers to the decision making process in the autoscaling. Self-awareness here is concerned with knowing how the decision making can be affected by :

• QoS and cost models, as well as their requirements - Goal-awareness.

• regions of objectives, which represent the positive, negative or zero interaction be- tween objectives during decision making - Interaction-awareness.

Obtaining these levels of knowledge mean that the decision making process is capable to self-adapts its behaviour in the search for better trade-offs decisions. Specifically, self- awareness assists the decision making process in extensively reasoning about the effects of autoscaling decisions on goals and the possible trade-offs. By leveraging on modern search based algorithms, the reasoning serves as a strong assurance about the quality of

autoscaling, especially when the search space is incredibly large (i.e., too many combi- nations of software configurations and hardware resource provisions), which cannot be handled by human decision maker. More importantly, the knowledge acquired from self- awareness helps the process to self-adapt its own search behaviour for better optimality and diversity, e.g., exploring more on the decisions that contain high CPU allocations and more beneficial for certain goals. This permits the Decision Maker to handle com- plex trade-offs even without prior preferences, i.e., achieving well-compromised trade-offs, which largely improving majority of the goals while causing relatively small degradations on others. Given that the regions are dependent to each others, we only make decisions for the regions containing the objectives whose requirement violations have been detected. process is needed.

3.5

Conclusion

As cloud computing continuous to evolve, autoscaling requires novel principles and ap- proaches to seamlessly manage the underlying cloud-based services. Self-awareness pro- vides highly promising avenue for improving self-adaptivity and the effectiveness of au- toscaling in the cloud. In this chapter, we describe the autoscaling architecture and its mapping to self-awareness capabilities and the related pattern. We focus on discussing how the principle of self-awareness can be beneficial for various logical aspects in autoscal- ing, including QoS modelling, identifying granularity of control and making trade-offs decisions. In Chapter 4, 5, 6 and 7 we will experimentally evaluate each of these logical aspects in details.

In the next chapter, we will explore the first internal self, namely QoS Modeller, in the self-aware autoscaling architecture. Specifically, in such internal self, we propose a self-aware and self-adaptive QoS modelling approach, which is capable to dynamically correlate QoS attributes to various cloud primitives on-the-fly.

Chapter 4

Self-Aware and Self-Adaptive QoS

Modelling in Cloud Autoscaling

4.1

Introduction

The elasticity of cloud has caused a paradigm shift in the way we manage and continually evolve cloud-based software services. However, it would be difficult for software engineers and cloud engineers to predict the wide variation of behaviours that software services can experience when running on a shared and on-demand environment such as the cloud. It is particularly hard to anticipate the dynamic changes in workload and the runtime demands of these cloud-based software services. This fact implies that it becomes more complex to assure the Quality of Service (QoS) when engineering cloud- bases services. The design of offline and manual management strategies for QoS are mere difficult if not impossible exercise to achieve.

With such context in mind, the key problem, which cloud/service providers face is how to manage runtime QoS by autoscaling to the best set of control values on-the-fly. In particular, the fundamental challenge is how to dynamically link QoS with the primitives in cloud, which we address in this Chapter. QoS models allow the use of primitive values as

inputs and predict the likely QoS value as outputs. An accurate QoS model in the cloud can serve as a powerful tool that assists software/cloud engineers or other automated agents to profile service characteristics (e.g., CPU intensive services); to diagnose the cause of violation on QoS requirements; and more importantly, to compare and reason about different elastic autoscaling decisions in the cloud.

As we have extensively surveyed in Chapter 2, the majority of the existing approaches for QoS modelling in cloud has been either static (i.e., analytical [77] and simulation based [55]) or semi-dynamic [90]. The former is being static in the sense that the expression of models are fixed, and therefore, they are insensitive to the QoS fluctuations at runtime; this is due to the entire modelling process has relied on manual and offline analysis. On the other hand, the semi-dynamic approaches focus on adaptive and dynamic modelling of the magnitude of primitives in correlation to QoS, which means the model changes with respect to the QoS fluctuations. However, their selection of primitives to determine the feature inputs of models has been manual and offline, resulting fixed inputs for the models. As a result, they suffer limited self-adaptivity.