# A Survey on Modeling Languages for Applications Hosted on Cloud-Edge Computing Environments
## 3 Results
### Description of the Deployment Phase  
In edge-cloud computing environments, CMLs used for applications illustrate the interaction of application components and their deployment within these environments. Nevertheless, there is a lack of consensus among CMLs regarding the standardized approach for describing application components. While some languages represent them as containers, others favor the utilization of services on virtual machines. This discrepancy arises from developer perspectives on streamlining orchestration within specific cloud platforms that may have a preference for certain types of deployment units. The previous subsection emphasizes the significance of CMLs that are not limited to specific cloud platforms. These languages should be capable of describing the deployment process. For instance, Uni4 Cloud [13] utilizes the OCCI specification for cloud-agnostic application deployment. In contrast, CAMEL [1] enables the depiction of application deployment across various cloud providers. Users define components using the design time-domain, and runtime models are created by reasoners to facilitate deployment on the chosen provider. The deployment package in CAMEL allows developers to specify the deployment of their applications. According to [14], TOSCA provides the ability to describe the deployment and management of application components in a cloud-agnostic way, making it compatible with various cloud providers and container technologies such as Docker and Kubernetes. However, to use TOSCA on cloud providers and container technologies, a reasoner is required. For reasoners to handle translation effectively, it is important to match the representationsof a CML with the underlying technology entities. Building on this idea, [PERSON] et al. [15] conducted a study illustrating the utilization of a TOSCA-based language with Kubernetes to orchestrate pods, which serve as deployment units for one or multiple containers. They identified specific semantics necessary in TOSCA to describe application components, ensuring compatibility with Kubernetes configuration files. Drawing inspiration from TOSCA's capabilities, [PERSON] et al. introduced a language named EDDM in [7]. EDDM facilitates the creation of declarative deployment models that place significant emphasis on defining the method of application's deployment in a platform-agnostic fashion. This includes specifying the application's structure, components, configurations, and interdependencies without being tied to any specific platform. EDDM models can be mapped to Kubernetes and Docker Compose configuration files and it can even be mapped to TOSCA models. [PERSON] [16] is a reasoner, which uses TOSCA Simple Profile YAML files to simplify the deployment of Docker containers. [PERSON] parses extended TOSCA models capable of describing container orchestration and transforms them into Docker deployment files. However, it is important to note that Tosker does not support the deployment of containers in the Docker Swarm mode. [PERSON] et al. [17] introduced an advanced reasoner in their paper. They presented MiCADO (Microservices-based Cloud Application-level Dynamic Orchestrator), a container orchestrator utilizing TOSCA on both Docker Swarm and Kubernetes platforms. To support this, they created a reasoner called MICADO Submitter. Initially, MICADO used Docker Swarm but later transitioned to Kubernetes. Another example is the Cloudify platform, a cloud and network function virtualization (NFV) orchestration platform, which utilizes an extended version of TOSCA to introduce new entities for describing Docker container orchestration ([[https://cloudify.co/blog/docker-tosca-cloud-orchestration-openstack-heat-kubernetes/](https://cloudify.co/blog/docker-tosca-cloud-orchestration-openstack-heat-kubernetes/)]([https://cloudify.co/blog/docker-tosca-cloud-orchestration-openstack-heat-kubernetes/](https://cloudify.co/blog/docker-tosca-cloud-orchestration-openstack-heat-kubernetes/))) (accessed on 12 October 2023).