---
title: Demand-Driven Application Management
url: https://www.emergentmind.com/topics/demand-driven-application-management
type: topic
---

# Demand-Driven Application Management

Searching arXiv for recent and relevant papers on demand-driven application/resource management across clusters, microservices, cloud-edge, and related orchestration settings.
Demand-Driven Application Management denotes a class of application-management approaches in which deployment, resource allocation, reconfiguration, and related control actions are driven by observed or anticipated application demand rather than by static reservations, fixed workflows, or permanently provisioned worst-case configurations. Across compute clusters, clouds, microservice systems, fog and edge environments, and demand-side management settings, the unifying premise is that application demand is dynamic, that static allocation is therefore structurally inefficient, and that management logic should adapt online to workload, service-level objectives, queueing effects, user requests, or other demand signals. The literature spans data-driven cluster resizing [1807.00368], probabilistic cloud provisioning under rare bursts [1209.4806], distributed peak-demand minimization [1703.08376], QoS-aware microservice control [2105.13424], closed-loop forecast-and-decision co-optimization [2102.13273], continuum-wide SLO-driven deployment automation [2411.16697], malleable HPC jobs [2005.05910], user-space page management driven by application hints [1910.07566], adaptive process/runtime interfaces for HPC DRM [2403.17107], declarative decentralized fog orchestration [2501.09964], and C-ITS application orchestration through Kubernetes and ROS 2 [2509.18793].

## 1. Conceptual scope and defining characteristics

A recurring motivation in the literature is that demand changes over time while conventional management mechanisms often do not. In compute clusters, resources are commonly reserved for peak demand although peak usage may occur only for a small portion of application lifetime, leading to under-utilization [1807.00368]. In cloud systems, resource costs vary by configuration while workloads can exhibit sudden intense variations and rare extreme events such as buzz or flash crowd effects [1209.4806]. In HPC, jobs are usually submitted with a fixed resource allocation even though cluster demand changes over time, which harms both utilization and turnaround [2005.05910]. In microservices, dependencies between tiers create backpressure and cascading QoS violations, so local utilization signals are inadequate for end-to-end management [2105.13424].

Within this body of work, “demand-driven” consistently implies that management decisions are tied to runtime demand signals rather than to static declarations alone. Those signals differ by domain. In clusters and clouds they include observed resource utilization, workload intensity, and queueing behavior [1807.00368]. In probabilistic provisioning they include time-averaged workload levels and rare-event probabilities over multiple time scales [1209.4806]. In microservices they include per-tier CPU, memory, and network utilization, end-to-end latency history, and candidate next-step resource configurations [2105.13424]. In fog and Cloud-IoT systems they include local request rates, latency to clients, and resource availability, expressed as local facts for decentralized policy evaluation [2501.09964]. In C-ITS they include the requested configuration and the list of requesting entities, which together form the demand on a specific application part at a certain point in time [2509.18793].

A second defining characteristic is that demand-driven management is broader than autoscaling in the narrow sense of adding or removing capacity. The papers include dynamic resource provisioning [1807.00368, 1209.4806], per-tier CPU assignment in microservices [2105.13424], process-count changes in malleable HPC jobs [2005.05910], process-set operations such as grow, shrink, split, union, and replace in dynamic resource management for HPC programming models [2403.17107], page-level caching and prefetching driven by application hints [1910.07566], workflow and schema evolution in description-driven BPM systems [1803.07435], and deployment, reconfiguration, update, upgrade, and scaling in C-ITS application orchestration [2509.18793].

A third common theme is the separation between local demand knowledge and global control objectives. Several papers stress that local application signals alone are insufficient, while a purely system-driven approach lacks application semantics. The HPC DRM design principles explicitly decompose the problem into Dynamic Process Management and Dynamic Resource Allocation/Mapping, so that applications describe process changes while the system decides where resources are assigned [2403.17107]. The DMR API for malleable MPI jobs similarly relies on collaboration between workload manager and parallel runtime [2005.05910]. Sinan’s centralized scheduler uses global application view plus per-tier metrics to choose resource-efficient actions that preserve end-to-end QoS [2105.13424].

## 2. Demand signals, state representations, and control variables

The representation of demand is domain-specific, but the surveyed work reveals several recurring categories.

**Observed resource demand** is central in data-driven cluster management. The mechanism in "A Data-Driven Approach to Dynamically Adjust Resource Allocation for Compute Clusters" monitors resource utilization, forecasts resource demand with quantified uncertainty, and modulates resources assigned to running applications accordingly [1807.00368]. MDP_DT similarly models the environment through a measurement vector over resource-side and workload-side variables, then learns which distinctions matter by adaptive partitioning of the state space [1702.02978].

**Burst and rare-event demand** is central in probabilistic cloud provisioning. In "Dynamic Resource Management in Clouds: A Probabilistic Approach" the key object is the probability of observing a given time-averaged workload over aggregation window \(\tau\), characterized through a large deviations spectrum \(f(\alpha)\) [1209.4806]. This permits threshold policies and capacity margins based not only on expected demand but on the probability of sustained overload.

**End-to-end QoS demand** is central in interactive microservices. Sinan gathers per-tier CPU, memory, and network utilization, end-to-end latency measurements, and workload information such as requests per second every 1 second, then evaluates candidate per-tier CPU allocations with a CNN latency predictor and a Boosted Trees QoS-violation predictor [2105.13424]. The QoS targets in evaluation are 99th-percentile latency \(\le 200 \text{ ms}\) for Hotel Reservation and \(\le 500 \text{ ms}\) for Social Network [2105.13424].

**User- or entity-originated demand** is explicit in C-ITS and fog orchestration. In "Application Management in C-ITS: Orchestrating Demand-Driven Deployments and Reconfigurations" a demand may include which application is demanded, basic application configurations, necessary communication channels, and which C-ITS entities request the application; for a specific application part, the requested configuration and the list of requesting C-ITS entities together form the demand [2509.18793]. In the decentralized fog framework "Declarative Application Management in the Fog. A bacteria-inspired decentralised approach", the local fact
```prolog
requests(ServiceInstanceId, Neighbour, RequestRate, LatencyToClient).
```
encodes request rate and latency from neighboring sources, which directly drive `replicate`, `migrate`, and `undeploy` decisions [2501.09964].

**Application-hint demand** appears in memory management. UMap moves page management to user space so that applications can steer caching, prefetching, eviction, and flushing based on access patterns and storage characteristics, using configurable page size, explicit arbitrary-page prefetch, bounded buffers, and dirty-page watermarks [1910.07566]. Here the “demand” is not merely a page fault; it is the application’s knowledge of which pages matter next and which transfer granularity is appropriate.

**Forecast-driven demand** appears in closed-loop forecast-and-decision systems. "Application-Driven Learning: A Closed-Loop Prediction and Optimization Approach Applied to Dynamic Reserves and Demand Forecasting" argues that forecasting should be optimized with respect to realized downstream application cost rather than standalone statistical loss, formalized as a bilevel problem
\[
\theta_T \in \argmin \limits_{\theta \in \Theta, \hat{y}_t,z_t^{*} \quad  \frac{1}{T} \sum_{t \in \mathbb{T}} G_a(z_t^{*}, {y}_t)
\]
subject to
\[
\hat{y}_t = \Psi (\theta, x_t), \qquad
z_t^{*} \in \argmin_{z \in Z }  G_p(z, \hat{y}_t)
\]
[2102.13273]. This recasts demand management as a closed loop in which prediction and action are co-optimized.

## 3. Architectural patterns and implementation models

Despite wide variation in domain, the papers converge on a small number of architectural patterns.

One pattern is the **monitor–predict–act loop**. The cluster mechanism of [1807.00368] monitors utilization, forecasts demand and confidence, and adjusts allocations. Sinan collects metrics every second, predicts near-term latency and later QoS violation probability, and chooses the least-resource safe action [2105.13424]. The continuum resource manager in [2411.16697] continuously monitors SLOs, validates deployments with the Monitoring and Alerting Verticles, and reacts to violations within an evaluation interval of 5 s.

A second pattern is **declarative desired-state reconciliation**. In C-ITS, the application manager translates deployment requests into Kubernetes custom resources, and custom operators reconcile changing and new demands using bookkeeping to derive a new desired application state [2509.18793]. This explicitly extends Kubernetes’ reconciliation loop from infrastructure resources to the application level. The fog framework in [2501.09964] is also declarative, but with Prolog rules at each decentralized agent instead of a centralized Kubernetes control plane.

A third pattern is **cooperation between application/runtime and system scheduler**. The DMR API for malleable MPI jobs exposes reconfiguration points through `dmr_check_status` or `dmr_icheck_status`, while Slurm returns `expand`, `shrink`, or `none` depending on spare resources and queued jobs [2005.05910]. The HPC DRM design-principles paper generalizes this into process-centric interfaces with Process Sets (PSets), PSet operations, and a Cooperative Optimization Language associated with those operations [2403.17107].

A fourth pattern is **surrogate or latent-model control**. Sinan’s CNN produces latent representation \(L_f\), which is then used both for latency prediction and by the Boosted Trees QoS-violation classifier [2105.13424]. The Stackelberg DSM paper estimates a projected-affine user-response model
\[
x^*(y)=\mathrm{proj}_C(\Theta_Ay-\Theta_b)
\]
from observed user actions and then solves a learned surrogate bilevel problem to accelerate tariff search [2605.00588]. MDP_DT uses a decision-tree abstraction over measured telemetry to create an adaptive state representation for a full-model MDP [1702.02978].

## 4. Core methodological families

Demand-driven application management in the surveyed literature can be organized into several methodological families.

### 4.1 Data-driven demand forecasting with uncertainty

The compute-cluster mechanism of [1807.00368] represents a forecasting-based family. It employs a data-driven approach to resource-demand forecasting, with quantification of uncertainty, and uses predicted demand and confidence to modulate cluster resources while preventing failures due to finite-resource contention such as RAM [1807.00368]. The abstract reports more than one order of magnitude reduction in turnaround time while keeping application failures under control [1807.00368].

A related but more formal probabilistic approach appears in [1209.4806]. For a finite irreducible continuous-time Markov process and observable \(\Phi\), the paper studies
\[
\frac{1}{\tau}\cdot\int_{0}^{\tau} \Phi(X_s) d s
\]
and derives a large-deviation principle
\[
\lim_{\epsilon\to0} \lim_{\tau\to\infty} \frac{1}{\tau} \log P \left\{  
\int_{0}^{\tau} \Phi(X_s) d s \in [\alpha - \epsilon, \alpha+\epsilon]  
\right\} = f(\alpha).
\]
For the VoD use case, \(\Phi(N_I(t),N_R(t))=N_I(t)\), so \(\alpha\) is the time-averaged number of active viewers [1209.4806]. This supports reconfiguration timescale selection and capacity-margin sizing through quantities such as
\[
\tau^* = \max\{\tau : \mathbb{P}{\{ \langle i \rangle_{\tau} \geq \alpha^* \} }  \geq \sigma^*\}.
\]

### 4.2 Distributed optimization for peak-demand management

The smart-grid DSM paper [1703.08376] studies distributed minimization of
\[
\min_{x^1,\ldots,x^N}\: \max_{s \in \{1,\ldots,S\}} \sum_{i=1}^N g_{is}(x^i_s)
\quad \text{subj. to } x^i\in X_i,
\]
with double coupling across devices and across time. Through a sequence of primal/dual reformulations, it derives local convex problems
\[
\min_{x^i,\rho^i}\: \rho^i \quad \text{subj. to } x^i\in X_i,\ 
g_{is}(x^i_s)+\sum_{j\in\mathcal N_i}(\lambda^{ij}-\lambda^{ji})_s \le \rho^i
\]
and dual updates
\[
\lambda^{ij}(t+1)=\lambda^{ij}(t)-\gamma(t)\big(\mu^i(t+1)-\mu^j(t+1)\big).
\]
This family is not forecasting-based but optimization-based: demand enters as coupled convex costs to be coordinated across agents.

### 4.3 QoS-aware prediction-driven microservice management

Sinan is a representative microservice family. It uses a CNN for next-interval tail-latency prediction and Boosted Trees for later QoS-violation prediction, operating every second [2105.13424]. It evaluates a restricted candidate action space such as scale down one tier, hold current allocation, scale up one tier, scale up all tiers, or scale up recent victim tiers, with CPU change steps of 0.2 up to 1.0 CPU or 10%/30% service CPU changes [2105.13424]. Candidate actions are filtered by predicted latency exceeding \(QoS - RMSE_{valid}\) and then by violation probability thresholds \(p_d < p_u\), after which the least-resource acceptable action is chosen [2105.13424].

The CNN is trained with squared loss
\[
\mathcal{L}(X, \hat{y}, W) = \sum_i^n (\hat{y_i}-f_W(x_i))^2
\]
and, in the more detailed version of the work, achieves validation RMSE of 14.7 ms for Hotel Reservation and 26.4 ms for Social Network [2105.13424]. The paper reports that Sinan always meets QoS on the evaluated applications while using less CPU than other QoS-meeting methods; for example, on Hotel Reservation it uses 25.9% less CPU on average and up to 46.0% less, and on Social Network it reduces CPU usage by 59.0% on average and up to 68.1% [2105.13424].

### 4.4 Closed-loop prediction-and-decision co-optimization

The application-driven learning framework [2102.13273] belongs to a distinct family in which forecasts are learned against downstream decision cost. It proves that
\[
\lim_{T\to\infty}d(\theta_{T},S^{*}) =0
\]
with probability 1 under the paper’s assumptions, where
\[
S^{*} =\textup{argmin}_{\theta\in\Theta}\,\mathbb{E}\big[G_a\big(\zeta(\Psi(\theta,X)),Y\big)\big].
\]
Empirically, on PG-LIB-OPF systems the Opt-Opt configuration improves out-of-sample cost over LS-Ex by between \(2.01\%\) and \(12.89\%\), with average gain \(8.42\%\) [2102.13273]. This family suggests that demand-driven management may require changing the learning objective itself, not just the runtime controller.

### 4.5 Runtime malleability and process-centric DRM

The HPC strand includes DMR API [2005.05910] and the DRM design-principles paper [2403.17107]. DMR API exposes application-level malleability at safe points and lets the scheduler decide whether to expand, shrink, or keep current size. On a 400-job workload, synchronous malleable execution achieved average resource utilization 93.909% versus 83.607% for fixed execution, average waiting-time gain 27.980%, and average completion-time gain 12.786% despite a negative execution-time gain of \(-58.482\%\) due to shrinking jobs from performance-optimal size [2005.05910]. Across workloads of 50, 100, 200, and 400 jobs, flexible workloads reduced waiting and completion times substantially even though execution times increased [2005.05910].

The design-principles paper abstracts this into Process Sets and PSet operations such as ADD, SUB, SPLIT, UNION, DIFFERENCE, INTERSECTION, GROW, SHRINK, and REPLACE, plus a Cooperative Optimization Language attached to those operations [2403.17107]. This generalizes demand-driven management beyond ad hoc grow/shrink APIs.

### 4.6 User-space, application-driven data/memory management

UMap [1910.07566] shows that demand-driven management can target page placement and movement rather than coarse resources. Using `userfaultfd`, manager threads, filler threads, evictor threads, and a store-object abstraction, it lets applications control page size, prefetch, eviction, and flushing per region. The paper reports performance improvements of 1.25× to 2.5× over the system service, with 2.5× speedup for out-of-core sort at 8 MiB page size and 1.8× for BFS at 512 KiB [1910.07566].

### 4.7 Declarative and decentralized policy-based orchestration

The fog paper [2501.09964] represents a decentralized family. Policies are Prolog rules of the form
```prolog
operation(OperationId, ServiceInstanceId, TargetNode) :- TriggeringCondition.
```
and use facts such as `service`, `node`, `serviceInstance`, `requests`, and `inhibited` [2501.09964]. Local agents can `replicate`, `migrate`, or `undeploy`, and global behavior emerges from accepted local actions. In simulation over Rome taxi traces with 81 AP handovers, the system reacts within 1–2 management cycles on average, and correlations between user handovers and management operations include \(r = 0.597\) for workload-sensitive apps under Policy 1 and \(r = 0.985\) for latency-sensitive apps under Policy 2 [2501.09964].

### 4.8 Kubernetes-based demand reconciliation at the application level

The C-ITS framework [2509.18793] uses a ROS 2 action interface for deployment requests, an application manager to translate those requests into Kubernetes custom resources, and custom operators with bookkeeping to reconcile overlapping, time-shifted demands. In the collective perception use case, object detection and object fusion services are deployed on demand when vehicles approach an intersection; existing services are reused rather than redeployed when later requesters arrive; and shared services are only shut down when no requesters remain [2509.18793].

## 5. Representative systems and empirical evidence

The following table organizes representative systems by domain and demand signal.

| System | Domain | Demand signal and action |
|---|---|---|
| Compute-cluster forecasting [1807.00368] | Compute clusters | Utilization forecasting with uncertainty; modulate assigned resources |
| Probabilistic VoD provisioning [1209.4806] | Cloud networking / VoD | Large-deviation workload analysis; choose reconfiguration timescale and capacity margin |
| Sinan [2105.13424] | Interactive microservices | Per-tier telemetry, latency history, candidate CPU allocations; choose least-resource safe action |
| DMR API [2005.05910] | HPC | Queue pressure and spare resources; expand, shrink, or keep current process count |
| UMap [1910.07566] | Data-intensive HPC / storage | Application access hints, page faults, backend characteristics; prefetch, evict, flush, resize regions |
| Continuum resource manager [2411.16697] | Edge–cloud continuum | SLO monitoring and threshold validation; alert and support corrective orchestration |
| Declarative fog management [2501.09964] | Fog / Cloud-IoT | Local requests, latency, available hardware; replicate, migrate, undeploy |
| C-ITS application manager [2509.18793] | C-ITS | Requested configuration plus requester set; deploy, reconfigure, update, scale, shut down |

Several quantitative findings recur across these systems. Compute-cluster forecasting reports turnaround-time reduction by more than one order of magnitude [1807.00368]. Sinan reports always meeting QoS in evaluation while maintaining high utilization and reducing CPU usage relative to alternative QoS-meeting methods [2105.13424]. UMap reports 1.25× to 2.5× performance improvement over `mmap` with adapted configurations [1910.07566]. The continuum resource manager detects SLO violations in 0–5 s because the evaluation interval is 5 s [2411.16697]. Malleable HPC execution improves average waiting and completion times at workload scale [2005.05910]. The closed-loop forecasting paper reports large-system out-of-sample cost improvements averaging 8.42% [2102.13273].

## 6. Common design principles

A set of cross-cutting design principles emerges from the literature.

**Demand should be represented at the right abstraction level.** In some systems the relevant state is instantaneous resource usage; in others it is a time-averaged workload over a horizon [1209.4806], a requester set and configuration [2509.18793], or an application-specific access pattern [1910.07566]. This suggests that demand-driven management is less about one universal signal than about exposing the control-relevant demand variable for a given domain.

**Static thresholds are usually insufficient.** This is explicit in elasticity papers such as MDP_DT, which motivates adaptive state-space partitioning by the difficulty of identifying correct metrics and thresholds in advance [1702.02978], and in microservices, where utilization thresholds are shown to be unreliable proxies for end-to-end latency [2105.13424].

**Application semantics matter.** The DMR API requires applications to expose safe reconfiguration points and redistribution logic [2005.05910]. UMap relies on application hints [1910.07566]. The BPM paper relies on runtime-interpreted, versioned descriptions of workflows and schemas [1803.07435]. The fog paper relies on application-specific declarative policies [2501.09964]. This suggests that purely infrastructure-driven orchestration is often too weak.

**Global objectives still require system-level control.** Cooperative interfaces in HPC [2403.17107], centralized cluster scheduling in Sinan [2105.13424], and the application manager in C-ITS [2509.18793] all preserve a system-level role in reconciling multiple demands and resources.

**Prediction without downstream coupling can be misaligned.** This is the explicit thesis of application-driven learning [2102.13273], but it also underlies Sinan’s use of future QoS-violation prediction rather than myopic latency-only prediction [2105.13424].

**Runtime bookkeeping is indispensable when demands overlap in time.** The C-ITS framework’s custom operators store which entities request which application part and its dynamic configurations [2509.18793]. The fog paper stores inhibited operations to avoid retrying impossible actions [2501.09964]. DMR maintains queue-aware decisions across running and pending jobs [2005.05910].

## 7. Misconceptions and points of contention

One common misconception is that demand-driven management is equivalent to threshold autoscaling. The surveyed work suggests otherwise. Threshold triggers are only one possible policy mechanism, and several papers argue they are difficult to configure or structurally inadequate [1702.02978, 2105.13424]. Demand-driven systems may instead use forecasts [1807.00368], probabilistic large-deviation analysis [1209.4806], distributed optimization [1703.08376], learned surrogate models [2605.00588], or declarative logical policies [2501.09964].

A second misconception is that demand-driven management necessarily requires centralized optimization. The fog paper explicitly proposes a fully decentralized approach [2501.09964], while HPC DRM proposes cooperative interfaces rather than centralized direct control of all process semantics [2403.17107]. At the same time, some domains do benefit from central control, as in Sinan and Kubernetes-based C-ITS management [2105.13424, 2509.18793]. This suggests that centralization is an architectural choice, not a defining property.

A third misconception is that better predictive accuracy always yields better management. The freezer DSM paper shows the opposite in a controlled setting: the nonlinear Model E has the best predictive accuracy, but the third-order linear Model C is better for MPC because it yields a convex optimization problem and better control performance [1510.06855]. This suggests a broader principle: model tractability and control alignment may matter as much as raw forecast fidelity.

A fourth misconception is that demand-driven management is only about resource quantity. Several papers manage topology, communication channels, workflow definitions, or page movement rather than just CPU count [1910.07566, 1803.07435, 2509.18793].

## 8. Limitations and open directions

The literature also reveals recurring limitations.

Many systems rely on **offline training or profiling**. Sinan requires deliberate offline data collection, taking 8.7 hours for Hotel Reservation and 16 hours for Social Network [2105.13424]. Application-driven learning can overfit with small samples in more flexible model classes [2102.13273]. MDP_DT needs stored experience and careful split-threshold calibration [1702.02978].

Several systems are **resource-specific**. Sinan mainly controls CPU, while memory is provisioned at maximum profiled usage [2105.13424]. The continuum resource manager provides strong SLO monitoring and deployment automation, but its autonomous reallocation policy is under-specified [2411.16697]. The C-ITS paper focuses on a collective perception use case and does not provide quantitative contention-resolution or priority schemes [2509.18793].

Some frameworks provide **substrates rather than full policy solutions**. The HPC DRM design-principles paper defines interfaces and abstractions but does not report quantitative performance metrics [2403.17107]. The BPM paper provides a strong metadata and provenance architecture for runtime evolution, but says little about resource elasticity or SLOs [1803.07435].

Decentralized systems may sacrifice **global optimality**. The fog framework reacts locally and scales by decentralization, but it does not optimize a global objective or provide strong global convergence guarantees [2501.09964]. This suggests a design trade-off between scalability and global coordination.

A plausible implication is that future work will increasingly combine the strengths of these families: declarative application semantics, probabilistic or learned demand models, control-theoretic or optimization back ends, and runtime reconciliation infrastructure. The most explicit examples already point in that direction: closed-loop forecast learning [2102.13273], learning-assisted Stackelberg incentive design [2605.00588], and QoS-aware microservice control [2105.13424].

## 9. Synthesis

Demand-Driven Application Management is best understood not as a single algorithmic technique but as an organizing principle for managing applications under dynamic demand. The principle is that management decisions should be induced by the current or anticipated demand state that actually matters for the application and the system’s objectives. In the surveyed work, this leads to several concrete forms: utilization forecasting with uncertainty in compute clusters [1807.00368], large-deviation provisioning over time scales [1209.4806], distributed peak-demand optimization [1703.08376], end-to-end QoS-aware per-tier control in microservices [2105.13424], bilevel co-optimization of forecasts and operational plans [2102.13273], SLO-aware deployment automation across the continuum [2411.16697], runtime malleability and process-set control in HPC [2005.05910, 2403.17107], application-driven page management [1910.07566], decentralized rule-based fog orchestration [2501.09964], and Kubernetes-based reconciliation of overlapping application demands in C-ITS [2509.18793].

Taken together, these works suggest that demand-driven application management is fundamentally about closing the loop between application demand, system observation, and adaptive control, while preserving enough application semantics to make those controls meaningful. Whether realized through MDPs, bilevel optimization, machine learning, declarative policies, or runtime interfaces, the field is defined by that closed-loop relationship between evolving demand and evolving application state.

Source: https://www.emergentmind.com/topics/demand-driven-application-management