OpenFog defines Fog Applications (herein, applications) as being \"_composed of a loosely coupled collection of microservices_\" [7] (p. 85). The microservice paradigm used to design applications is based on separating the application logic into smaller independent, executable, scalable and upgradeable elements (i.e., microservices) that work together to achieve the goal of the application [12; 13; 14]. Therefore, we align with the OpenFog consideration of Fog applications as a collection of microservices and focus on the separation of concerns between the development of the application components and the design of applications. To execute microservices, Fog Computing takes advantage of the lightweight virtualization method that containers provide. This way, each microservice can be encapsulated inside of a container and deployed in distributed devices, or Fog Nodes as OpenFog calls them. Handling the numerous containers in a computer cluster and provisioning a communication environment around them requires a tool for container deployment, scaling and management. OpenFog recommends automating all of these actions through an entity commonly known as a container orchestrator. There are different options, Kubernetes being the most popular one [15]. It is estimated that around 70% of the published academic works have used Kubernetes as opposed to other orchestration solutions [16]. Additionally, many of the leading IT companies offer managed Kubernetes versions and other popular orchestration solutions are based on Kubernetes, such as Red Hat's OpenShift [17]. The design of applications and the development and deployment of the components that compose them are usually considered separate processes. When designing Cloud Application, there are two main ongoing projects that are worth mentioning and analyzing on their own:  
1. The Topology and Orchestration Specification for Cloud Applications (TOSCA) [18] is a standard that describes the usage of topology templates to define workloads that represent Cloud Applications as a collection of services [19]. The topology template is viewed as a graph of components and the relationships between them [20], where lifecycle dependencies can be established for the components, as utilized in [21]. 2. The Open Application Model (OAM) [22] focuses on the modeling of a cloud application as a Directed Acyclic Graph (DAG). They define a Cloud Application as follows: \"_A cloud native application is a collection of interrelated, but discrete components (services, tasks, workers) that, when coupled with configuration and instantiated in a suitable runtime infrastructure, together accomplish a unified functional purpose_\". The OAM mainly consists of two elements: the OAM component that defines workloads related to certain runtime environments and the OAM application where the OAM components are interconnected. Despite the differences they may exhibit, these projects have the same goal: to treat the set of components of an application as a functional unit. This has led to the search for synergies between them: in [12], the authors define applications based on TOSCA and transform them into OAM-compatible files. The design of an application as a DAG helps represent its computations and the communications that interrelate them [23]. Therefore, in the context of Fog Computing, a Fog Application is equivalent to a DAG where the vertices represent the microservices and the edges represent the data exchange between them. Figure 1a shows how the conception of Fog Applications as DAGs can be applied in the manufacturing domain, allowing the design of applications that describe different operations related to the data of each asset in the factory. However, the DAG concept does not establish relations between applications, although some may refer to the same asset. In fact, the DAGs of Figure 1a could be arranged by a robot, as in Figure 1b, or by Assembly Lines (AL) as in Figure 1c.