## 4 Cloud Application Management Patterns
### Elasticity Management Pattern  
**Icon:** the icon of the _elasticity management pattern_ is depicted in Figure 7.  
**Driving Question:**_How can the number of resources to which application components are scaled-out be adjusted efficiently to the currently experienced workload?_  
**Context**: a _componenized application_ is hosted on an _elastic infrastructure_ and comprised of _elastic components_, _elastic queues_, or _elastic load balancers_. **Challenges**: the dynamicity of clouds demands automatic scaling of cloud resources. To perform this task, the current resource demand has to be determined and has to be reflected in provisioning and deprovisioning of system resources. **Solution**: analyze the current utilization of system resources after certain time intervals, when a user requests it, or based on monitored system events to determine the current workload and adjust resource numbers accordingly. **Result**: the elasticity management flow can be triggered periodically (every day, month _etc._) depicted by the timer event in Figure 8. Alternatively, a user of the application can trigger it, for example, because he knows that a number of new employees will start using the application at a certain date. This case is reflected by a message event passed to the management flow. As a third option, the flow can be triggered by signals originating from monitoring. For example, the size of a queue may exceed a certain threshold if this management pattern is combined with the _elastic queue pattern_. When the elasticity management flow is triggered, resource utilization is optimized and resource numbers are adjusted to correctly reflect the workload. Critical design decisions in this scope are:  
1. Time interval at which system utilization is evaluated (in case of time-based triggers): if this interval is too large, the system may be underutilized or overloaded without notice. Figure 8: Abstract Management Flow of the Elasticity Management Pattern. Figure 7: Icon of the Elasticity Management Pattern. 2. Reactions to workload analysis: the reaction must be appropriate, for example, if too few resources are added to the system, it takes too long until an increased workload can be handled by the application. Both design decisions mainly depend on heuristics and prior experiences. When determining the time interval at which utilization is measured, it has to be considered how quickly utilization has changed in the past. Also, the time it takes to provision new resources has to be considered here. This is also an important factor when determining how a change in the utilization should be addressed. Historic information, such as user behavior during holidays may be used to adjust these variables [34]. **Relations to other patterns**: the elasticity management pattern can be combined with _elastic components, elastic queues_, or _elastic load balancers_. These patterns form the architectural basis for the elasticity management flow by providing the required monitoring information that has to be extracted from the managed application components and their runtime environment. **Variations**: manual triggering of the introduced management flow may not only originate from application users. Who is responsible for this task mainly depends on the employed _cloud service model_. In case of _IaaS_, the user of the cloud likely performs this task. However, in case of _PaaS_ and _SaaS_, the configuration of elasticity management may be hidden from the user. In this case, the task instead may be performed by the cloud provider. **Known Uses**: [2] describes how to scale Amazon AWS Resources. Especially, it covers different events and conditions when the elasticity management should be executed. [35] evaluates the scaling capabilities of Windows Azure, for which [36] offers a scaling software as a service. The concept to scale-out applications automatically is, however, not only seen in cloud computing and has been used by the industry for quite some time [31].