# Spot Market Cloud Orchestration Using Task-Based Redundancy and Dynamic Costing
## 3 Task-Based Redundancy in Cloud Systems
### Applying Task-Based Redundancy to Cloud Microservices  
Our proposed model for applying TBR to cloud microservices uses three tiers of abstraction: the task tier, the microservice tier, and the container tier (Figure 4). A task is a set of actions that depend on the acceptable functioning of one or more microservices. In our model, microservices are abstract, stateless images that can be instantiated into as many containers as are necessary at runtime. These containers are the instantiated redundant instances that actually provide the service to the end user.  
In TBR, the reliability of the system with respect to some task \(T\) is modeled using a failure function, \(F_{T}(t)\), which defines the probability that, due to the failure of all the redundant components, the system will enter the failure state (defined as the state where it is unable to execute \(T\)) before time \(t\)[31].  
Applying this method to our proposed cloud microservices model (Figure 4), we develop increasingly compound failure functions at each tier, culminating in the failure function \(F_{T}(t)\) at the task tier. The failure functions at each tier are series/parallel arrangements of the failure functions of the relevant dependencies in the preceding (lower) tier.  
At the lowest tier (the container tier), we define a uniform failure function \(F(t)\) for each of \(n\) container instances of some microservice [6]. \(F(t)\) reflects some real-world assessment of the failure behavior of the microservice container.  
In our empirical testing, discussed in Sections 5 and 6, we elected to use the exponential function due to its constant hazard rate, reflecting the general case where no additional information is known about the propensity of a particular container to fail [6]. However,  
Figure 4: Our Task-Based Redundancy (TBR) model for cloud microservices. The diagram shows a single task composed of several microservices. The microservices shown may also be dependencies for other independent tasks in the cloud system.  
any suitable function may be chosen, perhaps even an approximation of statistical failure behavior in cloud systems with a monitoring history available.  
Having selected some function for \(F(t)\), we can determine the failure function, \(F_{MS}(t)\), at the next superior tier, which defines the probability of failure of a microservice comprising \(n\) redundant containers, as in (1) [6]. \(F_{MS}(t)\) is found to be the product of the failure functions of the containers because the microservice will cease to provide service _iff_ all redundant containers fail. While the failure functions for each microservice container, \(F_{i}(t)\), are identical by virtue of the replication of the same microservice image, in order to adjust for the different times of instantiation of each container, the argument \(t\) is offset by \(t_{0i}\), where \(t_{0i}\) is the time of instantiation of the microservice in terms of the global system time, as in (1).  
\[F_{MS}(t)=\prod_{i}^{n}F_{i}\big{(}t-t_{0_{i}}\big{)} \tag{1}\]  
Finally, we find the failure function of the task with respect to the failure functions \(F_{MSm}(t)\) of its constituent microservices. In our example, we assume a simple sequence of calls to microservices (i.e., all microservices are required), yielding an in-series arrangement. Thus, we find the failure function of the task to be as in (2), expanded to (3) [6].  
\[F_{T}(t)=1-\prod_{j}^{m}\big{(}1-F_{MSj}(t)\big{)} \tag{2}\]  
\[F_{T}(t)=1-\prod_{j}^{m}\left(1-\prod_{i}^{n}F_{i}\big{(}t-t_{0_{i}}\big{)}\right) \tag{3}\]