# Enabling Role-Based Orchestration for Cloud Applications
## 4 Experimental Evaluation
### TOSCA Model Conversion Cost
As a result, the proposed approach can benefit from role separation of concerns and higher-level orchestration features enabled by OAM technology. Since our approach is geared towards higher-level abstractions, low-level details such

Figure 12: Progress of rolling update. as infrastructure resource managements are hidden from the application developers and operators. This way, it can effectively ease much of the complexities and burdens inherent to cloud application orchestration. Consequently, application builders can focus on their own tasks without being worried about under-the-hood details. However, a downside of the proposal is that it lacks fine-grained orchestration ability for cloud services and applications. Being positioned as an orchestration solution at the capability level and above, our proposed system is notable for handling orchestration needs with regard to low-level infrastructure resources. It is noteworthy that there exist other approaches that can support both IaaS- and PaaS-level orchestration [22]. Regrading the runtime implementation, our system is built upon Kubernetes. As a result, it can handle containerized workloads only. Our prototype system can be extended to support other types of workloads, especially non-containerized workloads. In addition, further flexibility could be considered regarding the application component to container mapping relationships. It is noteworthy that some proposals already support the case of multiple components being placed within a single container [23]. Lastly, the workflow engine in our prototype could be augmented further. Even though TOSCA specifies primitives for workflow definition including interfaces of node types, our prototype implementation does not provide a full coverage of the primitives to generate corresponding execution directives. In addition, the current implementation is limited in that one workflow step can only specify the activities and states of a single node. However, it is likely that there exists an orchestration scenario where a workflow step involves multiple nodes in the cluster. ## 5 Related Work

Much attention has recently been paid to the technology of cloud orchestration. As a result, various alternative approaches to cloud application orchestration have been explored, each with different strengths and weaknesses [6; 24; 25]. Some of the efforts target the standardization of orchestration features and interfaces, while others have focused the development of real orchestration tools and solutions. In addition, when it comes to the orchestration layer of focus, they exhibit a wide range of low-level resources to application layer functionalities. In order to assess the novelty of our proposal against others, we have conducted a qualitative comparison study of several outstanding approaches in the field. Table 3 compares our approach with Tosker, TOSCAMP, Cloudify, and KubeVela. This paper extends our previous work [26] where the idea of role-based cloud orchestration was proposed along with its early results presented. In this version, having advanced the orchestration system architecture with support for features like application topology model, platform capability abstraction, and role-awareness for cloud application orchestration, we have demonstrated that our proposal significantly reduces the complexity of application orchestration on cloud platforms.