## 1 Introduction  
In recent years, there has been a strong industry adoption of Docker containers due to its easy-to-use approach for distributing and bootstrapping container images. Moreover, in comparison to virtual machines, Linux containers have a lower memory footprint and allow for flexible resource allocation to improve server consolidation [1]. The popularity of Docker has also changed the way in which application software can be packaged and deployed: container images are self-contained components that can be tagged with version numbers and are made available for download from private or public Docker registries. Moreover, container images are portable across different operating systems and different cloud provider stacks [2]. Container orchestration (CO) frameworks, such as Docker Swarm, Kubernetes, and the Mesos-based Marathon, provide support for deploying and managing a multi-tiered distributed application as a set of containers on a cluster of nodes [3]. Container orchestration frameworks have also increasingly been used to run production workloads as for example demonstrated in the annual OpenStack user survey [4; 5; 6]. However, there have been several high paces of feature additions among the most popular CO frameworks as illustrated by Figure 1, which shows the number of feature additions between June 2013 and June 2018. As shown, there was a first peak of feature additions between June 2014 and January 2015 because Mesos v0.20.0 [7] added support for Docker containers and Google open-sourced Kubernetes v0.4.0 [8] that from its inception offered support for Docker containers. Moreover, Kubernetes v0.6.0 included several innovating features such as container IP and service IP networking [9], pods [10], and persistent volumes [11]. This caused a ripple effect of feature additions across the other CO frameworks. For example, support for persistent volumes has been added to Docker v1.7 [12] in June 2015. By August 2016, Docker's architecture for persistent volumes has also been supported by Mesos v1.0.0 [13]. As another example, support for container IP networking has been added to Mesos v0.25.0 [14] and Docker Swarm stand-alone v1.0.0 [15] by January 2016. This high pace of feature additions has been a challenge for companies to (a) keep an up-to-date understanding of what constitutes the conceptual foundation of the overall domain, to (b) determine which CO framework matches most closely with their requirements and to (c) determine which framework is most mature with respect to these requirements. This is both a risk for companies who start using container orchestration technology and companies who consider migrating from one CO framework to another framework. They are also faced with (d) feature deprecation risks, i.e., there is strong dependence on a feature that will not be supported anymore by future versions of the employed  
Figure 1: Density of feature additions over time (common features only). CO framework. Finally, (e) academic researchers and entrepreneurs are also faced with the challenge that their innovative idea for a product or research prototype may become obsolete when a new version of the CO framework has been released. An illustration of these challenges from the entrepreneur side is the story of ClusterHQ, a company that pioneered in 2014 with the container data management service Flocker [16]. Flocker initially gained a lot of traction and the company raised 12 $ million in 2015 [17] and there was a well-working integration [18] with Kubernetes, Mesos and Docker Swarm. However, by the end of 2016, the company stopped all its activities because of reportedly \"self-inflicted wounds\" [19]. Actually, by that time all major CO frameworks provided also built-in support for external persistent volumes. A final challenge is to (f) keep track and interpret ongoing standardization efforts in this space.