# A Survey on Modeling Languages for Applications Hosted on Cloud-Edge Computing Environments
## 3 Results
### Description of the Deployment Phase
The Cloudify platform also includes a reasoner capable of translating its own TOSCA entities into Docker deployment files. [PERSON] et al. [18] presented a noteworthy instance of the cooperation between Docker and Cloudify's TOSCA, which can deploy IoT applications as containers across both edge and cloud environments. Moreover, there are reasoners that possess the ability to transform technical deployment files into high-level description models. In their publication [19], [PERSON] et al. proposed the Deployment Model Abstraction Framework (DeMAF), which is a reasoner tool that enables the conversion of technology-specific deployment models into technology-agnostic deployment models including Terraform, Kubernetes, and AWS CloudFormation. These technology-agnostic models are structured based on the EDMM [7]. The same approach was employed by [PERSON] et al. [20], where a TOSCA generator tool was provided that is capable of retrieving annotations as input and generating the appropriate type level model of the TOSCA extension. Even in languages not based on TOSCA, the utilization of a reasoner is evident. [PERSON] et al. [21] introduced the Self-adaptive IoT DSL and provided a reasoner converting their language models into K3s orchestration files. In their subsequent study [22], they further emphasized that this reasoner can deploy both the application components described in the model and the entire provided framework, which reads the model for deployment and runtime adaptation purposes. Another example is the velo DSL, presented in [11], which functions as a language specifically designed for describing container orchestration. The Transpiler, as the reasoner of the Velo DSL, has the ability to interpret the abstract specification and generate deployment files for Kubernetes, Docker Swarm, and Mesos Marathon. SMADA-Fog [12] enables a deployment model capable of describing the deployment of application components as a static topology that must be applied to Docker. [PERSON] et al. [23] also discussed the inclusion of a reasoner named the OCCIWare runtime server in MoDMaCAO (Model-Driven Configuration Management of Cloud Applications with OCCI), which has the ability to interpret models and translate them into actions for provisioning infrastructure on OpenStack. Certain CMLs are specifically designed to concentrate on delineating the deployment of services on virtual machines. An alternative approach offers developers the capability to craft tailored virtual machine images that incorporate pre-installed services. However, their conventional purpose primarily assists infrastructure owners in configuring virtual machines as hosts within cloud resources. It is worth noting that even these solutions incorporate reasoner logic to enable effective deployment management. For example, Aeolus Blender [24] generates service deployment configuration using its Zephyrus component. This is achieved by parsing (i) a specification file that contains descriptions of components and their constraints, (ii) a universe file that represents available services and virtual machines in JSON (JavaScript Object Notation) format, and (iii) a configuration file that outlines system level data, such as the number of virtual machines and actions required for a service. Another example, Wrangler [25], is a tool that facilitates the deployment of virtual machines on infrastructure clouds by allowing users to create an XML file that outlines the desired deployment configuration for virtual machines. The previously mentioned MICADO orchestrator [17] can also utilize Occupus or Terraform, along with its MICADO Submitter reasoner, to deploy virtual machines on different private or public cloud infrastructures using the provided descriptions. Efforts are underway to develop a higher-level CML that combines the strengths of existing languages. An example of such an effort is GENTL [9].