## 5 Prototypical Validation and Case Study
### Variability4 TOSCA: An Extension of the TOSCA Standard
#### 5.1.2 Extending TOSCA for VDMM
Missing components are iteratively added until every relation has a target component. For example, a user application has a pending relation for a web server. Therefore, a web server component is added, which introduces a new pending relation for a virtual machine. This process is repeated until no component is missing. [PERSON] et al. [81] makes use of this approach and further injects communication drivers into components to enable middleware-independent modeling. [PERSON] et al. [82] presented a method that first splits the hosting components of a deployment model based on labels. These labels are assigned to business-relevant components and represent, for example, the desired deployment on a specific cloud provider such as AWS. A matching step transforms the hosting components to conform to the specified label of their hosted business-relevant components. For example, a Java web application that is hosted on a Tomcat on a virtual machine is labeled to be deployed on AWS. This results in the replacement of the Tomcat and underlying hosting components with an AWS Beanstalk component. ### Templating Engines

There exist several templating engines. For example, the Go Templating Engine [85] is used by the Kubernetes package manager Helm [86] to generate Kubernetes manifests, Jinja2 is used by Ansible, among others, to access variables inside Playbooks or to generate configuration files, and Embedded JavaScript Templating (EJS) [87] or Pug [88] can be used with the Node.js server framework Express [89] for server-side rendering of HTML. These templating engines support conditional elements but are usually restricted to specific programming languages, e.g., Go Templating Engine for Golang and EJS for JavaScript. In comparison, our approach is independent of the used programming language. Furthermore, our approach is integrated into TOSCA. For example, if a condition on a group is evaluated as false, then all group members are removed from the deployment model. Therefore, not even templating engines which are independent of the programming language are suitable. ## 7 Threats to Validity

Considering threats to validity regarding the case study, the case study was conducted by one of the authors and not by one or even multiple probands, being unfamiliar with the approach. Furthermore, the case study was restricted to our motivating scenario. However, we are confident about the generalizability of the motivating scenario since from the view of a graph-based deployment model, the components and relations are simply nodes and edges possibly representing any kind of application. Furthermore, we validated our approach with a prototype based on TOSCA. We did not validate applying our approach, for example, to Docker Compose. However, since our approach is based on EDMM, we are confident about the generalizability. Considering threats to validity regarding the benchmark, the median of several runs was used to mitigate outliers. However, the benchmark was executed while the system was not under load. Combining the results of several benchmarks distributed over several days while the system is under various load would improve the validity of the benchmarking results. Furthermore, the benchmarking is in respect of a single implementation. Other implementations might perform better or worse. ## 8 Conclusions and Future Work

Describing different variants of an application deployment using individual deployment models quickly results in a large number of models which are error prone to maintain. Deployment technologies, such as Terraform and Ansible, address this by conditional components and dependencies. We applied this concept to TOSCA in form of a preprocessing step. By transforming Variability4 TOSCA models to standard TOSCA models, our approach can be easily integrated into existing toolchains since employed TOSCA orchestrators can be used without any modifications.