Problemas de saneamiento urbano derivados

To some extent, SOC addressed the problem of complexity in ever-growing and expanding computing systems. As the number of individual components consti- tuting enterprise systems was growing exponentially, their timely management was becoming an increasingly challenging task. Figure 2.3 schematically illus- trates this basic concept. With the traditional software architecture, enterprises, existing in isolation from each other, need to develop their own components from scratch and manage them afterwards. With the SOA approach, there is no need to maintain redundant components – each of the enterprises is in charge of a single software component, whereas the other components constituting their application

systems are provisioned by other enterprises as services. As this simple diagram illustrates, at a small price of additionally managing network communication, the SOC model allowed reducing software management efforts by a factor of N, where N=4 is the number of enterprises and services constituting their SBAs.

A B C D Enterprise 1 A B C D Enterprise 2 A B C D Enterprise 3 A B C D Enterprise 4 A Enterprise 1 B Enterprise 2 C Enterprise 3 D Enterprise 4

Figure 2.3: Traditional multi-component enterprise software architecture and service-oriented architecture.

With the continuing paradigm shift towards cloud computing, service-based cloud environments are expected to become even more complex. The diagram in Figure 2.4 schematically depicts how cloud computing follows the SOC model and accumulates multiple IT services available to users in one place. By providing a selection of IT resources offered as services to customers, on the one hand, they exempt them from tedious and often unnecessary tasks of IT management. On the other hand, however, the burden of IT management does not simply vanish – it is now the cloud provider’s responsibility to maintain the required Quality of Service (QoS) and meet SLAs.

Given the fact that the number of available cloud services is constantly grow- ing, and their timely management is outgrowing cloud providers’ capacity to man- age them in a responsive manual manner, we are running into a risk of ending up in a situation where service-based cloud platforms become tangled, complex, and unreliable environments. Both academia and industry are coming to realise this problem and consequently putting considerable effort into finding potential so- lutions to address it. Attempts to enable clouds with self-managing mechanisms have mainly focussed on the infrastructure level. Mechanisms for distributing the varying volumes and types of user requests across different computational in- stances (load-balancing), or by reserving and releasing computational resources

A Enterprise 1 B Enterprise 2 C Enterprise 3 D Enterprise 4 A B C D G E F J I H Cloud Services K L

Figure 2.4: Clouds follow the SOC model by gathering IT services in one place.

on demand (elasticity) (Armbrust et al., 2010, Natis et al., 2009) are nowadays seen as ‘must-have’ features of a cloud offering. In both cases, self-adaptation mecha- nisms typically implement a closed control loop for self-adaptations, where main monitoring metrics are CPU and memory utilisation of computational instances (i.e., virtual machines), and network bandwidth. More specifically, to facilitate load balancing, IaaS providers observe current resource consumption and take necessary steps to move computational instances – that is, to spread users’ work- load – across multiple physical servers. By doing so, they aim at achieving even workload distribution across their datacentres and avoiding situations when some servers are overloaded with data storage and intensive computations, while others stay idle. As for elasticity, IaaS providers monitor customers’ resource utilisation and are able to automatically take necessary steps to either scale down by shut- ting down excessive instances associated with a particular customer, or scale up by launching additional instances in response to reaching a critical level of re- source utilisation. As a result, customers benefit from both types of activities – they do not need to pay for idle instances (that is, for the resources they are not actually using), and are also secured from their applications crashing due to the

shortage of resources. Both load balancing and elasticity are now seen as essential characteristics of cloud computing (Mell and Grance, 2009).

In some cases, the process of adding/removing computational instances is managed by the cloud platform in a completely automated way (e.g., in Open- Shift, Google App Engine, or AWS Elastic Beanstalk). In other cases, application developers are first expected to configure such capabilities by specifying critical thresholds when resources have to be provisioned/de-provisioned. Other cloud platforms only provide an API for performing such activities (e.g., CloudFoundry or Heroku), and users are asked to monitor their resource utilisation and accord- ingly apply changes programmatically. Third-party solutions have also proved to be useful when automating the task of scaling applications up/down (e.g., a commercial offering HireFire1for Heroku). Another relevant technique offered by several platforms, including OpenShift and Heroku, is to idle inactive computa- tional instances based on users’ recent activity to save cloud platform resources and users’ money.

A basic technique employed by most of the existing cloud self-management mechanisms is ‘heart beat monitoring’ which relies on sending polling request to the monitored components within certain time intervals to check if it is still ‘alive’ (that is, responding to these requests), and, if not, taking necessary steps to restart it (for example, see Dead Man’s Snitch for Heroku.2_{) Self-management}

behaviour of this kind is rather simple, and does not involve any sophisticated analysis of what the underlying problem might be and how to solve it. Appli- cations are treated as ‘black boxes’ and usually, if they still do not operate after several attempts to restart, they are fully stopped and further actions need to be taken by users. To support more in-depth monitoring of deployed applications and provide customers with visibility into resource utilisation and operation per- formance, some cloud platform operators either offer built-in monitoring tools (e.g., Amazon CloudWatch3 or Google App Engine Dashboard) or employ exter- nal monitoring frameworks4 _{(e.g., New Relic}5 _{and Sensu}6_{). Common monitored}

metrics are CPU and memory utilisation, disk reads and writes, network traffic, number of incoming requests, etc. However, such monitoring frameworks often only deal with collecting and displaying data, and do not provide any means of automatically recognising and fixing a problem once it appears – this task is left

1_{https://www.hirefire.io/}

2_{https://elements.heroku.com/addons/deadmanssnitch/} 3_{http://aws.amazon.com/cloudwatch/}

4_{Please refer to Chapter 4 and Appendix C for a more detailed overview.} 5_{http://newrelic.com/}

to the administrators. In this sense, existing solutions for supporting autonomic behaviour can only qualify for the managed level of self-management (please refer to Table 2.1). In Chapter 4, we provide a more detailed and critical overview of the existing solutions in the domain of autonomic cloud platforms and associated data monitoring and analysis solutions.