## 7 Assessment of Maturity and Stability
\begin{table}
\begin{tabular}{l l c c c c c c c} \hline \hline
**Sub-aspects with** & & & & & & & & & \\
**features that relate to** & _Standardization_ & _initiatives_ & **Swarm** & **Swarm** & **Integrated** & **Kubernetes** & **Mesos** & **Mesos +** & **Mesos +** & **Marathon** & **DC/OS** \\ \hline \hline \multirow{4}{*}{**Unified container**} & & **Sa** & **Si** & **Ku** & **Me** & **Au** & **Ma** & **De** \\ \cline{2-10}  & _Open Container_ & & & & & & & & \\
**runtime architecture** & _Initialize (CCI) over_ & & & & & & & & \\
**Contained container** & & & & & & & & \\  & _runtime architecture_ & & & & & & & \\
**Plugin architecture** & & _Container Network_ & & & & & & \\
**for network services** & _Interface (CNI)_ & & & & & & & \\
**Docker’s libnetwork_ & & & & & & & & \\
**(_data CMD_ & & & & & & & \\
**Docker’s volume_ & & & & & & & & \\
**Pensistent volumes** & _plugin system_ & & & & & & & \\  & _Common Storage_ & & & & & & & \\  & _Interface (CSI)_ & & & & & & & \\ \hline \hline \end{tabular}
\end{table} 
Table 7: Overview of existing standardization initiatives and their support. With respect to common features, we have studied the volatility of features in the past by counting the number of feature additions versus the number of feature deprecations (see Figure 1). Surprisingly, we have found very little volatility in terms of feature being deprecated without a replacing feature update. We recorded in total 626 feature additions; 48 out of these 626 additions comprised an update of an existing feature without deprecating the existing implementation strategy of the feature; finally, only 9 out of 626 feature additions comprised a feature update with deprecation or removal of the old implementation strategy of the feature. If we assume that the past is a good indicator for the future, the risk that a common feature will be deprecated by a CO framework without being replaced with an alternative new feature implementation strategy is less than 2%. With respect to unique features, we assume that the risk may be higher. After all, if the team developing a specific unique feature faces even small problems, there is less incentive to resolve these problems in comparison to common features that are supported by other CO frameworks as well. This risk should be taken into account by research and development projects that consider relying on those unique features. The technical report [31] presents in Section 6 a detailed assessment of the risk of feature deprecation for the unique features of the three leading CO frameworks, Docker Swarm integrated mode, Kubernetes and DC/OS. In this article, we only present a summary of the most important findings for Kubernetes that offers a substantially higher number of unique features:  
* If the performance overhead of _StatefulSets_ for running database clusters cannot be resolved, DC/OS' approach to offer a user-friendly software development kit for generating custom scheduler frameworks for specific database may be the better approach. * _Horizontal and vertical Pod autoscalers_ are not fit to meet SLOs for complex stateful applications like databases. The generic design of these autoscalers will need to be sacrificed so that application managers can develop custom auto-scalers for particular workloads. As such, there is a substantial chance that the generic autoscaler will be replaced by different types of auto-scalers (see also Section 8.3). * The development of the federation API for managing multiple Kubernetes clusters across cloud availability zones has been halted; instead, a new API is being planned [384]. Most likely the federation API will be replaced by a simplified API where some _existing federated instantiations_ of Kubernetes API objects such as federated namespaces will be deprecated.