A Microservice-Based Platform for Sustainable and Intelligent SLO Fulfilment and Service Management

1. Problem Statement

The paper addresses the growing complexity of managing Service Level Objectives (SLOs) in Microservices Architecture (MSA) applications deployed across the Computing Continuum (CC).

• The Conflict: Modern applications must balance performance SLOs (e.g., latency, throughput) with sustainability SLOs (specifically carbon-awareness). Optimizing for one often negatively impacts the other (e.g., increasing GPU usage improves performance but increases energy consumption).
• The Privacy Barrier: Effective reconfiguration requires deep knowledge of the infrastructure and real-time data. However, infrastructure providers (CC providers) possess this data but are often restricted from observing the internal logic or specific semantics of the applications they host due to privacy and competitive concerns (e.g., a cloud provider cannot see the proprietary algorithms of a streaming service like Netflix).
• The Technical Gap: Existing decision systems (using AI, heuristics, or optimization) are often tightly coupled to specific services, require source code modifications, or lack the ability to operate while preserving the semantic privacy of the service developer. They also struggle to integrate diverse data sources (hardware metrics, external carbon intensity data) in a modular way.

2. Methodology: The CASCA Platform

The authors propose CASCA (Carbon-Aware SLO and Control plAtform), an open-source, MSA-based platform designed to decouple service management from service semantics while enabling intelligent reconfiguration.

Core Architecture

CASCA is built on MSA principles, ensuring modules are loosely coupled, reusable, and distributable. It consists of three main layers:

1. Telemetry and Data Ingestion:

   • Telemetry Middleware: Uses message-oriented brokers (e.g., MQTT) to receive data from diverse sources (clients, hardware sensors, orchestrators).
   • Telemetry Hooks: Specialized services that deserialize messages, convert them to a unified schema, and store them in a time-series database (e.g., InfluxDB). This decouples the network protocol from the storage format.
   • EMMA (Energy Mix Manager): A dedicated microservice that provides a unified API for carbon intensity data. It aggregates data from external sources (e.g., government energy mix reports, ElectricityMaps) to allow decision systems to calculate carbon footprints without needing direct access to raw infrastructure data.

2. Service API (The Privacy Layer):

   • Acts as a gateway between the service developer and the infrastructure provider.
   • Service Controller: Abstracts the specific configuration interfaces of a service (CLI, config files, APIs) into a unified interface.
   • SLO Controller: Manages the definition and retrieval of SLOs.
   • Privacy Mechanism: The API allows developers to obscure semantics. For example, a developer can declare "SLO A" (CPU < 80%) without revealing that "SLO A" actually refers to "Thread Count." The decision system sees the metric and the target value but not the underlying business logic.

3. Decision System Integration:

   • CASCA exposes three standard APIs: SLO API (observability), Service Control API (reconfiguration), and Carbon Footprint API (via EMMA).
   • It is technology-agnostic, supporting any decision logic (heuristics, traditional optimization, or AI/RL) implemented in any language.

3. Key Contributions

1. CASCA Platform: A reusable, open-source MSA platform for SLO fulfilment that supports dynamic reconfiguration while maintaining developer privacy.
2. Privacy-Preserving APIs: A declarative interface design that allows infrastructure providers to manage services without accessing proprietary service semantics (context).
3. EMMA Microservice: A unified interface for integrating carbon intensity data into service management, enabling carbon-aware decision-making.
4. Implementation & Evaluation: A full implementation of CASCA applied to a media streaming use case (using Jellyfin), demonstrating compatibility with decision systems written in Bash, Rust, and Python.
5. Open Source Replication: All source code, Docker configurations, and documentation are publicly available to foster replication.

4. Experimental Results

The platform was evaluated in a real-world testbed using a media streaming service (Jellyfin) with three distinct decision systems:

• Random Decision System (RDS): Bash-based baseline.
• Greedy Decision System (GDS): Rust-based heuristic.
• Reinforcement Learning Decision System (RLDS): Python-based Deep Reinforcement Learning (PPO algorithm).

Key Findings:

• Performance:
  • RLDS achieved the best balance, fulfilling the performance SLO (FPS > 24) 85.2% of the time while minimizing carbon footprint.
  • GDS fulfilled the SLO 90.6% of the time but was less carbon-efficient than RLDS because it did not explicitly optimize for carbon intensity in its reward function.
  • RDS performed poorly, fulfilling the SLO only 5.4% of the time.
• Privacy Impact:
  • Experiments comparing "Revealed" (full semantic knowledge) vs. "Obscured" (masked parameter names) descriptions showed negligible performance differences.
  • Decision systems (especially RLDS) performed equally well without knowing the specific names of parameters (e.g., "Encoding Thread Count" vs. "ServiceParam"), proving that privacy can be maintained without sacrificing control efficacy.
• Overhead:
  • CASCA introduced an average latency of ~74ms for setting/getting parameters compared to native interaction. This overhead was deemed acceptable given the decision intervals (seconds/minutes).
• Flexibility:
  • Reconfiguration Speed: CASCA's declarative approach (modifying config files) reduced reconfiguration time from ~56 seconds (imperative source code recompilation) to ~2.7 seconds, demonstrating high agility.

5. Significance and Future Work

Significance:

• Bridging the Gap: CASCA successfully bridges the gap between the need for intelligent, carbon-aware infrastructure management and the strict privacy requirements of modern cloud tenants.
• Sustainability: It operationalizes "Carbon-Aware Computing" by making carbon intensity a first-class citizen in SLO management, allowing systems to shift load or adjust configurations based on the greenness of the energy grid.
• Architectural Shift: It moves away from tightly coupled, AI-specific control loops toward a modular, MSA-compliant ecosystem where decision logic can be swapped or upgraded independently of the service.

Future Work:

• Hardware Control: Extending CASCA to control hardware-level settings (e.g., CPU frequency scaling) directly.
• Service Orchestration: Expanding the scope to decide where services run (migration across the continuum) rather than just how they are configured.
• Dashboarding: Developing a visual dashboard to simplify the generation of declarative configurations for non-technical operators.