FREEDA: Adaptive Deployment Toolchain

• FREEDA is a DevOps-oriented toolchain that automates the deployment of microservice-based applications across heterogeneous cloud-edge infrastructures, ensuring failure resilience and carbon-efficient operations.
• It integrates modular components—monitoring, failure and energy enhancers, a harmonizer, and a multi-criteria solver—to continuously optimize deployment plans under evolving operational conditions.
• FREEDA’s constraint optimization model and adaptive algorithms reduce downtime to 0% and lower CO₂ emissions by 21–52%, demonstrating robust performance under stress scenarios.

FREEDA is a DevOps-oriented toolchain designed to automate the deployment of microservice-based applications (MSAs) across heterogeneous and dynamic cloud-edge infrastructures, where operational requirements include failure resilience, carbon-efficient operation, and performance quality of service (QoS). FREEDA continuously adapts its deployment plans to evolving operational conditions—such as resource availability and variations in carbon intensity—by integrating event-driven monitoring, soft constraint enrichment, automated harmonization of competing objectives, and rigorous constraint-based optimization (Ponce et al., 7 Jan 2026).

1. System Architecture and Workflow

FREEDA is modular, comprising four principal components, which together enable closed-loop, adaptive orchestration across the cloud-edge continuum:

• Monitoring: While not part of FREEDA proper, the system relies on external tools—ECLYPSE (for simulation), Kubernetes/Prometheus, and Kepler (for emulation)—to continuously collect logs, failure events, resource utilization, network quality, and power/carbon intensity metrics from the infrastructure.
• Failure Enhancer & Energy Enhancer (Enrichment Phase): These preprocessors transform monitoring data into sets of soft placement constraints (affinity, anti-affinity, avoid). The Failure Enhancer codifies resilience “rules-of-thumb” (e.g., segregate components across nodes to minimize correlated failures), while the Energy Enhancer produces sustainability-directed constraints (e.g., avoid high-carbon nodes, co-locate high-traffic services).
• Harmonizer: Receives the soft constraints from both enhancers and applies policy-driven prioritization—such as “prioritize failure resilience” or “prioritize carbon saving”—to resolve conflicts and output a consistent set of requirements.
• Multi-Criteria Solver (Trade-Off Phase): Integrates the hard infrastructure/MSA requirements with the harmonized soft constraints into a unified constraint optimization model. The solver computes, and where feasible explains, an optimal or minimally disruptive deployment plan.

This architecture operates in discrete loops: after each deployment, new monitoring data trigger reevaluation of constraints, which may prompt re-optimization and reconfiguration to maintain resilience, efficiency, and environmental sustainability under changing conditions.

2. Formal Multi-Objective Optimization Model

At the core of FREEDA is a constraint optimization model with the following constructs:

• Sets and Parameters:
  • $C$: Set of MSA components.
  • $F(c)$: For each $c \in C$, available flavours; each $i \in F(c)$ characterized by importance $\text{imp}(c,i)$, resource requirements $\text{req}_r(c,i)$ over resources $r$ (e.g., CPU, RAM), and per-unit carbon cost $\text{co}_2(c,i)$.
  • $N$: Infrastructure nodes; each $j \in N$ defined by capacities $\text{cap}_r(j)$, current carbon intensity $\text{ci}(j)$, and uptime probability $\text{avail}(j)$.
  • Network parameters: $\text{lat}(j,k)$ and $\text{avail}(j,k)$ (latency and link availability).
  • Communication requirements: $A^{c,s}$ (maximum allowed end-to-end latency between $c$ and $s$).
  • Global budgets for deployment cost ($B_{\text{money}}$) and emissions ($B_{\text{CO}_2}$).
• Decision Variables:
  • $D^c_{i,j}$: Binary, 1 iff component $c$ is deployed as flavour $i$ on node $j$.
• Hard Constraints:

1. Unique assignment: Each $c$ assigned at most one $(i,j)$ pair.
2. Node resource capacities not exceeded.
3. Communication pairs $(c,s)$ must meet latency and availability requirements.
4. Total cost and CO₂ emissions must respect $B_{\text{money}}$, $B_{\text{CO}_2}$.

• Objectives:
  • For initial deployment: maximize total flavour importance, $\sum_{c,i,j} \text{imp}(c,i) D^c_{i,j}$.
  • For adaptation: additionally, maximize preservation of prior assignments, i.e., minimize redeployment churn.

Soft constraints—encoding resilience and carbon-efficiency heuristics—are injected as additional requirements but can be relaxed when infeasible.

3. Adaptation Mechanisms and Algorithms

FREEDA’s adaptivity is achieved by an interplay among enhancers, harmonizer, and solver:

• Failure Enhancer: This component is Prolog-based and analyzes deployment and event logs for patterns suggesting fragility—such as repeated timeouts, overloads, or node/network path disruptions. It generates soft constraints (e.g., anti-affinity, avoid) targeting components and nodes with degraded reliability, informed by institutionalized “rules-of-thumb”.
• Energy Enhancer: Maintains a historical profile knowledge base covering per-service/per-flavour energy use, communication-related overheads, and node carbon intensities. It issues “avoid” constraints targeting high-carbon placements and “affinity” constraints for co-location of services with heavy inter-service traffic to minimize communication-induced emissions.
• Harmonizer: Accepts competing soft constraints and resolves direct conflicts according to user preference (resilience versus energy objectives), ensuring that the prioritized set is internally consistent before integrating with the core model.
• Multi-Criteria Solver Loop: Encodes all hard constraints plus the harmonized set of soft constraints into a MiniZinc model, invoking a CP/MIP solver (Gecode by default) with a runtime cap. In case of unsatisfiability, a drop-and-retry process iterations, progressively removing the least critical soft constraints until a feasible plan is found or no soft constraints remain.

This process ensures the best possible match between deployment objectives and system state at each cycle.

4. Experimental Methodology and Evaluation

Evaluation of FREEDA encompasses both simulated (ECLYPSE) and emulated (Kubernetes/Minikube) experiments:

• Simulation (ECLYPSE):
  • Application: 7-component MSA (Load-balancer, Frontend, API, Redis, Identity Provider, etcd, Database), with each supporting Tiny/Medium/Large flavours.
  • Infrastructure: Two “Public” (cloud) nodes and five “Private” (edge) nodes in a mesh topology.
  • Scenarios: Induced resource exhaustion, sinusoidal energy anomalies.
  • Variants: Simulator’s best-fit, Solver alone, Solver+Energy Enhancer, Solver+Failure Enhancer, complete FREEDA.
  • Metrics: Energy consumption, service downtime, aggregate flavour importance, and relocation counts.
  • Key Results: FREEDA maintained 0% downtime under severe node failures, stabilized energy consumption below baselines post-first round, and maximized flavour importance within carbon and resilience constraints.
• Emulation (Kubernetes/Minikube/Prometheus/Kepler):
  • Application: BrewMonitor, a 4-service MSA with Tiny/Large flavours.
  • Cluster: Seven heterogeneous K8s nodes, some labeled with dynamic carbon intensities.
  • Scenarios: Surges in CPU demand, node-level contention, full node drains, abrupt/smooth carbon intensity changes.
  • Baseline: Native Kubernetes scheduling.
  • Adaptation: FREEDA invoked every five minutes to optimize deployment.
  • Metrics: App Quality (aggregate flavour importance score), downtime (%), total CO₂ emissions.
  • Key Results: In carbon intensity spikes, FREEDA reduced emissions by approximately 35% while maintaining 100% uptime. In node-drain scenarios baseline K8s managed 50% availability, whereas FREEDA restored/maintained 100% availability and reduced emissions by 21–24%.

5. Key Insights, Effectiveness, and Limitations

FREEDA demonstrates that unified flavour and placement optimization, augmented with adaptive, prioritized soft constraints for resilience and sustainability, enables both downtime-free operation and reductions in CO₂ emissions of 21–52% across a variety of stress scenarios relative to best-fit or native scheduling. The incremental objective function—favoring preservation of existing deployments—further mitigates orchestration-induced instability.

The Enhancer→Harmonizer→Solver cycle is robust to both abrupt failures and gradual parameter drifts across the infrastructure. Limitations include the Harmonizer’s restriction to pairwise resolution of soft constraint conflicts and its inability to detect fundamentally unsatisfiable mixes of hard and soft requirements, which defers conflict resolution to iterative solver relaxation. Solver runtimes may increase with infrastructure scale or complexity.

6. Future Developments and Extensibility

Planned extensions for FREEDA include the integration of additional non-functional objectives (e.g., security, cost), elaboration of energy models with real-time grid carbon forecasts, and the creation of “FREEDA Studio”—a comprehensive DevOps interface for graphical specification and dashboard-driven live explanations. This suggests ongoing evolution towards a more comprehensive, explainable, and user-controllable orchestration platform for next-generation cloud-edge deployments (Ponce et al., 7 Jan 2026).