# Enabling Role-Based Orchestration for Cloud Applications
## 4 Experimental Evaluation
### TOSCA Model Conversion Cost
We leveraged managed Kubernetes services of the cloud providers which enables higher availability and better performance than a manual setup in the local machine. We repeated the application deployment for our sample scenario multiple times on each cloud platform and averaged the times taken before the WordPress application becomes available and the auto-scaling feature gets ready. The results in Figure 11 show that our prototype system is able to deploy the application on these cloud platforms within a minute. Figure 10: Conversion times of TOSCA to OAM specification. To see how simplified it can make matters when it comes to orchestration configurations, we compared the number of configuration fields that have to be cared about. As presented in Table 2, only six fields at the top need to be configured in case of our approach. We'd like to emphasize that this is a drastic reduction from previous approaches where all the low-level details, as listed at the bottom of the table, should have been specified and configured. In our case, the six parameters are enough to set up an application with auto-scaling capability enabled. These configurable fields should be of interest for the two roles of application developers and operators. It is noted that our role-aware orchestration model makes this reduction possible, as its building blocks, from basic modeling types to top-level application topology, are identified and distinguished according to different roles' concerns. All other parts that do not concern particular roles remain hidden from them and are automatically handled by the orchestration system. \begin{table}
\begin{tabular}{l l} \hline \hline \multicolumn{2}{c}{**Capability Configuration Fields**} \\ \hline
**ContainerizedWorkload (Workload Capability)** & **AutoScaling (Operational Capabilitiy)** \\ \hline.spec.template.spec.containers.* &.spec.promQuery \\ \hline.spec.ports.* &.spec.promThreshold \\ \hline.spec.maxReplicaCount \\ \hline.spec.minReplicaCount \\ \hline \multicolumn{2}{c}{**Related Underlying Resource Configuration Fields**} \\ \hline
**deployments.apps/v1 (main application)** & **deployments.apps/v1 (Prometheus component)** \\ \hline apiVersion/kind & apiVersion/kind \\ \hline metadata &.metadata \\ \hline.spec.replicas &.spec.replicas \\ \hline.spec.selector.matchLabels &.spec.selector.matchLabels \\ \hline.spec.template.metadata.* &.spec.template.metadata.* \\ \hline.spec.template.spec.containers.* &.spec.template.spec.containers[0].* \\ \hline
**services(.core)/v1 (main application)** &.spec.template.spec.containers[0].volumemounts \\ \hline apiVersion/kind &.spec.template.spec.volumes.* \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Comparison of orchestration configuration fields. Figure 11: Deployment times on managed Kubernetes service. ### Workflow and Progressive Delivery

In order to make sure that our workflow engine works as expected, we conducted an experiment of progressive delivery which involves orchestration workflows. Progressive delivery is a process of releasing updates of applications in a controlled manner, steering the automated promotion or rollback of the update. Progressive delivery involves both application developers and operators. Developers are responsible for providing the artifacts of a new version as well as a workload configuration for running the artifacts. By contrast, operators carry out multiple tasks, such as specifying a rolling strategy, modifying other operational capabilities to avoid interfering with the rollout, determining a rollback strategy, etc. This is where an orchestration workflow comes into play. It is composed of a series of steps to handle various tasks. Our approach promotes the principle of separation of concerns by allowing users to define a role-aware workflow in TOSCA. Each step of the workflow is relevant to specific roles. The workflow is divided into five steps as shown in the Listing 7. During progressive delivery, the number of replicas of a new version should follow the defined rules.