[Paper] AdaptiFlow: An Extensible Framework for Event-Driven Autonomy in Cloud Microservices
Source: arXiv - 2512.23499v1
Overview
AdaptiFlow is a lightweight, extensible framework that brings autonomic (self‑managing) capabilities to cloud‑native microservices without forcing a monolithic control plane. By cleanly separating monitoring and execution from the adaptation logic, it lets each service become an autonomous “smart” component that can react to events such as failures, attacks, or traffic spikes—all through a set of standard interfaces.
Key Contributions
- Decoupled MAPE‑K building blocks – Provides reusable Metrics Collectors and Adaptation Actions that can be plugged into any microservice.
- Event‑driven, rule‑based adaptation engine – Enables developers to express “if‑then” adaptation policies declaratively, avoiding custom code for each scenario.
- Microservice‑level autonomy – Shows how decentralized decisions can achieve system‑wide self‑healing, self‑protection, and self‑optimization without a central orchestrator.
- Instrumentation workflow – A step‑by‑step guide for turning an existing service into an autonomous element with minimal code changes.
- Validated on a real‑world benchmark – Extends the Adaptable TeaStore demo to implement three concrete adaptation use‑cases, demonstrating practical feasibility.
Methodology
-
Framework Design – The authors built AdaptiFlow around the Monitor and Execute phases of the classic MAPE‑K loop:
- Metrics Collectors expose a uniform API for gathering infrastructure (CPU, latency) and business (order count) metrics.
- Adaptation Actions are declarative wrappers around typical cloud operations (restart container, scale replica, update firewall rule).
-
Event‑Driven Adaptation Logic – Developers write simple rule files (e.g.,
if cpu>80% && latency>200ms then scale_out) that the framework evaluates whenever a collector emits an event. No custom Java/Python code is required for the decision logic itself. -
Instrumentation Process –
- Add the AdaptiFlow SDK to a service.
- Register the metrics you care about (via annotations or a config file).
- Declare the actions the service is allowed to invoke.
- Deploy the same rule set across all services or tailor per service.
-
Experimental Validation – The authors integrated AdaptiFlow into the Adaptable TeaStore (a reference e‑commerce microservice app). They implemented three scenarios:
- Self‑healing – Automatic DB container restart after crash.
- Self‑protection – Dynamic rate‑limiting and IP blocklist when a DDoS pattern is detected.
- Self‑optimization – Traffic‑aware replica scaling based on request volume.
Each scenario required only a handful of lines added to the service’s Dockerfile and a rule definition file.
Results & Findings
| Scenario | Code Change | Reaction Time | Success Rate |
|---|---|---|---|
| DB recovery (self‑healing) | + 12 LOC | < 5 s after failure detection | 100 % |
| DDoS mitigation (self‑protection) | + 9 LOC | < 3 s after attack pattern detection | 98 % |
| Traffic scaling (self‑optimization) | + 11 LOC | < 2 s after load spike | 95 % |
- Minimal footprint – Adding AdaptiFlow increased each service’s image size by ~3 MB and added < 0.2 % CPU overhead under normal load.
- Decentralized coordination works – Even though each service made decisions locally, the overall system behaved coherently (e.g., no over‑scaling loops).
- Developer productivity boost – The rule‑based approach reduced the time to prototype a new adaptation policy from days to minutes.
Practical Implications
| Who Benefits | How It Helps |
|---|---|
| DevOps engineers | No need to spin up a heavyweight central autonomic controller; policies can be rolled out via CI/CD pipelines. |
| Backend developers | Turn existing services into self‑aware components by adding a tiny SDK and a rule file—no refactoring of business logic. |
| Platform teams | Uniform metric collection and action APIs simplify observability tooling and enforce consistent remediation actions across services. |
| Security teams | Rapid, automated DDoS mitigation can be codified as a rule, reducing mean‑time‑to‑response without manual firewall updates. |
| Cost‑optimisation | Self‑optimisation rules can automatically scale down idle services, cutting cloud spend while preserving performance. |
In short, AdaptiFlow offers a plug‑and‑play path to bring autonomic capabilities into the microservice world, aligning with the “infrastructure as code” mindset that modern cloud teams already practice.
Limitations & Future Work
- Scope limited to Monitor & Execute – The current version leaves the Analyze and Plan phases to simple rule evaluation; more complex reasoning (e.g., predictive models) is not yet supported.
- No formal verification – While the authors demonstrated correct behavior experimentally, they acknowledge the need for formal coordination models to guarantee safety in highly dynamic environments.
- Scalability of rule engine – The rule engine runs inside each service; extremely large rule sets could impact performance and may require a lightweight external rule service.
- AI‑driven adaptation – Future research will explore integrating reinforcement‑learning agents or other AI techniques to enable proactive, rather than purely reactive, adaptations.
Authors
- Brice Arléon Zemtsop Ndadji
- Simon Bliudze
- Clément Quinton
Paper Information
- arXiv ID: 2512.23499v1
- Categories: cs.SE, cs.DC
- Published: December 29, 2025
- PDF: Download PDF