2 Background

Answer Set Programming (ASP) is a popular declarative programming paradigm. Its compact and expressive language makes it a powerful tool for handling knowledge-intensive combinatorial problems, both in industry and academia (Erdem et al. (Reference Erdem, Gelfond and Leone2016); Falkner et al. (Reference Falkner, Friedrich, Schekotihin, Taupe and Teppan2018); Gamblin et al. (Reference Gamblin, Culpo, Becker and Shudler2022); Baumeister et al. (Reference Baumeister, Herud, Ostrowski, Reutelshöfer, Rühling, Schaub and Wanko2024); Azzolini et al. (Reference Azzolini, Forti and Ielo2025)), also thanks to the availability of efficient reasoners (Leone et al (Reference Leone, Pfeifer, Faber, Eiter, Gottlob, Perri and Scarcello2006); Gebser et al. (Reference Gebser, Kaminski, Kaufmann and Schaub2019)).

Syntax. A term is either a variable, a constant, or a function symbol, where variables start with uppercase letters and constants start with lowercase letters or are numbers. A function term is an expression of the form $f(t_1, \ldots , t_n)$ where $f$ is its name and $t_i$ are terms. An atom is an expression of the form $p(t_1,\ldots ,t_n)$ where $p$ is a predicate of arity $n$ and $t_1,\ldots ,t_n$ are terms; it is ground if all its terms are constants. A literal is either an atom $a$ or its negation $\mathop {not} a$ , where $\mathop {not}$ denotes the negation as failure. A literal is said to be negative if it is of the form $\mathop {not} a$ , otherwise it is positive. For a literal $l$ , $\overline {l}$ denotes the complement of $l$ . More precisely, $\overline {l}=a$ if $l = \mathop {not} a$ , otherwise $\overline {l}=\mathop {not} a$ . A normal rule is an expression of the form $h \leftarrow b_1,\ldots ,b_n$ where $h$ is an atom called head. When $n\geq 0$ , $b_1,\ldots ,b_n$ is a conjunction of literals called body. A normal rule is said to be a constraint if its head is omitted, while it is said to be a fact if $n=0$ . A programme is a finite set of normal rules. We will also use choice rules (Niemelä et al. (Reference Niemelä, Simons and Soininen1999)). A choice element is of the form $h:l_1,\ldots ,l_k$ , where $h$ is an atom, and $l_1,\ldots ,l_k$ is a conjunction of literals. A choice rule is an expression of the form $\{e_1;\ldots ;e_m\}\leftarrow b_1,\ldots ,b_n$ . We also consider aggregate atoms in the body of rules (Alviano and Faber (Reference Alviano and Faber2018)) of the form $\#sum\{\epsilon _0 ; \ldots ; \epsilon _n\} \ \gt k$ where $k$ is called guard and can be a constant or a variable and $\epsilon _0, \ldots , \epsilon _n$ is such that each $\epsilon _i$ has the form $t_1, \ldots , t_n : F$ and each $t_i$ is a term whose variables appear in the conjunction of literals $F$ .

Semantics. Given a programme $P$ and $r \in P$ , $ground(r)$ is the set of ground instantiations of $r$ obtained by replacing variables in $r$ with constants in $P$ . For aggregates, a variable is called local if it appears only in the considered aggregate; global otherwise. The grounding of a rule with aggregates first requires replacing global variables and then replacing local variables appearing in aggregates with ground terms. We denote with $ground(P)$ the union of ground instantiations of rules in $P$ . An aggregate is true in an interpretation $I$ (i.e., a set of atoms) if the evaluation of the aggregate function under $I$ satisfies the guards. We refer the reader to Calimeri et al. (Reference Calimeri, Faber, Gebser, Ianni, Kaminski, Krennwallner, Leone, Maratea, Ricca and Schaub2020) for a more in-depth treatment of aggregates. Given a programme $P$ , an interpretation $I$ is an answer set (also called stable model) of $P$ iff $(i)$ $I$ is a model, that is for each rule $r \in ground(\Pi )$ either the head of $r$ is true w.r.t. $I$ or the body of $r$ is false w.r.t $I$ ; and $(ii)$ $I$ is a minimal model of its GL-reduct (Gelfond and Lifschitz (Reference Gelfond and Lifschitz1991)). If $P$ has no answer sets, it is called unsatisfiable.

Optimisation. Weak constraints (Buccafurri et al. (Reference Buccafurri, Leone and Rullo2000)) are expressions of the form $:\sim l_1, \ldots , l_m.[w@p,t_1,\ldots ,t_n]$ where $l_1, \ldots , l_m$ are literals, $w \in \mathbb{N}$ is the cost, $p \in \mathbb{N}$ is the priority, and $t_1, \ldots , t_n$ is a tuple of terms. Such rules associate each answer set with a cost with a priority level, which can be intuitively understood as an objective function, to be optimised in order of priority. These enable one to tackle optimisation problems in ASP (Alviano et al. (Reference Alviano, Dodaro, Marques-Silva and Ricca2020)). An answer set with costs $c_0, c_1, \ldots c_k$ has a “lower cost” than an answer set with costs $c_0', c_1', \ldots , c_k'$ if there exist $i$ such that $c_i \lt c_i'$ and $c_j = c_j'$ for all $j \lt i$ . An answer set is optimal if there does not exist an answer set with a lower cost.

3 Motivating scenario: the application placement problem

In this section, we illustrate the considered problem by means of a simple, yet complete, motivating example adapted from the literature (Forti (Reference Forti2022)). The depicted scenario epitomises a broader class of placement problems in which functional (e.g., hardware, IoT) and non-functional requirements related to sustainability (e.g., energy efficiency, carbon intensity), performance (e.g., latency, bandwidth), and reliability (e.g., availability, security) must be satisfied simultaneously, despite being often conflicting and constrained by limited resources. Typical deployments involve hundreds of services and nodes, leading to a combinatorial explosion of potential candidate solutions (Smolka and Mann (Reference Smolka and Mann2022)) (e.g., mapping 30 services on 100 nodes yields up to $100^{30}=10^{60}$ candidates to check).

The application in Figure 1 manages street lighting using machine learning (ML) and includes two services: the ML Optimiser, which processes video streams to determine optimal lighting strategies, and the Lights Driver, which controls the street lights. The ML Optimiser requires a GPU co-processor to train models that update the driver’s control rules while the Lights Driver interfaces with both a lighting hub and a video camera, which monitors ambient conditions and streams footage to the optimiser. Each service has functional and non-functional requirements. For instance, the ML Optimiser requires 16 GB RAM, access control and anti-tampering mechanisms, minimum node availability (av_min) of 99%, carbon intensity of the node energy mix (ci_max) below 300 $\mathrm{gCO}_{2}$ -eq/kWh, and power usage effectivenessFootnote ¹ (PUE_max) under 2.5. Additionally, communication constraints specify a maximum latency of 50 ms and a minimum bandwidth of 1 Mbps from the ML Optimiser to the Lights Driver, and 5 ms and 16 Mbps in the reverse direction.

Fig. 1. Example application.

Fig. 2. Example infrastructure.

Figure 2 sketches the target infrastructure for the described application. It consists of three interconnected computing nodes – Private Cloud, Access Point, and Edge Node – with a different availability of resources. For instance, the Edge Node is located closest to end devices, being directly connected to the lights hub and the video camera, and is equipped with 8 GB of RAM, a GPU, and 100 Mbps mobile connectivity. It has 90% availability, a PUE of 1.2, and is powered up through an energy mix with a carbon intensity of 100 $\mathrm{gCO}_{2}$ -eq/kWh. While the Private Cloud is assumed to feature all security mechanisms, the other two nodes are only equipped with an anti-tampering system to mitigate the damage in case of physical access to deployment resources. Network communication latencies are symmetric and range from 5 ms between adjacent nodes to 15 ms between the Private Cloud and the Edge Node.

Determining an eligible placement of the application of Figure 1 to the resources of Figure 2 requires mapping each service to a node that satisfies all its functional and non-functional requirements, without exceeding the node’s hardware and bandwidth capacity, which is an NP-hard problem (Brogi and Forti (Reference Brogi and Forti2017)). In the described scenario, there is no solution placement that can satisfy all application requirements in the target infrastructure. To address this, however, the DevOps team in charge of application deployment is willing to relax certain non-functional requirements (i.e., soft) based on predefined priorities, where higher values indicate greater importance and less flexibility. Latency and bandwidth constraints have the highest priority (10) and are thus the least negotiable. Availability follows with priority 2, indicating moderate flexibility. Conversely, PUE and carbon intensity have the lowest priority (1). Security, hardware and IoT requirements remain non-negotiable (i.e., hard) and must always be strictly enforced.

Hereinafter, we show how FlexiPlace leverages ASP and accounts for constraint prioritisation to relax a minimal set of requirements to compute feasible placements with the least impact on the original constraints. That is, we aim at answering the following question: How can we determine a constraint-relaxed placement of a cloud-edge application that is both feasible and minimally deviates from our original deployment intent?

4 ASP encoding

The core idea of our encoding is to match services to nodes in the infrastructure, discarding candidate solutions that do not satisfy application requirements over infrastructure capabilities. As we will formalise in the following, we represent an infrastructure as a graph extended with attributes. Analogously, applications are represented as graphs and their requirements consist of simple arithmetic relationships between a (constant) threshold value for an attribute that a given service “requires” and the value of that specific attribute over the node where a service is placed. Rather than considering a fixed set of attributes for the nodes (and application requirements), our solution provides a way (by means of input facts) to define the attributes of each node (and the corresponding requirements), that can be thus customised by users.

We first describe how to encode an input instance (infrastructure & its capabilities, application & its requirements) into a set of ASP facts, then how to model the application placement problem in ASP (“base encoding”), and finally how to address its relaxed version through ASP optimisation, using the clingo (Gebser et al. (Reference Gebser, Kaminski, Kaufmann and Schaub2019)) input language.

4.1 Reification of infrastructures & applications

Modelling the infrastructure. We model a target deployment infrastructure by means of predicates $node/1$ and $link/2$ . We use an atom $node(x)$ for each vertex $x$ in the network, and an atom $link(x,y)$ for each edge that connects nodes $x$ and $y$ . Informally, both node attributes and link attributes are modelled as “key-value pairs,” by means of predicates $node\_attr/3$ and $link\_attr/4$ . Atoms $node\_attr(x,k,v)$ mean that attribute $k$ has value $v$ on node $x$ , and $link\_attr(x,y,k,v)$ mean that attribute $k$ on edge $(x,y)$ has value $v$ . This representation accommodates several kinds of infrastructure and application properties.

Example 1 (Infrastructure). The node Private Cloud of Figure 2 is encoded via the following set of facts:

Similarly, the link that connects such node to the Edge Node is denoted by the fact:

Modelling the application. We use the predicates $service/1$ and $dependency/2$ , with an analogous meaning to $node/1$ and $link/2$ , to describe the application to be placed. That is, $service(s)$ denotes that $s$ is a unique identifier for a service, and $dependency(s,t)$ that service $s$ “depends on” service $t$ . The counterpart of infrastructure attributes are service requirements, which intuitively act as “constraints”Footnote ² to forbid deployments. Intuitively, as services are deployed onto nodes and have pairwise dependencies, we can label each service with properties its matchee must abide. Thus, while infrastructure attributes refer to its vertices and edges, service requirements will refer to the node the service is deployed onto (during stable model search).

A (simple) requirement is a statement about infrastructure properties a node should possess in order to host a service. Here, we focus on requirement expressions that consist of comparisons between attributes’ value and constants. That is, expressions of the form $r \circ t$ where $r$ is an attribute, $\circ \in \{\lt , \gt , \le , \ge , =, \ne \}$ or $reserve(r,t)$ . Intuitively, these respectively mean that the value (on a node) of an attribute $r$ should compare in a specific way against a threshold value $t$ . The requirement expression $reserve(r,t)$ expresses that $(i)$ attribute $r$ should be understood as consumable resources $(ii)$ a given service requires $t$ units of $r$ on the node to which it is deployed. Application deployments often require that each service has access to a dedicated amount of computational resources (e.g., RAM or bandwidth). Whenever multiple services are placed onto the same node or link asset, it must be ensured that the consumable resources are enough to host all services.

We encode requirement expressions by means of function terms such as $lt(r,v)$ (“less-than”), $gt(r,v)$ (“greater-than”), $eq(r,v)$ (“equals-to”), in addition to the aforementioned $reserve(r,v)$ . Given a requirement expression, we say that it holds on a given service using the atoms $hreq/2$ and $sreq/2$ , which stand respectively for hard requirement and soft requirement. The atom $hreq(s,e)$ denotes that the service $s$ can be deployed onto a node if and only if the node satisfies the requirement $e$ . The atom $sreq(s,e)$ denotes that the service $s$ should be deployed onto a node that preferably satisfies the requirement $e$ . Similarly, the atoms $sreq((x,y),e)$ and $hreq((x,y),e)$ state that the requirement $e$ must be satisfied by the link between the nodes that host the services $x$ and $y$ .

Example 2 (Application requirements). The following encoding denotes the requirements of service ML Optimiser of Figure 1 :

Akin to infrastructure links, dependencies between services are denoted as:

4.2 Encoding application deployment

We now present the “base” encoding that solves the deployment problem. It is based on a guess-and-check procedure, where choice rules guess a candidate assignment of services to infrastructure nodes and constraints prune assignments that violate requirements. We denote such a programme $\Pi _{deploy}$ . For now, we assume no distinction between hard requirements ( $hreq/2$ ) and soft requirements ( $sreq/2$ ). Given an application network $A$ and an infrastructure $R$ , the answer sets of $\Pi _{deploy} \cup [R] \cup [A]$ can be mapped back to assignments that solve our problem. A solution placement can be decoded by projecting answer sets onto the $deploy/2$ predicate.

Fig. 3. FlexiPlace main encoding.

4.3 Relaxing soft requirements on application deployment

Distinguishing between hard and soft requirements naturally corresponds to an ASP optimisation task. The idea is to abduce over possible constraints to remove atoms matching $sreq/2$ by means of choice rules; this disables the corresponding constraint in the logic programme. To do so, $(i)$ we replace line 9 in the base encoding (Figure 3) with the rules in Figure 4 and $(ii)$ if we wish to weight (e.g., assign a preference score) to soft requirements to remove, we introduce atoms $violation\_cost(S,E,(C,L))$ to denote that we will pay a cost of $C$ at level $L$ if we renounce the soft requirement $sreq(S,E)$ .

Fig. 4. Additions to the main encoding of Figure 3 to address the relaxed problem.

Optimal answer sets correspond to optimal solutions of the deployment problem, where atoms $\mathit{lift}(S,E)$ denote that we renounce the requirement $E$ on the deployment of service $S$ . If this logic programme is unsatisfiable, it means that even removing all $sreq$ s, this would not be sufficient to ensure existence of a deployment. That is, (at least one of) the reason(s) for the inconsistency lies in $hreq$ s alone, and further analysis would be required. The logic programme is satisfiable if there exists an assignment that perfectly fits all the requirements. As we are interested in detecting soft requirements to relax rather than finding deployments, we consider projection of answer sets on the $\mathit{lift}/2$ predicate. From the ASP modelling point of view, it would have been equivalent (in terms of optimal solutions) to directly express soft requirements as weak constraints. However, our design choices have several practical advantages: $(i)$ the $\mathit{lift/2}$ predicate enables to easily inspect answer sets and retrieve which requirements have been relaxed to achieve the solution, $(ii)$ it is possible to control by means of facts (i.e., those matching $sreq/2$ and $hreq/2$ ) which requirements are mandatory and which ones can be relaxed, and $(iii)$ atoms $\mathit{lift/2}$ could be naturally used as objective atoms to compute minimal unsatisfiable subprograms for explainability purposes (Alviano et al. (Reference Alviano, Dodaro, Fiorentino, Previti and Ricca2023)).

Example 3. Consider again the motivating scenario of Section 3 . As discussed above, there is no eligible placement that meets all the requirements for the application of Figure 1 to the infrastructure of Figure 2 . For instance, the only node that can support the execution of the ML Optimiser (i.e., the Private Cloud node) features a carbon intensity of 350 gCO $_2$ -eq which exceeds the required 300 gCO $_2$ -eq. Note that our model relies on facts like

to set the cost (i.e. priority) for relaxing soft constraints. Running the encoding of Figures 3 and 4 over the input denoting our motivating scenario returns an eligible placement that suggests deploying ML Optimiser to Private Cloud and Lights Driver to Access Point, and is obtained by relaxing constraints on carbon intensity for both services. Such a solution is optimal, as it only relaxes two of the lowest-priority constraints, as indicated by the DevOps team in charge of managing the application.

5 Experiments

We perform a set of experiments to assess the effectiveness of our approach in computing cost-optimal relaxed deployments. We first analyse the behaviour of available ASP systems on our encoding. Then, we conducted a more in-depth analysis to investigate the trade-off between model-guided (Gebser et al (Reference Gebser, Kaminski, Kaufmann and Schaub2011)) and core-guided (Andres et al. (Reference Andres, Kaufmann, Matheis and Schaub2012)) optimisation algorithms for our application scenario.

The experimentsFootnote ³ were run on a server with Intel(R) Xeon(R) CPU E7-8880 v4 @ 2.20 GHz CPU, equipped with 500 GB RAM, with a timeout of 180 s using GNU Parallel and executing at most 16 jobs in parallel. A timeout in our setting refers to not being able to find an optimal model or proving unsatisfiability within 180 s.

Data. We provide an instance generator for the problem, following standard practice in literature (Gupta et al. (Reference Gupta, Vahid dastjerdi, Ghosh and Buyya2017); Forti et al. (Reference Forti, Bisicchia and Brogi2022); Ghobaei-Arani and Shahidinejad (Reference Ghobaei-ARANI and Shahidinejad2022)). We focus on the infrastructure attributes in Table 1 and define a set of realistic templates for infrastructure nodes and for application services. Infrastructure graphs and application graphs are obtained by sampling from Barabási-Albert (Barabási and Albert (Reference Barabási and Albert1999)) and Erdős-Renyi (Erdős and Rényi (Reference Erdős, P. and Renyi1959)) topologies, respectively. On one hand, the Barabási-Albert model captures the scale-free property of real-world ICT networks, where node degree distribution usually follows a power-law (Newman (Reference Newman2010)). This reflects the heterogeneity and hierarchy typical of cloud-edge infrastructures, where a small number of nodes act as high-bandwidth hubs and others as resource-constrained peripheral nodes. On the other hand, the Erdős-Renyi model neutrally approximates application topologies, where dependencies between services are established with uniform probability (Newman (Reference Newman2010)). This reflects the loosely coupled and stochastic nature of microservice-based applications, where interactions do not follow any hierarchical patterns (Soldani et al. (Reference Soldani, Tamburri and Van den Heuvel2018); Velepucha and Flores (Reference Velepucha and Flores2023)). Each node is assigned (uniformly at random) a “configuration” from a finite set. In our case, the only link attribute is latency, which we model as a random integer between 10 and 50. Nodes that are not directly connected by an edge are assigned an edge with a latency equal to the sum of the latencies in the shortest path between the two nodes. As an example, if a generated graph contains the edges $(a,b)$ and $(b,c)$ , we introduce the edge $(a,c)$ with latency $\ell (a,b) + \ell (b,c)$ , where $\ell (x,y)$ is the latency on edge $(x,y)$ . Following these procedures, we generated 10 infrastructures of size $\{50, 100, 150, \ldots , 500\}$ , and 6 applications of size $\{5, 10, 15, \ldots , 30\}$ . For each combination, we generated 100 input pairs (i.e., application and infrastructure). This yields a total of $10 \cdot 6 \cdot 100 = 6 \cdot 10^3$ instances. We denote by $I(n,k)$ the set of instances considering the deployments of an application of size $k$ over infrastructures of size $n$ . We also use the notation $I(\cdot ,\{k_0,k_1,\ldots \})$ to denote “all problem instances that deal with applications of size $k_0$ , $k_1,$ , $\ldots$ ” and $I(\{n_0,n_1,\ldots \},\cdot )$ to denote “all problem instances that deal with infrastructures of size $n_0$ , $n_1$ , $\ldots$ ”. Lastly, each of the considered applications consists of constraints over all infrastructure properties defined in Table 1. Note that we use a weight of $1$ for all constraints that can be relaxed, with a single priority level, but the encoding we provide is more general.

Table 1. Considered node properties. The table does not contain latency since it is a link property. The “Shared” column denotes whether the property is considered shared among all services hosted on the considered nodes. The “Constr” column reports the constraint instantiated for the attribute during the generation process, for each service

5.1 Solver selection

We consider four ASP systems, obtained by pairing up the ASP solvers clasp (Gebser et al. (Reference Gebser, Kaufmann, Neumann and Schaub2007a)) and wasp (Alviano et al. (Reference Alviano, Dodaro, Leone and Ricca2015)) with the ASP grounders I-DLV (Calimeri et al. (Reference Calimeri, Fuscà, Perri, Zangari, Maratea, Adorni, Cagnoni and Gori2017)) and gringo (Gebser et al. (Reference Gebser, Schaub and Thiele2007b)). Note that the gringo+clasp and IDLV+wasp combinations are, essentially, the combinations adopted in the clingo (Gebser et al. (Reference Gebser, Kaminski, Kaufmann and Schaub2019)) and DLV (Leone et al (Reference Leone, Pfeifer, Faber, Eiter, Gottlob, Perri and Scarcello2006)) solvers. We refer to each system as gringo+wasp, gringo+clasp, IDLV+wasp, IDLV+clasp. We execute the systems using both a model-guided (BB) (Gebser et al (Reference Gebser, Kaminski, Kaufmann and Schaub2011)) and a unsatisfiable core-guided (USC) (Andres et al. (Reference Andres, Kaufmann, Matheis and Schaub2012)) algorithm, which typically yield complementary performances (Alviano et al. (Reference Alviano, Dodaro, Marques-Silva and Ricca2020)). In brief, model-guided algorithms attempt to iteratively improve lower bound solutions, à la branch & bound, while unsatisfiable core-guided algorithms try to treat all weak constraints as standard (strong) constraints, using unsatisfiable cores found within the optimisation routine to shrink the search space. We consider the bb and oll algorithms for clasp, and the basic and one algorithms for wasp, which are the default for the model-guided and core-guided algorithms in these solvers, respectively. This yields a total of 8 configurations that we run over the 10% of the total instances, selecting 60 instances for each network size, for a total of 600 instances.

Figure 5 shows that, overall, clasp-based configurations outperform all wasp-based configurations in terms of execution times. In particular, the core-guided configuration of the gringo+clasp system (i.e., clingo with default parameters) essentially overlaps with the virtual best solver. Recall that the virtual best solver is a fictitious system that is assumed to perform (instance-wise) as the best among the available solvers. The scatter plots provide an instance-wise comparison of the systems. We can observe in Figure 6 (left) that the default core-guided algorithm outperforms the default model-guided algorithm across all systems. Moreover, Figure 6 (right) confirms that the grounder plays a less important role in our problem, with points distributed along the bisector.

Fig. 5. Solvers comparison.

Fig. 6. Left: a point $(x,y)$ denotes that a given problem instance is solved in $x$ seconds using the model-guided and in $y$ seconds using the core-guided algorithm. Right: a point $(x,y)$ denotes that a given problem instance is solved in $x$ seconds using the IDLV and in $y$ seconds using gringo grounder.

5.2 Assessment of FlexiPlace

From the previous set of experiments the gringo+clasp system (i.e.,, clingo) obtained the best overall performance among the tested configurations. Thus, we focus on that system and perform a more in-depth assessment of our approach on all the generated instances ( $6 \cdot 10^3$ ). We start by discussing the easy instances and then continue with an in-depth analysis of the results in the harder instances. Memory-wise, in all settings, we do not report significant memory usage.

Fig. 7. Mean (solid) and standard error (dashed) on execution time to find the first optimal solution over $I(\cdot , \{5,10,15\})$ using BB (left) and USC (right) algorithms.

Fig. 8. Number of timeouts per application size and network size.

Easy instances. Applications of size up to 15 yield solvable instances for both optimisation techniques. Figure 7 reports average runtime (up to the first optimal solution) over instances $I(\cdot ,\{5,10,15\})$ , where we can observe indeed an exponential-like effect of the application size w.r.t. infrastructure size on the overall runtime regardless of the solving algorithm. Here, BB and USC have similar performances. Overall, this is already sufficient to show applicability of our technique on non-trivial deployments, over realistic-sized infrastructures. We continue our analysis, focusing on deployments with 20, 25 and 30 applications, being these more challenging.

Harder instances. Instances $I(\cdot ,\{20,25,30\})$ yield more interesting behaviour and deserve further analysis. First, we observe in Table 8 that several instances hit the time-limit, with both optimisation algorithms. Figure 9 reports the overall performance of the two optimisation algorithms over these instances, in terms of a cactus plot. Overall, we can observe that these instances are better suited to be solved with USC techniques, as it is able to solve many more instances to optimality. Instance-wise, the scatter plot in Figure 10 confirms the result, usually with USC outperforming BB. However, USC also accrues more and more time-limits as the application size increases.

Temporal Distribution of Sub-optimal Answer Sets in BB. In practical scenarios, obtaining sub-optimal solutions in a fast way might still be useful. Thus, one might be interested in investigating whether sub-optimal solutions are obtained at all, whenever optimal solutions are unavailable. Figure 11 provides a plot on how non-optimal answer sets are found and distributed within allowed runtime when using the model-guided BB algorithm. We observe that overall some solutions (for all instances) are found within the first minute, then answer sets become more sparse, up to timeout – that typically occurs whenever the solver “hits an optimal model,” but is not able yet to certify it as optimal (e.g., proving non-existence of a model with lesser cost).

Overall, USC and BB performance are comparable over 5–10–15 instances, regardless of network size, while USC is generally preferable for “harder” instances in the 20–25–30 range. However, BB is a way to obtain sub-optimal solutions quickly, whereas USC would time-out. We remark that, in a real-world setting, it would be totally feasible to run both approaches in parallel, so as to pick the first (optimal) solution found by either approach.

Fig. 9. Cumulative runtime of BB and USC algorithms over all instances.

Fig. 10. Execution time over instances of size 350 (blue), 400 (red), 450 (orange), and 500 (green) in (a) $I(\{350, 400, 450, 500\}, 20)$ , (b) $I(\{350, 400, 450, 500\}, 25)$ , and (c)  $I(\{350, 400, 450, 500\}, 30)$ . A point $(x,y)$ denotes that the USC algorithm solves an instance in $y$ seconds, while BB solves it in $x$ seconds.

Fig. 11. Temporal distribution of answer sets using the BB algorithm. Each cell reports, in a dotted chart, data about $I(n,k)$ (with label $n$ — $k$ ). A point $(x,y)$ denotes that invoking the ASP solver on the $y$ -th instance of $I(n,k)$ yields a model at time $x$ .

6 Related work

As aforementioned, the problem of deciding how to place application services to cloud-edge nodes in a QoS- and context-aware manner has been thoroughly studied. Here, we focus on the most closely related work, and we refer the readers to recent surveys by Pallewatta et al. (Reference Pallewatta, Kostakos and Buyya2023); Apat et al. (Reference Apat, Goswami, Sahoo, Barik and Saikia2025), and Aït-Salaht et al. (Reference Aït-salaht, Desprez and Lebre2021) for further details.

Many solutions exist that rely on different techniques to determine application placements that meet functional and non-functional requirements. Among these, most of the approaches relied on informed (heuristic) search (Brogi and Forti (Reference Brogi and Forti2017); Gupta et al. (Reference Gupta, Vahid dastjerdi, Ghosh and Buyya2017)), mathematical programming (Skarlat et al. (Reference Skarlat, Nardelli, Schulte, Borkowski and Leitner2017); Mahmud et al (Reference Mahmud, Ramamohanarao and Buyya2020b)), bio-inspired meta-heuristics (Ghobaei-Arani and Shahidinejad (Reference Ghobaei-ARANI and Shahidinejad2022)), and deep learning solutions (Goudarzi et al. (Reference Goudarzi, Palaniswami and Buyya2023)). Different solutions aims at optimising one (or more) aspect(s) of application placements, for example operational costs, latency, energy consumption, and resource usage. Logic programming solutions, mainly written in Prologue, have recently been proposed to tackle the application placement problem, with a focus on aspects such as data locality (Massa et al (Reference Massa, Forti and Brogi2022)), security and trust requirements (Forti et al. (Reference Forti, Ferrari and Brogi2020)), environmental impact (Forti and Brogi (Reference Forti and Brogi2022)), or high-level network intent satisfaction (Massa et al. (Reference Massa, Forti, Paganelli, Dazzi and Brogi2024)). Notably, by classifying intent properties as either hard or soft, the latter approach supports recommending changes to original intents aimed at resolving emerging conflicts.

Forti et al. (Reference Forti, Bisicchia and Brogi2022) relied on continuous reasoning mechanisms to enable incremental updates of solution placements in response to changes in application requirements or infrastructure capabilities, rather than recomputing solutions from scratch. On a similar, yet complementary line, Azzolini et al. (Reference Azzolini, Forti and Ielo2025) proposed a solution combining ASP optimisation and Prologue-based continuous reasoning to distribute container images in cloud-edge settings. ASP is also adopted by Le et al. (Reference Le, Son, Pontelli and Yeoh2017), where the authors addressed the distributed constraint optimisation problem. The constraint-based approach of Amadini et al. (Reference Amadini, Gazza, Soldani, Vitali, Brogi, Forti, Giallorenzo, Plebani, Ponce and Zavattaro2024) complements our solution by addressing sustainable cloud-edge application placement via adaptive service flavour and topology selection under cost and carbon constraints.

Similarly to other declarative programming efforts, FlexiPlace allows modelling constraints including, for example hardware resources, availability, bandwidth, security policies, inter-component latency PUE, and carbon intensity. Differently from all previous work, it features the possibility of automatically relaxing lower-priority constraints when no feasible deployment can be determined. This flexibility goes beyond the state of the art, by implementing a graceful degradation of determined solution placements while guaranteeing critical constraints are met. To the best of our knowledge, FlexiPlace is the first approach integrating logic-based placement with priority-based constraint relaxation.