# AdaptiFlow: An Extensible Framework for Event-Driven Autonomy in Cloud Microservices

Brice Arléon Zemtsop Ndadji, Simon Bliudze, Clément Quinton

► To cite this version:

Brice Arléon Zemtsop Ndadji, Simon Bliudze, Clément Quinton. AdaptiFlow: An Extensible Framework for Event-Driven Autonomy in Cloud Microservices. Proceedings of the First Workshop on Adaptable Cloud Architectures (WACA 2025), Giuseppe De Palma; Saverio Giallorenzo, Jun 2025, Lille, France. pp.123-147, 10.4204/EPTCS.438.7 . hal-05074243

HAL Id: hal-05074243

https://hal.science/hal-05074243v1

Submitted on 7 Jan 2026

**HAL** is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# AdaptiFlow: An Extensible Framework for Event-Driven Autonomy in Cloud Microservices

## Brice Arléon Zemtsop Ndadji

Univ. Lille, CNRS, Inria, Centrale Lille, UMR 9189 CRISTAL, F-59000 Lille, France

brcie-arleon.zemtsop-ndadji@inria.fr

## Simon Bliudze

Univ. Lille, Inria, CNRS, Centrale Lille, UMR 9189 CRISTAL, F-59000 Lille, France

simon.bliudze@inria.fr

## Clément Quinton

Univ. Lille, CNRS, Inria, Centrale Lille, UMR 9189 CRISTAL, F-59000 Lille, France

clement.quinton@inria.fr

Modern cloud architectures demand self-adaptive capabilities to manage dynamic operational conditions. Yet, existing solutions often impose centralized control models ill-suited to microservices' decentralized nature. This paper presents **AdaptiFlow**, a framework that leverages well-established principles of autonomous computing to provide abstraction layers focused on the **Monitor** and **Execute** phases of the MAPE-K loop. By decoupling metrics collection and action execution from adaptation logic, AdaptiFlow enables microservices to evolve into autonomous elements through standardized interfaces, preserving their architectural independence while enabling system-wide adaptability. The framework introduces: (1) **Metrics Collectors** for unified infrastructure/business metric gathering, (2) **Adaptation Actions** as declarative actuators for runtime adjustments, and (3) a lightweight **Event-Driven** and rule-based mechanism for adaptation logic specification. Validation through the enhanced **Adaptable TeaStore** benchmark demonstrates practical implementation of three adaptation scenarios targeting three levels of autonomy—self-healing (database recovery), self-protection (DDoS mitigation), and self-optimization (traffic management)—with minimal code modification per service. Key innovations include a workflow for service instrumentation and evidence that decentralized adaptation can emerge from localized decisions without global coordination. The work bridges autonomic computing theory with cloud-native practice, providing both a conceptual framework and concrete tools for building resilient distributed systems. Future work includes integration with formal coordination models and application of adaptation techniques relying on AI agents for proactive adaptation to address complex adaptation scenarios.

**Keywords:** self-adaptive systems, cloud microservices, MAPE-K loop, decentralized adaptation, autonomic computing, adaptive workflows

## 1 Introduction

Modern cloud architectures face growing complexity due to their distributed nature, necessitating systems that autonomously adapt to dynamic conditions. The MAPE-K loop [20] (Monitor-Analyze-Plan-Execute-Knowledge) has long served as the foundation for self-adaptive systems, traditionally implemented as a centralized, reactive, and sequential loop for executing adaptations [36]. However, the decentralized nature of microservice-based applications demands a paradigm shift toward separating functional and adaptation concerns. Drawing inspiration from hardware abstraction layers (HALs) in operating systems, this paper introduces an abstraction layer focused on the **Monitor** and **Execute** phases
of MAPE-K, enabling microservices to expose observable data and to accept control commands without invasive code changes. As envisioned in the seminal paper by Kephart and Chess [20], this approach ensures "the managed element can be adapted to enable the autonomic manager to monitor and control it," bridging the gap between non-adaptive systems and self-managing elements.

We present AdaptiFlow, a framework providing standardized interfaces to instrument microservices for self-adaptation. AdaptiFlow's architecture is designed to address the unique challenges of self-adaptive systems in cloud-native environments, where decentralization, scalability, and context-awareness are critical. Self-adaptive systems are capable of dynamically altering their structure and behavior during runtime by continuously evaluating their environment, internal state, and operational goals [26]. For instance, consider a microservice that responds to a sudden workload increase by disabling non-essential functionalities. An online retailer, for example, might temporarily deactivate its computationally intensive recommendation engine during peak traffic periods. Such adaptations enable the system to preserve Key Performance Indicators (KPIs, e.g. latency, CPU, and memory usage) despite fluctuating demands. To build a self-adaptive system, developers must encode logic that defines the data to observe (e.g. performance metrics), the events (e.g. traffic increase, service unavailable, DDoS Attack), the conditions triggering adaptation, and the specific mechanisms for executing those changes. AdaptiFlow's core abstraction layer comprises:

* **Metrics Collectors:** Unified APIs to gather infrastructure (CPU, latency) and business-level metrics (cache hits, transaction rates).

* **Adaptation Actions:** Declarative interfaces to define infrastructure-level (e.g. scaling) and business-level (e.g. feature toggling) actuators.

By decoupling monitoring and execution from adaptation logic, AdaptiFlow enables diverse strategies for analysis and planning. Developers can implement:

* **Internal Logic:** Rule-based adaptations (e.g. threshold-driven events) embedded directly into services.

* **Exogenous Logic:** External agents or planners (e.g. AI agents) leveraging AdaptiFlow's interfaces to collect metrics and execute actions.

To validate this approach, AdaptiFlow incorporates event-driven concepts that enable rule-based adaptation logic. The framework provides *Event Observation* mechanisms to detect threshold-based (e.g. CPU > 80%) or custom events (e.g. service degradation patterns) through periodic polling or on-demand triggers. These events act as semantic bridges between raw metrics and actionable adaptations, allowing developers to declaratively specify *when* and *how* the system should respond to changing conditions.

We validate AdaptiFlow on the *Adaptable TeaStore Benchmark* [2, 6]. Adaptable TeaStore is an extension of the TeaStore microservices benchmark [42] supporting autonomous behaviour and specifying adaptation scenarios [2]. An implementation of the benchmark is available [6] for evaluating different approaches to adaptation. We apply AdaptiFlow to that implementation to realise the adaptation scenarios specified in [2]. Our experiments demonstrate AdaptiFlow's practicality through three implemented adaptation scenarios targeting three levels of autonomy: self-healing (service recovery), self-protection (DDoS mitigation), and self-optimization (traffic management) with minimal code changes.

**Key Contributions:**

* Design and validation of an abstraction layer for the Monitoring and Execution phases of the MAPE-K loop, transforming non-adaptive services into autonomic elements
* A workflow to instrument microservices with metric collectors and with actuators

* Empirical validation through the *Adaptable TeaStore*

The rest of the paper is structured as follows. Section 2 presents the state of the art, Section 3 outlines the framework design. Section 4 details experimental results with the Adaptable TeaStore case study. Section 5 concludes the paper.

## 2 State of the art

Modern computing systems are evolving toward autonomic paradigms, where components manage their behavior autonomously to reduce human intervention. Inspired by biological systems, the vision of autonomic computing [20] envisions distributed networks of *autonomic elements*, self-managing entities that deliver services while adhering to predefined policies. Each element consists of a *managed resource* (e.g. a database, CPU, or microservice) and an *autonomic manager* that monitors and controls it. Over time, the distinction between manager and managed resource may dissolve [20], yielding fully integrated elements capable of independent decision-making while collaborating through decentralized interactions.

More broadly, the evolution of self-adaptive systems, as chronicled by Weyns [43], can be understood through seven successive waves of research focus. These waves encompass: (1) *Automating Tasks* with external managers [30, 20, 7], (2) *Architecture-based Adaptation* for separation of concerns [12, 22, 44], (3) the use of *Runtime Models* for reasoning [1, 28, 41], (4) *Requirements-driven* design [45, 39, 14], (5) providing *Guarantees under Uncertainty* [4, 27, 5], (6) *Control-based* adaptation for theoretical guarantees [13, 10, 38, 23], and (7) *Learning from Experience* with machine learning [9, 8, 17, 32]. This historical context frames the fundamental paradigms that influence the design of AdaptiFlow. Our work embraces the push toward separation of concerns, decentralization, and requirements-driven design. We argue that to realize these goals in modern cloud-native environments, an abstraction layer for adaptation logic analogous to a hardware abstraction layer is needed. AdaptiFlow aims to provide such a layer, built upon the established principles of the MAPE-K control loop [20], and rule-based adaptation techniques [35]. These concepts are essential for managing complex distributed systems, from early monolithic architectures to modern cloud-native environments. Figure 1 provides a visual summary of the MAPE-K reference model that underpins much contemporary adaptation research.

The Monitor-Analyze-Plan-Execute over a shared Knowledge (MAPE-K) loop (Fig. 1), introduced over two decades ago by Kephart et al. [20], remains a cornerstone of self-adaptive systems. It structures adaptation into four phases:

* Monitor: Observes the system's internal state and environment (e.g. CPU usage, request latency).

* Analyze: Evaluates observations to identify adaptation needs (e.g. detecting service failures).

* Plan: Generates strategies to achieve desired states (e.g. scaling instances, enabling circuit breakers).

* Execute: Implements selected adaptation actions.

<figure><img src="image_2.png" /><figcaption>Figure 1: The MAPE-K loop</figcaption></figure>
A shared **Knowledge (K) repository** stores contextual data (e.g. metrics, policies) to support decision-making across phases. Originally applied to monolithic systems, MAPE-K has since been adapted for cloud computing [24, 19, 26], IoT [29, 33], and cybersecurity [16, 18, 40].

Rule-based systems like Drools [35] can be used to operationalize the **Analyze** and **Plan** phases of MAPE-K by codifying adaptation logic into declarative condition-action pairs. A rule's structure "when *condition*, then *action*" enables developers to declaratively specify behaviors (e.g. "when CPU > 80%, then scale instances"). Unlike traditional code, rules are modular, auditable, and dynamically updatable, making them ideal for scenarios requiring rapid adjustments (e.g. fraud detection, load management). For example, Drools filters data through conditions and triggers actions when matches occur. This approach bridges technical and business requirements, allowing non-developers to contribute to adaptation policies.

Complementary to centralized frameworks, Gru [11] introduces a decentralized autonomic approach for microservices based on agents. Each *Gru-Agent* embeds a local MAPE loop and independently manages a set of Docker containers on a node. Decisions such as scaling or migrating microservices are taken based on local and partial neighborhood state information, improving fault tolerance. Gru's autonomy layer wraps microservices without modifying their internals. This design shares goals with AdaptiFlow (flexibility, separation of concerns), but Gru operates closer to the infrastructure level, making it a valuable complement for decentralized adaptation logic.

Recent contributions explore increasingly specialized mechanisms to improve system resilience. For example, Sedghpour et al. [37] investigate circuit-breaking strategies embedded directly into the service mesh layer. Leveraging control theory, their adaptive controller dynamically adjusts queue limits to maintain response time guarantees under stress conditions.

While frameworks such as Drools and agent-based solutions like Gru have significantly simplified the expression of adaptation logic, we take on the challenge of providing a lightweight solution in the form of a reusable abstraction layer that exposes standard interfaces for both service monitoring and adaptation execution—spanning infrastructure-level and application-level concerns. This abstraction explicitly focuses on separating functional responsibilities from adaptation logic in cloud microservice systems. Unlike traditional frameworks, our approach does not impose a specific MAPE control pattern; rather, it grants developers the flexibility to adopt the integration pattern that best fits their needs. Moreover, it facilitates the construction of benchmarks of self-adaptive microservices on which adaptation approaches such as Sedghpour et al. [37] can be implemented and compared.

## 3 Framework Design

AdaptiFlow's architecture envisages autonomous management for cloud-native systems through a decomposition of the MAPE-K loop. Our design introduces a modular approach based on two key principles: (1) standardization of observation and actuation interfaces, and (2) flexible integration of various adaptation strategies. This separation allows microservices to retain their architectural independence while participating in system-wide adaptation models. Figure 2 provides a visual illustration of the AdaptiFlow specification within autonomic managers. This illustration showcases AdaptiFlow's flexibility, deployed here in a decentralized architecture where each autonomic element manages its own adaptation logic. The same abstraction layer can alternatively support a centralized coordination model, as demonstrated by the database recovery scenario in Section 4.2.
## Architectural Overview

AdaptiFlow provides a set of directives to specify the adaptation logic. The framework operationalizes the MAPE-K loop by focusing on two phases **Monitor** and **Execute** tailored for decentralized cloud environments. We intentionally omit the **Analyze** and **Plan** phases since our goal is to allow the separation of concerns. However, in order to allow closing the loop, we do provide the mechanism for triggering actions when a corresponding condition is satisfied using an event-driven methodology. This is a lightweight implementation of the analysis and planning phases, which originally involve assessing the microservices execution context, identifying the system's adaptation needs, and finally generating adaptation strategies in order to achieve the adaptation objective. Since our solution is provided in the form of a Java library, it allows for the specification of arbitrary custom adaptation strategies. However, it intentionally does not provide any dedicated syntax or abstraction (a domain-specific language for adaptation) for that purpose. These are left for separate future work.

In the **Monitor** phase, metrics collectors continuously gather infrastructure (e.g. CPU, memory) and business-level (e.g. request rates, service states) data, providing real-time insights into system state. For example, a **LatencyCollector** might track API response times, while a **ResourceUsageCollector** monitors cloud resource availability.

The **Execute** phase then invokes predefined or custom adaptation actions, such as scaling services via Kubernetes (ScaleService) or disabling non-critical features like recommendations (*EnableFall-backAlgorithm*). AdaptiFlow uses a decentralized decision-making through event subscriptions: services subscribe to relevant events (e.g. an auth service subscribing to `DDoSAttackEvent`).

The **Analyze** phase employs conditional evaluators to interpret the data collected, detecting events such as HighWorkloadEvent (request rate > 1,000/s OR CPU > 80%) or ServiceFailureEvent (health check timeout). These evaluators apply threshold-based rules (e.g. CPU > 80%) or custom logic (e.g. apply more complex tests to the given metric) to determine adaptation triggers.

The shared **Knowledge (K)** is derived dynamically from distributed metrics rather than a static repository. This approach offers three key advantages: (1) *Decentralized control*, enabling parallel adaptations; (2) *Transparency*, as rules and events are explicitly defined and auditable; and (3) *Flexibility*, supporting hybrid adaptations that combine infrastructure adjustments (scaling) with business logic changes (feature toggling). AdaptiFlow distributes adaptation logic across microservices, aligning with their autonomous nature. This design choice enables granular, context-driven adaptations.

To realize this architecture, AdaptiFlow decomposes the adaptation process into six modular components (Fig. 2), each addressing a distinct aspect of self-adaptation. The (Fig. 3) describes the interactions between those components:

* **Metrics Collectors** (Perception of the Environment): gather infrastructure and business-level metrics (e.g. CPU usage, API latency) to establish a real-time view of the context.

* **Adaptation Actions** (Executing Change): translate decisions into runtime adjustments, ranging from infrastructure operations (e.g. scaling) to business logic modifications (e.g. enabling fallback algorithms).

* **Event Management**: the events are specified using conditional evaluators, then services or service components subscribe to them and the event observation starts. When the conditions specified in the event conditional evaluator are met, the event is triggered and the event subscribers are notified.

- **Conditional Evaluators** (Adaptive Decision-Making): apply threshold-based or custom logic (e.g. "IF cache hit ratio < 20% AND peak hour") to determine when events should
<figure><img src="image_3.png" /><figcaption>Figure 2: AdaptiFlow specification within autonomic managers of a decentralized architecture, emphasizing modular components for metrics collection, adaptation action execution, and event handling.</figcaption></figure>
<figure><img src="image_4.png" /><figcaption>Figure 3: Sequence diagram illustrating runtime interactions between AdaptiFlow components</figcaption></figure>

trigger and also when subscribers should be notified to execute adaptations. Conditional
Evaluators are part of the specification of both events and event subscribers.

- **Event Specification** (Contextual Awareness): defines the structure of an event by the use of conditional evaluators on the collected metrics (e.g. `ResourceExhaustionEvent = CPU > 90% && FreeDisk < 10%`). Developers implicitly specify event types (threshold-based or custom) and their triggering criteria, enabling precise alignment with adaptation goals.

- **Event Subscription**: enables services or service components to declaratively register interest in specific events (e.g. a billing service subscribing to `HighErrorRateEvent`).

- **Event Observation** (Contextual Awareness): Implements strategies to detect specified events, such as periodic polling (e.g. check CPU every 30 seconds) or on-demand triggers (e.g. API failure webhook). This component ensures timely responses to gradual trends (e.g. memory leaks) and sudden anomalies (e.g. DDoS attacks).

The following sections detail how these components collectively enable granular, context-aware
adaptations while adhering to microservices' decentralized ethos. By decoupling data collection, event
detection, and action execution, AdaptiFlow allows developers to specify and gradually extend the adap-
tation logic without making major architectural changes.
## Metrics Collectors: Perception of the Environment

The foundation of self-adaptation lies in accurate perception. AdaptiFlow's *Metrics Collectors* are designed to gather both infrastructure-level (e.g. CPU, memory) and business-level metrics (e.g. transaction success rates, cache hit ratios). This dual focus ensures adaptations account for technical constraints and domain-specific requirements. For example, a *LatencyCollector* might monitor API response times, while a *CartAbandonmentCollector* tracks user behavior. Collectors enable services to expose their context for adaptation purposes. Once the collectors have been defined, it's easy to support both pull mechanisms (e.g. Prometheus) and push mechanisms (e.g. REST webhooks), accommodating diverse monitoring ecosystems. By decoupling data collection from analysis, AdaptiFlow allows developers to incrementally instrument services without overhauling existing systems.

## Adaptation Actions: Executing Change

Adaptation actions translate decisions into runtime changes. AdaptiFlow enables the specification of adaptation actions that impact the:

* **Infrastructure-Level**: Platform-specific or DevOps operations like *ScaleService* or *Restart a Container*.

* **Business-Level**: Domain-specific adjustments such as *EnableFallbackRecommender* (switching to a lightweight algorithm) or *EnableCache*.

Action execution can either be synchronous (e.g. immediate circuit breaking) or asynchronous (e.g. batched log cleanup). Using our provided mechanism for adaptation logic specification, developers bind actions to events subscribers (services or service components). Each subscriber defines a list of adaptation actions that will be executed when the conditions defined in both the event and the subscriber are met. For example, a billing service might subscribe to *HighErrorRateEvent* to disable premium features temporarily, while a load balancer scales instances for the same event.

## Conditional Evaluators: Adaptive Decision-Making

Conditional Evaluators determine when events should trigger and also when subscribers should be notified to execute adaptation. AdaptiFlow implicitly provides two evaluator types: (1) **Threshold-Based Evaluators**, simple rules like *GreaterThan* or *Between*, ideal for tests on numerical data types (e.g. scaling when CPU > 85%) and (2) **Context-Aware Evaluators**, custom logic combining multiple metrics. For instance, a *PeakHourEvaluator* might disable non-essential features during high traffic only if cloud credits are low. Conditional Evaluators act like filters to know when adaptation actions will be executed.

## Event Specification

Events in AdaptiFlow are defined as logical combinations of conditions evaluated against collected metrics. The *Event Specification* component allows developers to declaratively construct events using threshold-based or custom logic. Events serve as the bridge between raw metrics and actionable insights. Here are some examples of events: (1) **Threshold-Based Events**, simple rules like *HighCPUEvent* (CPU > 80%) or *LowDiskSpaceEvent* (FreeDisk < 10%) and (2) **Custom Events**, multi-condition rules such as *ServiceDegradationEvent* (latency > 1s && error rate > 10%).
## Event Observation

The *Event Observation* component implements strategies to detect specified events, balancing timeliness and resource efficiency: (1) **Periodic Polling**, checks conditions at fixed intervals (e.g. CPU every 30 seconds) for gradual trends like memory leaks and (2) **On-Demand Triggers**, event-driven checks (e.g. during API failures) for rapid response to anomalies. The **Observation Scheduler** orchestrates these strategies and developers can customize polling intervals or define their own observation logic, ensuring flexibility across scenarios.

## Event Subscription

AdaptiFlow's *Event Subscription* model allows services or their components to declaratively register interest in specific events. When an event triggers, the notification of subscribers consists of the execution of their adaptation actions. The adaptation action can be a local action inside the current service (e.g. EnableCache, LowPowerMode), an API call to another service to execute some adaptation actions remotely (e.g. OpenCircuitBreaker) or the specification of another adaptation scenario (e.g. DDoS Attack Mitigation).

This model supports hybrid architectures: a service can act as both a subscriber (e.g. Auth service responding to `DDoSAttackEvent`) and an event emitter (e.g. emitting `HighLatencyEvent`). Subscriptions can be dynamically updatable, allowing runtime adjustments without service restarts.

The preceding sections detailed AdaptiFlow's core components, which collectively enable decentralized, context-aware adaptations. However, realizing these capabilities requires a systematic methodology to translate high-level adaptation requirements (e.g. "prevent service outages during traffic spikes") into concrete implementations. This methodology—the **Workflow for Enabling Adaptability** (Fig. 4)—guides developers through six stages, each leveraging AdaptiFlow's components to incrementally build self-adaptive logic:

* **Metrics Collectors** operationalize the *Identify Observables* stage, defining what data to gather.

* **Adaptation Actions** and **Event Subscription** drive the *Specify Event Subscribers* stage, linking events to executable responses.

* **Conditional Evaluators** and **Event Specification** underpin the *Specify Conditional Evaluators* and *Specify Events* stages, mapping raw data to actionable triggers.

* **Event Observation** implements the *Configure Event Observation* stage, ensuring timely detection.

The following subsection elucidates this workflow, demonstrating how developers progress from abstract requirements (e.g. mitigating DDoS attacks) to deployable adaptation logic.

## Workflow for Enabling Adaptability with AdaptiFlow

AdaptiFlow's workflow (Fig. 4) transforms textual adaptation requirements into executable adaptation logic through six systematic steps. To illustrate this process, consider a scenario where the TeaStore Persistence service [42] detects database timeouts and coordinates graceful degradation across dependent services (Auth, Recommender, Image, WebUI). The workflow begins with the identification of critical data points and culminates in the implementation of observation strategies, ensuring end-to-end adaptability.

**Step 1—Identify Observables:** The process starts by defining *observables*—data sources required to monitor the system's state. Developers parse adaptation requirements to determine which metrics (e.g.
<figure><img src="image_5.png" /><figcaption>Figure 4: AdaptiFlow Workflow to enable adaptability in a given cloud microservices system using the textual description of the adaptation requirements or adaptation scenario description.</figcaption></figure>

database health, API latency) must be collected. For the Adaptable TeaStore scenario [2], this involves creating DatabaseHealthCollector to track connection timeouts. AdaptiFlow provides abstract interfaces (e.g. IMetricsCollector) to model these observables, decoupling data collection from downstream logic. Metrics descriptors define the structure of collected data (e.g. sampling frequency, data type), enabling consistent interpretation across services.

**Step 2—Define Adaptation Actions (Parallel Step):** Concurrently, developers specify *adaptation actions*—concrete steps to achieve adaptation goals. These actions fall into two categories: *infrastructure-level* (e.g. restarting pods, scaling instances) and *business-level* (e.g. disabling recommendations, enabling maintenance modes). For Adaptable TeaStore, the Persistence service defines EnableCache, while the WebUI implements EnableMaintenanceMode and the recommender implements LowPowerMode. AdaptiFlow abstracts action execution through interfaces (e.g. IAdaptationAction), allowing delegation to external tools (e.g. Docker API, Kubernetes API) or custom logic. This separation ensures developers focus on defining *what* to adapt, not *how* to implement low-level operations.

Steps 1 and 2 constitute the *preparation phase*, equipping services with the interfaces required for autonomic management. By defining metrics collectors (Step 1), services expose monitoring endpoints that provide real-time insights into their state (e.g. database health, API latency). Simultaneously, specifying adaptation actions (Step 2) establishes control points—actuators that enable runtime adjustments (e.g. restarting pods, toggling features). This aligns with the Autonomic Computing Vision (ACV), where "the managed element is adapted to enable the autonomic manager to monitor and control it" [20]. AdaptiFlow operationalizes this by decoupling data collection and action execution into reusable interfaces (IMetricsCollector, IAdaptationAction), effectively transforming non-adaptive services into autonomic elements. Once prepared, services offer standardized APIs for observation and control, enabling the autonomic manager to implement adaptation scenarios.

**Step 3—Specify Conditional Evaluators:** Conditional evaluators encode the logic for triggering events and filtering subscribers. This step involves dual evaluations: (1) *event evaluators* determine if
an event should trigger (e.g. DatabaseTimeoutEvaluator checks for consecutive timeouts), and (2) subscriber evaluators decide which subscribers should act (e.g. Auth service acts only after a 5-minute outage). Evaluators leverage collected metrics and can integrate external APIs (e.g. machine learning models for anomaly detection). For our Adaptable TeaStore, an UnHealthyDatabaseEvaluator combines database health metrics with service dependency statuses to assess system stability.

**Step 4—Specify Events:** Events semantically encapsulate adaptation scenarios. Developers bind evaluators and metrics to named events (e.g. DatabaseUnavailableEvent), which act as triggers for non-coordinated actions. Events inherit from AdaptiFlow's ConditionalEvent base class, enabling reuse across scenarios. For Adaptable TeaStore, the DatabaseUnavailableEvent is defined using the LocalDatabaseMetricsCollector and UnHealthyDatabaseEvaluator, ensuring it triggers only when timeout thresholds are breached. Events provide human-readable context (e.g. "database_unavailable"), aligning with adaptation goals described in requirements.

**Step 5—Specify Event Subscribers:** Subscribers declaratively register for events and define action execution strategies. A subscriber comprises (1) a list of adaptation actions and (2) a conditional evaluator to filter notifications. In Adaptable TeaStore, the Persistence service subscribes to DatabaseUnavailableEvent with an EnableCache action, while the WebUI service switches to maintenance mode. Subscribers can be granular (e.g. specific UI components) or service-wide. AdaptiFlow supports strategies like *immediate execution* (act on first trigger) or *event counting* (act after N occurrences), offering flexibility akin to MAPE-K's planning phase without fully implementing a planner.

**Step 6—Configure Event Observation:** The final step defines *how* events are detected. AdaptiFlow supports periodic polling (e.g. check database health every 10s) or on-demand triggers (e.g. during API failures). For Adaptable TeaStore, the ObservationScheduler uses periodic checks for database health. Developers can extend the AbstractObservationScheduler class to implement custom strategies (e.g. event-driven checks via message queues), ensuring adaptability to platform constraints. Observation configurations are decoupled from event logic, allowing runtime adjustments without disrupting active adaptations.

This structured workflow ensures systematic implementation of adaptation scenarios while preserving microservices' autonomy. Section 4 validates AdaptiFlow's efficacy through three scenarios in the Adaptable TeaStore: *self-healing* (database recovery), *self-protection* (DDoS mitigation), and *self-optimization* (traffic management).

# 4 Case Study: Building the Adaptable TeaStore

Validation of AdaptiFlow's design principles was carried out through comprehensive experiments with the TeaStore benchmark in order to provide an adaptable version: Adaptable TeaStore previously described by Bliudze et al [2]. This case study has two main objectives: (1) to demonstrate the practical implementation of our abstraction layers (Figure 5) and (2) to evaluate the effectiveness of the framework through distinct adaptation scenarios. We chose TeaStore [42] for its representative cloud-native architecture comprising five interdependent services (Auth, Persistence, Recommender, Image, and WebUI). The experimental methodology systematically examines three autonomous capabilities by implementing three adaptation scenarios: self-healing (service recovery), self-protection (DDoS mitigation), and self-optimization (traffic management).
<figure><img src="image_6.png" /><figcaption>Figure 5: AdaptiFlow class diagram.</figcaption></figure>
## 4.1 Experimental Setup

The experiments were conducted on a Docker-based [25] environment with Portainer CE [31] for container management. Each TeaStore service (Auth, Persistence, Recommender, Image, WebUI) was instrumented with AdaptiFlow's abstraction layer, exposing standardized REST APIs and Java classes for metrics collection and adaptation action execution. We use object-oriented subclassing as the instrumentation method. The AdaptiFlow framework library (compiled with JDK 11) provides base classes and interfaces for implementing metrics collectors, adaptation actions and event handlers.

We utilized the HTTP load generator [42] with Limbo [21] for modeling load intensities just like it is done in the original TeaStore. We containerized the two components of the load generator (the director and the load generator) for Docker compatibility. Load intensity was controlled via three CSV profiles: (1) *increasingLowIntensity.csv* for gradual ramp-up, (2) *increasingMedIntensity.csv* for moderate ramp-up and (3) *increasingHighIntensity.csv* for aggressive ramp-up.

For simplicity, we used the *increasingHighIntensity* profile to simulate DDoS attack conditions, while *increasingMedIntensity* tested self-optimization thresholds. Locust was present in the original configuration, but we intentionally ignored it as the Limbo HTTP load generator was sufficient for our experiments.

Each service's Docker container included: (1) *Metrics Collectors* (Infrastructure / Business-level), (2) *Adaptation Actions* (Business-level only) and *Event Handlers*. As our main objective was to define the abstraction layers needed to specify metrics collectors and adaptation actions, we have not addressed the implementation details of adaptation actions at the infrastructure level (e.g. stopping or restarting containers), since applications such as *Portainer* [31] demonstrate the feasibility of such actions in Docker and Kubernetes environments. We focused more on implementing adaptation actions linked to the business logic of the various microservices (e.g. optimizing recommendations, enabling/disabling caching, using an external provider for images). In addition, the validation focused on Docker; Kubernetes behavior was verified through API responses, but was not tested in cluster orchestration scenarios.

This setup enabled systematic evaluation of AdaptiFlow's ability to translate adaptation requirements into runtime behavior adjustments. The primary result of our experimental validation is the successful implementation of three distinct adaptation scenarios using the AdaptiFlow abstraction layer. The key success metric was functional: for each scenario, the system correctly detected the triggering condition and executed the predefined adaptation actions across the affected services without failure in repeated trials.

The following subsections detail our implementation of three autonomic scenarios, demonstrating how AdaptiFlow's abstraction layer (Figure 5) bridges the gap between non-adaptive services and self-managing elements.

## 4.2 Self-Healing: Database Unavailability

**Scenario overview (Figure 6):** The system is deployed in a barebone configuration with local services (Auth, Recommender, Image, Persistence, WebUI). The Persistence service detects timeouts from the local database due to an unexpected interruption. It triggers adaptation actions across dependent services (Auth, Recommender, Image, WebUI) to gracefully degrade functionality. The WebUI displays a maintenance message, and the system administrator is alerted to restart the database. Once restored, services resume normal operation.

In this scenario, the Persistence microservice serves as the central adaptation coordinator, monitoring database health through three key metrics: *connection status* (boolean), *query response times* (milliseconds), and *active connection counts*. Upon detecting failures, it triggers cascading adaptations across
<figure><img src="image_7.png" /><figcaption>Figure 6: The database unavailable mitigation flow diagram</figcaption></figure>
<table><caption>Table 1: Self-healing scenario implementation mapping to AdaptiFlow workflow</caption><thead><tr><td>Workflow Step</td><td>Key Classes</td><td>Implementation Purpose</td></tr></thead><tbody><tr><td>Identify Observables</td><td>LocalDatabaseMetricsCollector</td><td>Gathers database health metrics via JDBC checks</td></tr><tr><td>Define Adaptation Actions</td><td>DatabaseAvailableEventBroadcast, DatabaseUnavailableEventBroadcast, EnableMaintenanceMode, DisableMaintenanceMode, EnableCache, DisableCache, LowPowerMode, NormalMode</td><td>Declares business-level actuators</td></tr><tr><td>Specify Conditional Evaluators</td><td>HealthyDatabaseEvaluator, UnHealthyDatabaseEvaluator</td><td>Encapsulates detection logic of the database health status</td></tr><tr><td>Specify Events</td><td>DatabaseAvailableEvent, DatabaseUnavailableEvent</td><td>Links metrics to semantic adaptation triggers</td></tr><tr><td>Specify Event Subscribers</td><td>EventSubscriber</td><td>Registers service-specific response actions</td></tr><tr><td>Configure Event Observation</td><td>ContinuousObservationScheduler</td><td>Implements periodic detection strategy</td></tr></tbody></table>

dependent components. The WebUI responds by displaying maintenance pages, while the Recommender service dynamically adjusts its algorithm between normal operation (popular items only) and low-power mode (no recommendations).

**Implementation Methodology:** The implementation follows AdaptiFlow's six-step workflow for enabling adaptability (Section 3), systematically translating requirements into executable adaptation logic:

**Step 1—Identify Observables:** The *LocalDatabaseMetricsCollector* class implements the *IMetric-sCollector* interface to monitor four critical database health indicators: response times, network status, active connections, and pending queries. These observables provide real-time insights into database health through JDBC health checks and connection pool monitoring.

**Step 2—Define Adaptation Actions:** Business-level actuators were implemented across services:

* DatabaseAvailableEventBroadcast / DatabaseUnavailableEventBroadcast, EnableCache / DisableCache in Persistence service

* EnableMaintenanceMode / DisableMaintenanceMode in WebUI

* LowPowerMode / NormalMode in Recommender

Four adaptation patterns coordinate the system response. *Event broadcasting* in persistence service propagates status changes via REST notifications, while cache management dynamically *enables/disables* caching to improve system fault tolerance. The UI degradation pattern activates maintenance displays, and service throttling reduces computational load through the Recommender's power modes. These actions demonstrate AdaptiFlow's ability to easily combine infrastructure and business-level adaptations.

**Step 3—Specify Conditional Evaluators:** The system employs two condition evaluators with distinct triggering mechanisms. The *UnHealthyDatabaseEvaluator* activates when response times exceed 5000ms or when the network status deviates from expectations. Conversely, the *HealthyDatabaseEvaluator* requires both sub-5000ms response times and proper network status before signaling recovery:

* *UnHealthyDatabaseEvaluator* triggers when response times exceed 5000ms or network status deviates
<table><caption>Table 2: DDoS mitigation scenario implementation mapping to AdaptiFlow workflow</caption><thead><tr><td>Workflow Step</td><td>Key Classes</td><td>Implementation Purpose</td></tr></thead><tbody><tr><td>Identify Observables</td><td>LocalRequestMetricsCollector</td><td>Tracks request rates, IP patterns, error frequencies</td></tr><tr><td>Define Adaptation Actions</td><td>DDoSAttackEventBroadcast, EnableMaintenanceMode, OpenCircuitBreaker, CloseCircuitBreaker, LowPowerMode, EnableExternalImageProvider</td><td>Declares protection actuators across services</td></tr><tr><td>Specify Conditional Evaluators</td><td>DDOSEvaluator, NonDDOSEvaluator</td><td>Implements threshold verification logic</td></tr><tr><td>Specify Events</td><td>MaliciousTrafficEvent, BenignTrafficEvent</td><td>Defines attack detection triggers</td></tr><tr><td>Specify Event Subscribers</td><td>EventCounterSubscriber</td><td>Manages multi-stage verification requirements</td></tr><tr><td>Configure Event Observation</td><td>ContinuousObservationScheduler</td><td>Coordinates periodic and event-driven detection</td></tr></tbody></table>

* **HealthyDatabaseEvaluator** requires both sub-5000ms response times and proper network status

These implement the ConditionEvaluator interface with custom validation logic.

**Step 4—Specify Events:** The *DatabaseUnavailableEvent* and *DatabaseAvailableEvent* extend *ConditionEvent*, combining the metrics collector with their respective evaluators. This event abstraction serves as the semantic bridge between raw metrics and adaptation triggers.

**Step 5—Specify Event Subscribers:** Services register interest through *EventSubscriber* instances. In this scenario, only the persistence service subscribes to database availability and unavailability events and then notifies the other services (WebUI and Recommender) so that they can execute their adaptation actions.

**Step 6—Configure Event Observation:** A *ContinuousObservationScheduler* with 5-second polling intervals monitors events. The scheduler initiates the adaptation cycle by periodically invoking metrics collection and evaluation.

**Implementation Notes:** Current limitations include REST-based event propagation (planned upgrade to message brokers) and manual database recovery (future automation target). These constraints were intentionally maintained during validation to isolate and demonstrate the framework's core capabilities.

## 4.3 Self-Protection: Mitigating DDoS Attacks

**Scenario overview (Figure 7):** The system responds to a *Distributed Denial-of-Service* attack through a layered verification and adaptation protocol. The WebUI service acts as the primary detector, analyzing traffic patterns through request rate monitoring before declaring an attack only after three consecutive verification stages. Upon confirmation, it simultaneously activates the local circuit breaker and broadcasts REST notifications to all dependent services. Each recipient service—Auth, Recommender, Persistence, and Image—performs its own dual-layer validation of attack indicators before implementing specialized protections. First of all, the entire services activate its local circuit breaker, then the Recommender downgrades to low-power operation mode. The Persistence service shifts to cache-only operations, and the Image service reroutes requests to external providers.
<figure><img src="image_8.png" /><figcaption>Figure 7: Malicious traffic adaptation workflow</figcaption></figure>
This scenario describes a multi-stage approach that combines centralized detection with decentralized execution, ensuring attack mitigation while preserving critical functionality through coordinated circuit breaker deployment and service-specific degradation modes. The entire process emphasizes verification rigor, requiring five total confirmation checks (three central and two local) before full protective measures engage, preventing false positives during normal traffic spikes.

**Implementation Methodology:** The implementation follows AdaptiFlow's six-step workflow:

**Step 1—Identify Observables:** In this scenario, we employ uniform metric collection across all services through *LocalRequestMetricsCollectors*, monitoring *request rates*, *IP patterns*, *error frequencies* and *requests details*. The WebUI service initiates detection using threshold-based evaluators (*DDoSEvaluator* / *NonDDoSEvaluator*) that analyze requests per second over 60-second windows: more complex verifications could have been done, but we chose to simplify the scenario for our experiments. While all services can track contextual traffic metrics, at the beginning of the process, only WebUI detects and triggers system-wide adaptations when its evaluator detects sustained rates exceeding 300 requests/second. Then, WebUI notifies all services to start their own decentralized monitoring and detection.

**Step 2—Define Adaptation Actions:** Adaptations cascade through a two-phase protocol. The WebUI service first activates maintenance pages and the circuit breaker after triple-confirmed detection, then broadcasts alerts via REST. Recipient services implement specialized protections: Auth activates circuit breaker, Recommender switches to low power mode (no recommendations), Persistence prioritizes cached data, and Image services reroute to external providers. Each service independently verifies attack conditions through dual local checks before executing actions, preventing single-point failures.

* WebUI: *EnableMaintenanceMode*, *DisableMaintenanceMode*, *OpenCircuitBreaker*, *CloseCircuitBreaker*, and *DDoSAttackEventBroadcast*

* Auth: *OpenCircuitBreaker* and *CloseCircuitBreaker*

* Recommender: *LowPowerMode*, *NormalMode*, *OpenCircuitBreaker* and *CloseCircuitBreaker*

* Image: *EnableExternalImageProvider*, *DisableExternalImageProvider*, *OpenCircuitBreaker* and *CloseCircuitBreaker*

These actions demonstrate AdaptiFlow's support for heterogeneous response strategies across services.

**Step 3—Specify Conditional Evaluators:** *DDoSEvaluator* implements threshold-based attack detection, triggering when request rates exceed 300 req/sec. The complementary *NonDDoSEvaluator* handles recovery conditions.

**Step 4—Specify Events:** *MaliciousTrafficEvent* and *BenignTrafficEvent* extend *ConditionalEvent*, combining metrics collectors with evaluators. These event abstractions encapsulate attack semantics while decoupling detection from response logic.

**Step 5—Specify Event Subscribers:** WebUI uses *EventCounterSubscriber*, requiring three consecutive threshold breaches before triggering adaptations, reducing false positives. Downstream services implement dual-verification subscribers that perform two local confirmations before executing protections. This hierarchical subscription model balances system-wide awareness with local context validation.

**Step 6—Configure Event Observation:** A *ContinuousObservationScheduler* with 5-second polling intervals monitors events across all services. The scheduler initiates the adaptation cycle by periodically invoking metrics collection and evaluation.
<table><caption>Table 3: Self-optimization scenario implementation mapping to AdaptiFlow workflow</caption><thead><tr><td>Workflow Step</td><td>Key Classes</td><td>Implementation Purpose</td></tr></thead><tbody><tr><td>Identify Observables</td><td>ResourceUsageCollector</td><td>Monitors CPU/memory utilization across services</td></tr><tr><td>Define Adaptation Actions</td><td>LowPowerMode, EnableCache, NormalPowerMode, Disable, EnableExternalImageProvider</td><td>Implements service-specific optimization strategies</td></tr><tr><td>Specify Conditional Evaluators</td><td>IncreaseResourceUsageEvaluator, DecreaseResourceUsageEvaluator</td><td>Defines threshold-based optimization triggers</td></tr><tr><td>Specify Events</td><td>TrafficIncreaseEvent, TrafficDecreaseEvent</td><td>Encapsulates resource-based adaptation triggers</td></tr><tr><td>Specify Event Subscribers</td><td>EventSubscriber</td><td>Registers autonomous optimization responses</td></tr><tr><td>Configure Event Observation</td><td>ContinuousObservationScheduler</td><td>Implements periodic resource monitoring</td></tr></tbody></table>

**Technical Insights:** The event-driven architecture uses the *ConditionalEvent* wrapper around metric streams, with WebUI's *EventCounterSubscriber* requiring three threshold breaches before triggering adaptations. Recipient services reuse the same evaluator classes but configure two-step verification. REST notifications propagate through standardized adaptation endpoints, enabling heterogeneous action execution—from UI changes (*EnableMaintenanceMode*) to infrastructure adjustments (*EnableExternalImageProvider*). The code structure demonstrates AdaptiFlow's template pattern, where services implement shared interfaces (*IAdaptationAction*, *ConditionEvaluator*) while customizing verification thresholds and action combinations. REST notifications propagate through standardized endpoints, though future versions will also integrate message brokers for enhanced reliability.

## 4.4 Self-Optimization: Handling Benign Traffic Surges

**Scenario overview (Figure 8):** The system autonomously adapts to legitimate traffic spikes through context-aware resource optimization when infrastructure scaling is unavailable. Faced with surging user demand, the WebUI service triggers decentralized adaptations across dependent components without centralized coordination. The Recommender service switches to no recommendations, reducing computational load. Simultaneously, the Persistence service activates caching mechanisms, prioritizing frequently accessed data to alleviate database pressure. Image processing workloads shift dynamically to an external provider. Each service independently monitors resource utilization through dedicated collectors—CPU and memory-to calibrate adaptations, enabling system-wide load balancing.

In this scenario, we use an uncoordinated optimization strategy that demonstrates AdaptiFlow's ability, where autonomous decisions at the service level collectively contribute to stabilizing the system despite resource constraints. This stabilization is sometimes achieved at the expense of the user experience, depending on the adaptation actions chosen.

**Implementation Methodology:** The implementation follows AdaptiFlow's six-step workflow for decentralized optimization:

**Step 1—Identify Observables:** we employ decentralized resource monitoring through service-specific *ResourceUsageCollectors*, tracking CPU and memory utilization. Each service (Recommender, Persistence, Image) independently observes metrics via hash maps containing numeric percentages for *cpu_usage* and *memory_usage*. Threshold-based evaluators trigger adaptations when CPU exceeds 75%
<figure><img src="image_9.png" /><figcaption>Figure 8: Benign traffic adaptation workflow</figcaption></figure>
or memory surpasses 80%, with recovery initiated when both metrics drop below 60%. This dual-
threshold approach prevents oscillations during borderline resource conditions while maintaining granu-
lar control over optimization triggers.

**Step 2—Define Adaptation Actions:** Services implement autonomous optimization strategies when thresholds breach. The Recommender reduces computational load by switching to no recommendations via *LowPowerMode*, cutting recommendation logic overhead. Persistence activates caching mechanisms (*EnableCache*) to minimize database queries, while the Image service offloads processing to an external provider through *EnableExternalImageProvider*. Recovery actions revert systems to normal operations when resource usage stabilizes.

* Recommender: *LowPowerMode*, *NormalMode*

• Persistence: *EnableCache*, *DisableCache*

• Image: *EnableExternalImageProvider*, *DisableExternalImageProvider*

These localized adaptations occur without inter-service coordination, allowing parallel optimization
while preserving core functionality.

**Step 3—Specify Conditional Evaluators:** The *IncreaseResourceUsageEvaluator* triggers optimizations when either CPU or memory exceeds upper limits (default: 75% CPU, 80% memory), while *DecreaseResourceUsageEvaluator* restores normal operations when both metrics fall below recovery thresholds (60%). This asymmetric logic prioritizes rapid response to overloads while requiring sustained improvement for recovery.

**Step 4—Specify Events:** The *TrafficIncreaseEvent* and *TrafficDecreaseEvent* extend *ConditionalEvent*, combining resource metrics with their respective evaluators. These events provide semantic context for optimization triggers while maintaining service isolation.

**Step 5—Specify Event Subscribers:** Services use *EventSubscriber* instances to register their optimization responses directly. The granular subscription model allows per-service threshold customization while maintaining standardized interfaces. For example, Image services can implement higher CPU thresholds (85%) than Recommender services (75%).

**Step 6—Configure Event Observation:** A *ContinuousObservationScheduler* with configurable polling intervals (default: 5 seconds) monitors resource events. The scheduler initiates periodic resource checks, balancing detection responsiveness with system overhead.

**Technical Insights:** Decentralized decision-making leverages identical threshold patterns across services with service-specific interpretations. The *IncreaseResourceUsageEvaluator* class triggers optimizations when either CPU or memory exceeds upper limits, while *DecreaseResourceUsageEvaluator* restores normal operations when both metrics fall below recovery thresholds. This asymmetric logic prioritizes rapid response to overloads while requiring sustained improvement for recovery, balancing stability with responsiveness. Services maintain isolation, Rescommender never influences Persistence caching decisions.

The architecture uses standardized *ConditionalEvent* wrappers around resource metrics, enabling code reuse across services while allowing threshold customization. HashMaps structure metrics with strict key conventions (*cpu_usage*, *memory_usage*) for evaluator compatibility. Five-second polling intervals (configurable via *EVENT_LISTENING_INTERVAL_MS*) balance detection speed with overhead. Though services share adaptation patterns, each can maintain separate threshold configurations.
# 5 Conclusion and future work

The development and evaluation of AdaptiFlow demonstrate a workflow and abstraction layer for integrating self-adaptive capabilities into cloud-native microservices. More precisely, AdaptiFlow addresses the critical challenge of enabling self-adaptation in cloud-native microservices through an abstraction layer focused on the **Monitor** and **Execute** phases of the MAPE-K loop. By decoupling metrics collection and action execution from adaptation logic, the framework provides standardized interfaces that transform conventional services into autonomic elements with minimal code changes. While our primary focus was on abstracting the monitoring and execution phases, we introduced lightweight rule-based mechanisms for the **Analyze** and **Plan** phases to validate the core architecture through realistic scenarios. This pragmatic approach demonstrates how decentralized, event-driven adaptations can emerge from localized decisions while maintaining system-wide coherence.

The framework's strength lies in its dual-purpose API design: developers instrument services with metrics collectors and actuators using unified interfaces, while adaptation stakeholders, such as human operators or AI-based agents, leverage these primitives to implement diverse control policies. Our validation through the **Adaptable TeaStore** case-study [2] confirms AdaptiFlow's practicality across three critical adaptation objectives: self-healing, self-protection, and self-optimization.

As part of the future work, we plan to focus on three key enhancements:

* **Formal Coordination:** A current limitation is the potential for conflicting adaptations when multiple, independent scenarios are triggered within the same service. To address this, we plan to integrate a formal coordination engine, such as *JavaBIP* [3] or *Multi-Bach* [15], to explicitly model the composition of concurrent adaptation behaviors. This would allow us to rigorously specify interaction protocols and prevent undesirable system states.

* **Adaptation Language:** Exploration of a domain-specific language (DSL) for declarative rule or adaptation scenario specification, lowering the barrier for non-programmers to define adaptation policies.

* **Intelligent Adaptation:** Implementation and evaluation of AI-driven strategies using the AWARE framework [36], comparing machine learning approaches with traditional rule-based methods in terms of responsiveness and resource efficiency.

By bridging the gap between autonomous computing theory and cloud computing practice, AdaptiFlow consolidates the foundations of self-adaptive systems, in which microservices autonomously navigate dynamic environments, while developers retain full (ideal case) or moderate (if necessary) control over adaptation semantics. This balance between automation and flexibility makes the framework an essential tool for resilient, efficient cloud architectures at a time of ever-increasing operational complexity.

# References

[1] Gordon Blair, Nelly Bencomo & Robert B. France (2009): *Models@run.time*. Computer 42(10), p. 22–27, doi:10.1109/MC.2009.326.

[2] Simon Bliudze, Giuseppe De Palma, Saverio Giallorenzo, Ivan Lanese, Gianluigi Zavattaro & Brice Arléon Zemtsop Ndadji (2025): *Adaptable TeaStore*. In Giuseppe De Palma & Saverio Giallorenzo, editors: *Post-proceedings of the Workshop on Adaptable Cloud Architectures (WACA 2025), Electronic Proceedings in Theoretical Computer Science* 438, Open Publishing Association, pp. 1–14, doi:10.4204/EPTCS.438.1.
[3] Simon Bliudze, Anastasia Mavridou, Radoslaw Szymanek & Alina Zolotukhina (2017): *Exogenous coordination of concurrent software components with JavaBIP*. Software: Practice and Experience 47(11), pp. 1801–1836, doi:10.1002/spe.2495.

[4] Radu Calinescu, Lars Grunske, Marta Kwiatkowska, Raffaela Mirandola & Giordano Tamburrelli (2011): *Dynamic QoS Management and Optimization in Service-Based Systems*. IEEE Trans. Softw. Eng. 37(3), p. 387–409, doi:10.1109/TSE.2010.92.

[5] Radu Calinescu, Danny Weyns, Simos Gerasimou, Muhammad Usman Iftikhar, Ibrahim Habli & Tim Kelly (2018): *Engineering Trustworthy Self-Adaptive Software with Dynamic Assurance Cases*. IEEE Transactions on Software Engineering 44(11), pp. 1039–1069, doi:10.1109/TSE.2017.2738640.

[6] The SmartCloud consortium: *Adaptable TeaStore: Experimentation platform*. https://gitlab.inria.fr/adaptable-teastore/experimentation-platform. [Accessed 17-09-2025].

[7] Simon Dobson, Spyros Denazis, Antonio Fernández, Dominique Gaïti, Erol Gelenbe, Fabio Massacci, Paddy Nixon, Fabrice Saffre, Nikita Schmidt & Franco Zambonelli (2006): *A survey of autonomic communications*. ACM Trans. Auton. Adapt. Syst. 1(2), p. 223–259, doi:10.1145/1186778.1186782.

[8] Ahmed Elkhodary, Naeem Esfahani & Sam Malek (2010): *FUSION: a framework for engineering self-tuning self-adaptive software systems*. In: Proceedings of the eighteenth ACM SIGSOFT international symposium on Foundations of software engineering, pp. 7–16, doi:10.1145/1882291.1882296.

[9] Ilenia Epifani, Carlo Ghezzi, Raffaela Mirandola & Giordano Tamburrelli (2009): *Model evolution by run-time parameter adaptation*. In: 2009 IEEE 31st International Conference on Software Engineering, IEEE, pp. 111–121, doi:10.1109/ICSE.2009.5070513.

[10] Antonio Filieri, Henry Hoffmann & Martina Maggio (2014): *Automated design of self-adaptive software with control-theoretical formal guarantees*. In: Proceedings of the 36th International Conference on Software Engineering, pp. 299–310.

[11] Luca Florio & Elisabetta Di Nitto (2016): *Gru: An Approach to Introduce Decentralized Autonomic Behavior in Microservices Architectures*. In: 2016 IEEE International Conference on Autonomic Computing (ICAC), pp. 357–362, doi:10.1109/ICAC.2016.25.

[12] D. Garlan, S.-W. Cheng, A.-C. Huang, B. Schmerl & P. Steenkiste (2004): *Rainbow: architecture-based self-adaptation with reusable infrastructure*. Computer 37(10), pp. 46–54, doi:10.1109/MC.2004.175.

[13] Joseph L Hellerstein, Yixin Diao, Sujay Parekh & Dawn M Tilbury (2004): *Feedback control of computing systems*. John Wiley & Sons.

[14] M. Usman Iftikhar & Danny Weyns (2014): *ActivFORMS: active formal models for self-adaptation*. In: Proceedings of the 9th International Symposium on Software Engineering for Adaptive and Self-Managing Systems, SEAMS 2014, Association for Computing Machinery, New York, NY, USA, p. 125–134, doi:10.1145/2593929.2593944.

[15] Jean-Marie Jacquet & Manel Barkallah (2021): *Anemone: A workbench for the Multi-Bach coordination language*. Science of Computer Programming 202, p. 102579, doi:10.1016/j.scico.2020.102579.

[16] Sharmin Jahan, Ian Riley, Charles Walter, Rose F Gamble, Matt Pasco, Philip K McKinley & Betty HC Cheng (2020): *MAPE-K/MAPE-SAC: An interaction framework for adaptive systems with security assurance cases*. Future Generation Computer Systems 109, pp. 197–209, doi:10.1016/j.future.2020.03.031.

[17] Pooyan Jamshidi, Amir Sharifloo, Claus Pahl, Hamid Arabnejad, Andreas Metzger & Giovani Estrada (2016): *Fuzzy self-learning controllers for elasticity management in dynamic cloud architectures*. In: 2016 12th International ACM SIGSOFT Conference on Quality of Software Architectures (QoSA), IEEE, pp. 70–79, doi:10.1109/QoSA.2016.13.

[18] Saeid Jamshidi, Ashkan Amirnia, Amin Nikanjam & Foutse Khomh (2024): *Enhancing security and energy efficiency of cyber-physical systems using deep reinforcement learning*. Procedia Computer Science 238, pp. 1074–1079, doi:10.1016/j.procs.2024.06.137.
[19] Joao Paulo Karol Santos Nunes, Shiva Nejati, Mehrdad Sabetzadeh & Elisa Yumi Nakagawa (2024): *Self-adaptive, requirements-driven autoscaling of microservices*. In: Proceedings of the 19th International Symposium on Software Engineering for Adaptive and Self-Managing Systems, pp. 168–174, doi:10.1145/3643915.3644094.

[20] Jeffrey O Kephart & David M Chess (2003): *The vision of autonomic computing*. Computer 36(1), pp. 41–50, doi:10.1109/MC.2003.1160055.

[21] Jóakim von Kistowski, Nikolas Roman Herbst & Samuel Kounev (2014): *LIMBO: A Tool For Modeling Variable Load Intensities*. In: Proceedings of the 5th ACM/SPEC International Conference on Performance Engineering (ICPE 2014), ICPE ’14, ACM, New York, NY, USA, p. 225–226, doi:10.1145/2568088.2576092.

[22] Jeff Kramer & Jeff Magee (2007): *Self-Managed Systems: an Architectural Challenge*. In: Future of Software Engineering (FOSE ’07), pp. 259–268, doi:10.1109/FOSE.2007.19.

[23] Martina Maggio, Alessandro Vittorio Papadopoulos, Antonio Filieri & Henry Hoffmann (2017): *Automated control of multiple software goals using multiple actuators*. In: Proceedings of the 2017 11th joint meeting on foundations of software engineering, pp. 373–384, doi:10.1145/3106237.3106247.

[24] Michael Maurer, Ivan Breskovic, Vincent C Emeakaroha & Ivona Brandic (2011): *Revealing the MAPE loop for the autonomic management of cloud infrastructures*. In: 2011 IEEE symposium on computers and communications (ISCC), IEEE, pp. 147–152, doi:10.1109/ISCC.2011.5984008.

[25] Dirk Merkel (2014): *Docker: lightweight linux containers for consistent development and deployment*. Linux journal 2014(239), p. 2, doi:10.5555/2600239.2600241.

[26] Andreas Metzger, Clément Quinton, Zoltán Ádám Mann, Luciano Baresi & Klaus Pohl (2024): *Realizing self-adaptive systems via online reinforcement learning and feature-model-guided exploration*. Computing 106(4), pp. 1251–1272, doi:10.1007/s00607-022-01052-x.

[27] Gabriel A. Moreno, Javier Cámara, David Garlan & Bradley Schmerl (2015): *Proactive self-adaptation under uncertainty: a probabilistic model checking approach*. In: Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering, ESEC/FSE 2015, Association for Computing Machinery, New York, NY, USA, p. 1–12, doi:10.1145/2786805.2786853.

[28] Brice Morin, Olivier Barais, Jean-Marc Jezequel, Franck Fleurey & Arnor Solberg (2009): *Models@Run.time to Support Dynamic Adaptation*. Computer 42(10), pp. 44–51, doi:10.1109/MC.2009.327.

[29] Jiyoung Oh, Claudia Raibulet & Joran Leest (2022): *Analysis of MAPE-K loop in self-adaptive systems for cloud, IoT and CPS*. In: International Conference on Service-Oriented Computing, Springer, pp. 130–141, doi:10.1007/978-3-031-26507-5_11.

[30] P. Oreizy, M.M. Gorlick, R.N. Taylor, D. Heimhigner, G. Johnson, N. Medvidovic, A. Quilici, D.S. Rosenblum & A.L. Wolf (1999): *An architecture-based approach to self-adaptive software*. IEEE Intelligent Systems and their Applications 14(3), pp. 54–62, doi:10.1109/5254.769885.

[31] *Portainer Documentation*. https://docs.portainer.io/. [Accessed 20-04-2025].

[32] Federico Quin, Danny Weyns, Thomas Bamelis, Sarpreet Singh Buttar & Sam Michiels (2019): *Efficient analysis of large adaptation spaces in self-adaptive systems using machine learning*. In: 2019 IEEE/ACM 14th International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS), IEEE, pp. 1–12, doi:10.1109/SEAMS.2019.00011.

[33] Michael Riegler, Johannes Sametinger & Michael Vierhauser (2023): *A distributed MAPE-K framework for self-protective IoT devices*. In: 2023 IEEE/ACM 18th Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS), IEEE, pp. 202–208, doi:10.1109/SEAMS59076.2023.00034.

[34] Stuart Russell & Peter Norvig (2009): *Artificial Intelligence: A Modern Approach*, 3rd edition. Prentice Hall Press, USA.

[35] Mauricio Salatino, Mariano De Maio & Esteban Aliverti (2016): *Mastering jboss drools 6*. Packt Publishing Ltd.
[36] Brell Peclard Sanwouo, Paul Temple & Clément Quinton (2025): *Breaking the Loop: AWARE is the new MAPE-K*. In: FSE’25-International Conference on the Foundations of Software Engineering, pp. 626–630, doi:10.1145/3696630.3728512.

[37] Mohammad Reza Saleh Sedghpour, Cristian Klein & Johan Tordsson (2021): *Service mesh circuit breaker: From panic button to performance management tool*. In: Proceedings of the 1st workshop on high availability and observability of cloud systems, pp. 4–10, doi:10.1145/3447851.3458740.

[38] Stepan Shevtsov & Danny Weyns (2016): *Keep it SIMPLEX: Satisfying multiple goals with guarantees in control-based self-adaptive systems*. In: Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering, pp. 229–241, doi:10.1145/2950290.2950301.

[39] Vítor E. Souza, Alexei Lapouchnian, Konstantinos Angelopoulos & John Mylopoulos (2013): *Requirements-driven software evolution*. Comput. Sci. 28(4), p. 311–329, doi:10.1007/s00450-012-0232-2.

[40] Marco Stadler, Johannes Sametinger & Michael Riegler (2024): *Cyber-resilient edge computing: a holistic approach with multi-level MAPE-K loops*. In: 2024 IEEE 21st International Conference on Software Architecture Companion (ICSA-C), IEEE, pp. 79–83, doi:10.1109/ICSA-C63560.2024.00020.

[41] Thomas Vogel & Holger Giese (2014): *Model-Driven Engineering of Self-Adaptive Software with EUREMA*. ACM Trans. Auton. Adapt. Syst. 8(4), doi:10.1145/2555612.

[42] Joakim Von Kistowski, Simon Eismann, Norbert Schmitt, André Bauer, Johannes Grohmann & Samuel Kounev (2018): *Teastore: A micro-service reference application for benchmarking, modeling and resource management research*. In: 2018 IEEE 26th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (MASCOTS), IEEE, pp. 223–236, doi:10.1109/MASCOTS.2018.00030.

[43] Danny Weyns (2021): *An Introduction to Self-Adaptive Systems: A Contemporary Software Engineering Perspective*. John Wiley & Sons, Ltd, doi:10.1002/9781119574910.

[44] Danny Weyns, Sam Malek & Jesper Andersson (2012): *FORMS: Unifying reference model for formal specification of distributed self-adaptive systems*. ACM Trans. Auton. Adapt. Syst. 7(1), doi:10.1145/2168260.2168268.

[45] Jon Whittle, Pete Sawyer, Nelly Bencomo, Betty H.C. Cheng & Jean-Michel Bruel (2009): *RELAX: Incorporating Uncertainty into the Specification of Self-Adaptive Systems*. In: 2009 17th IEEE International Requirements Engineering Conference, pp. 79–88, doi:10.1109/RE.2009.36.

[46] Fenglin Yu, Fangkai Yang, Xiaoting Qin, Zhiyang Zhang, Jue Zhang, Qingwei Lin, Hongyu Zhang, Yingnong Dang, Saravan Rajmohan, Dongmei Zhang et al. (2025): *Enabling Autonomic Microservice Management through Self-Learning Agents*. arXiv preprint arXiv:2501.19056, doi:10.48550/arXiv.2501.19056.

[47] Zhiyang Zhang, Fangkai Yang, Xiaoting Qin, Jue Zhang, Qingwei Lin, Gong Cheng, Dongmei Zhang, Saravan Rajmohan & Qi Zhang (2024): *The Vision of Autonomic Computing: Can LLMs Make It a Reality?*. arXiv preprint arXiv:2407.14402, doi:10.48550/arXiv.2407.14402.