## 4 Cloud Application Management Patterns
### Resiliency Management Pattern  
**Icon:** the icon of the _resiliency management pattern_ is depicted in Figure 9.  
**Driving Question:**_How can the availability of a composite application be ensured even if individual components fail?_  
**Context**: a _composite application_ that distributes _application components_ among different _low-availability compute nodes_ offered by an _elastic infrastructure_.  
**Challenges**: if an application depends on the availability of many individual resources, the overall availability of the application is may be reduced drastically. This is due to the fact that the chance that  
Figure 9: Icon of the Resiliency Management Pattern.  
at least one of the resources fails is higher, the more resources are used. Therefore, it has to be ensured that individual resources may fail without affecting the availability of the overall application.  
**Solution**: scale-out application components among multiple resources. Ensure that a sufficient threshold of component instances is provisioned exceeding what the currently experienced workload requires, monitor and react to component instance failures according to the abstract management flow depicted in Figure 10.  
**Results**: the failure of component instances can be detected and automatic reaction is enabled. Critical design decisions in this scope are:  
1. Time intervals at which the states of component instances are checked.
2. Method for failure detection.  
The time intervals mainly depend on the required recovery time and, therefore, have to respect provisioning time of resources. Often, cloud providers do not make assurances for these times and heuristics have to be employed to predict them. To detect a component failure, providers may offer monitoring of network availability, CPU or memory utilization, for example [11]. The application manager, however, is obligated to interpret these values and deduct information about application component availability from them. Further, none of this information can assure that the component functions correctly on the application level. Such tests have to be implemented manually by the application developer.  
**Variations**: sometimes, failures are hard to detect on the application level. Especially, testing how application components behave after a very long runtime can be challenging. To address these challenges, application components can be randomly treated as failed after certain time intervals and are then replaced by newly provisioned instances.  
**Relations to other patterns**: the components themselves should be implemented as _stateless components_ to simplify their management within the scope of this pattern. The _resiliency management pattern_ may be combined with the _elasticity management pattern_ if elasticity is also an issue.  
**Known uses**: The concept has been used to enable high availability of processes running on a single machine. In this scope, the system component handling the above described management flow is called  
Figure 10: Abstract Management Flow of the Resiliency Management Pattern.  
a watchdog to which system components notify their availability [38]. Amazon suggests a similar approach to assure fault tolerance in applications using their Elastic Beanstalk service [39].