## 2 Offering and Managing Cloud Applications
### Common Management Challenges in Cloud Applications  
Because the quality of service and self-management capabilities of today's computer systems are both very high, human error has become the most significant reason for system downtime in large distributed systems [5, 6]. The management flexibility introduced by cloud computing has additionally increased this effect: management tasks, such as the provisioning of new virtual machines or the deprovisioning of unused ones is literally at the systems managers' fingertips and can be handled completely via management interfaces of cloud providers, such as [7] and [8]. Due to this evolution of management interfaces, human errors are more likely to occur, since there is hardly any notion of physical machines or an underlying physical connection network and management tasks can be performed much easier and quicker. Significant effort is required to structure the abstract view on managed resources in management interfaces [9]. However, the most effective way to avoid human errors during systems management is the automation of management tasks leaving only the decision when to trigger them up to human application managers. Regarding the scaling of cloud applications and to enable their resiliency towards failing cloud resources, significant automation is being introduced by cloud providers and cloud application developers [2, 10]. Automation of these tasks is fundamental to the successful use of cloud resources, because it enables cloud applications to benefit best from pay-per-use pricing models  
Figure 1: IT Infrastructure Library (ITIL) Management Aspects (adapted from [4]). and automation also addresses the often low availability of individual cloud resources. Handling these tasks manually would make cloud application too expensive to operate and it would most likely result in unacceptable availability assurances. Other management tasks, such as the update of applications or the migration of applications to new environments are, however, not automated to a similar degree. We now describe how elasticity, resiliency, and the move of applications may be handled in cloud applications and motivate further why an automation of these management tasks would be beneficial. We cover the current state of the industry regarding these automation efforts. Amazon AWS offers monitoring of running virtual machines to analyze central processing unit (CPU) usage, memory usage, request processing time _etc._ Additionally, running virtual machines may publish customized monitoring information and metrics [11]. Based on this information, triggers may be defined to provision new virtual machines or reduce their number. This functionality may be handled for elasticity to scale-out cloud resources. The identification of failing resources, however, may require custom monitoring on the application level, because in many cases not all application failures can be identified correctly on the system level. Additionally, the application developer has to carefully configure the behavior of the systems. Amazon's elasticity management, Cloud Watch, covers the configuration of: (i) the minimum number of virtual machines of a certain type; (ii) the maximum number; (iii) the number of machines to be provisioned and deprovisioned in case a condition occurs; and (iv) how often to check for such conditions. The actual behavior, and especially the success of systems management using this functionality, is highly dependent on this configuration. Consider, for example, a web shop that should scale-out automatically. The application developer therefore monitors the average CPU utilization of virtual machines every five minutes and specifies a trigger that provisions a new instance when the CPU utilization is above 80%. This configuration may be sufficient to scale the application most of the time, but fails when the load of the application increases drastically within very short time frames. In such a case, more machines should be provisioned to adequately react to a workload peak.