## 5 Prototypical Validation and Case Study
### Variability4 TOSCA: An Extension of the TOSCA Standard
#### 5.1.2 Extending TOSCA for VDMM
For example, one phase is used by the provider of the deployment system to restrict the available infrastructure, while another phase is used by the tenant for tenant-specific configurations, such as branding or passwords. The chosen alternatives are then used to modify the implementation files of components. Furthermore, [PERSON] et al. considered multi-tenancy patterns in which components are either bound to already running components or need to be deployed [46; 47; 53]. For example, instead of deploying a new component, a new tenant along with tenant-specific configurations is registered at an already running component. This binding is automatically done and respected during deployment. Different optimization algorithms can be used, e.g., to reduce costs or to distribute the expected workload [46; 54]. However, they do not provide such algorithms. A provisioning flow provisions components using component flows while respecting hosting relations and relations introduced by variability point dependencies [46; 55]. Component flows expose a unified provisioning and management interface, which is used for lifecycle management of the components. In a later work, the overall concept was further extended with triggers, e.g., to scale components up or down [56]. In comparison to our work, we model variability inside a deployment model. Thereby, we do not focus on multi-tenancy but on modeling conditional components and their relations. This is not explicitly possible in the concept proposed by [PERSON] et al., where variability targets the implementation files of components and not the application model. Furthermore, our deployment model is not only restricted to hosting relations but allows to model other relations, such as SQL connections. The concept by [PERSON] et al. for customization flows for ensuring completeness and correctness could be integrated into our concept. Having such a concept would enable us to omit our consistency check. However, such a check is still a valuable sanity check since modeling variability point dependencies is complex and error prone. We also do not further specify different phases for binding variability. However, the different phases proposed by [PERSON] et al. might be used inside our phase in which Variability Inputs are specified. Furthermore, [PERSON] et al. defined his own custom metamodel, whereas our deployment model is based on EDMM [1] and, therefore, can be mapped to TOSCA, Terraform, Ansible, Kubernetes, Docker Compose and more deployment technologies [1, 11]. ### Context-Aware Deployments

In the following, we discuss related work, which focuses on context-aware deployments, such as self-adaptive systems. [PERSON] et al. [42] presented an approach for the context-aware adaptation of dynamic software product lines. They combined a classical feature model with a feature model representing the context. Dependencies between these two models state whether a feature can be used under a certain context. These models are used to adapt applications at runtime by monitoring the context and adapting the currently active features. In comparison to our work, they operated on feature models to directly derive the adaptation steps, while we generate a declarative deployment model which contains the application structure along with all components, relations, and configurations. [PERSON] et al. [57] used a feature model for provisioning virtual machines which specifies available operating systems and software. The feature selection was then transformed into Chef configurations which install the expected software on the virtual machine. However, they were only restricted to a single virtual machine at a time, whereas we generate a deployment model which may consist of several components, such as virtual machines, databases or even other cloud offerings, such as Function-as-a-Service. [PERSON] et al.