# TOSCA-Based and Federation-Aware Cloud Orchestration for Kubernetes Container Platform
## 5 Related Research  
The necessity to federate cloud services has been discussed over the past several years [9; 26; 27]. However, existing studies are limited to the scope that roughly indicates the direction for future research. In contrast, this work has explored and demonstrated the feasibility of federated cloud services by building a working prototype system based on relevant standards and mainstream technologies; this paper proposes an architectural design of container-based cloud orchestration system that can scale out to multiple clusters, as the system load increases. It also presents our validation efforts to conduct a performance verification study by deploying and running a sample cloud service in an actual cloud environment. The problem of multi-cloud orchestration support has been investigated for a while [9; 20; 26; 27; 28]. As argued in recent research, there might be a need for a look from a different angle [11; 29]; the problem might be more effectively tackled when considering cloud application portability, multi-cloud interoperability, and elastic runtime adaptation altogether at the same time. According to the proposed approach, the multi-cloud problem can be divided into two sub-problems of elastic platform definition and cloud application definition [11]. Support for infrastructure-awareness of elastic container platforms provides an execution foundation for cloud-native applications translated from their universal definition to a particular format targeting a specific container platform. Therefore, the end result of their research is to enable cloud applications to migrate to a different cloud service provider at runtime. It is noted that we also aim for a similar research goal, that is, application topology-based multi-cloud orchestration support on top of container platforms. However, the difference is that our primary goal is to corroborate the integration of the trio targeting for a specific container platform, i.e., Kubernetes, whereas their work provides a more generic multi-cloud migration solution that can accommodate heterogeneous container platforms including Kubernetes, Docker Swarm, and Apache Mesos. There are a few other differences worth mentioning. First, runtime migration to different container platforms is not our primary focus. Also, when it comes to the way to define application blueprints, they rejected TOSCA to define a new, lightweight DSL. It contrasts our design decision which was made in favor of TOSCA, because the language is considered as a mature standard for cloud application definitions. The BEACON framework proposed by [PERSON] et al. [30] pertains to a networking solution for the federation of the cloud network; thus, it is different from this work, because the emphasis in our case is placed on enabling federation in the service level. The research work of [PERSON] et al. [28] introduced a multi-component application development structure that used TOSCA expressions to orchestrate the deployment of various cloud applications in OpenStack across multiple federated cloud providers. This differs from ours in that we present an approach and corresponding  
Figure 8: Auto-scaling and load balancing among Kubernetes clusters. architectural design that can reap the benefits of application portability from TOSCA-based declarative topology descriptions and performance gains from container-based fine-grained compositions. [PERSON] et al. [27] thought that the problem could be solved by collecting and stacking the cloud service federation vertically that are classified into the software-as-a-service (SaaS), platform-as-a-service (PaaS), and infrastructure-as-a-service (IaaS) cloud services. Our work proposed a more concrete solution to the same problem, using a container-based method for federating the clusters, to keep abreast of recent advances in the relevant technologies. A model-driven framework can be used to connect a platform-independent cloud model of services with cloud-specific operations [31].