PaperlayerView exact revision on arXiv

Source-linked AI summary

MicroIntent: Intent-Based Placement Strategy for Microservice Application in the Compute Continuum Using LLMs

Koushikur Islam, Guilherme Da Cunha Rodrigues, Bahman Javadi, Rodrigo N. Calheiros

arXiv:2609.07927v1cs.DC

TL;DR

MicroIntent addresses the barrier created by low-level SLOs in geographically distributed compute-continuum placement. It uses an LLM-based parser to translate natural-language intents into SLOs, combines them with infrastructure descriptions, and generates placement recommendations; MVP experiments demonstrate that placements react to intent and infrastructure changes.

  • Problem

    Low-level SLOs make compute-continuum placement harder for users, despite placement needing to satisfy latency, storage, QoS, and availability requirements.

  • Method

    MicroIntent uses an LLM-based intent parser to translate natural-language intents into actionable SLOs, then a placement generator matches them with infrastructure descriptions.

  • Results

    MVP experiments successfully reacted to changes in user intent and infrastructure when making placement decisions.

  • Takeaways & Limitations

    High-level natural-language intents can support microservice placement recommendations in the compute continuum while lowering the user entry barrier.

Abstract

from arXiv · show

The placement of microservices in the compute continuum plays a vital role in delivering services that comply with customers' needs, such as reduced latency, storage requirements, quality of service and availability. To achieve customers' needs in the geographically dispersed architecture of the compute continuum, Service Level Objectives (SLOs) have been largely used in decision-making to place microservices. However, because low-level SLOs increase the barrier to entry for continuum users, placement decisions based on high-level business vocabulary are required if the compute continuum is to be adopted at scale. This paper proposes an architecture for microservices placement decisions in the computing continuum utilizing high-level user intents described in natural language as input. The approach utilizes Generative Artificial Intelligence to translate the intents to low-level SLOs, which are used along with the infrastructure description to decide where different microservices that compose an application must be deployed so that SLOs are met. We implement and evaluate a prototype of the architecture to demonstrate the approach's feasibility.

I. INTRODUCTION

MicroIntent addresses the difficulty of placing microservices across heterogeneous cloud–edge environments using low-level SLOs. It translates natural-language intents into actionable SLOs and generates placement recommendations, with an MVP demonstrating feasibility.

  • Motivation: Heterogeneous, geographically distributed systems make resource management and microservice deployment harder while users still require latency, storage, QoS, and availability goals.The compute continuum combines cloud scalability with edge proximity, but edge resource constraints and cloud network latency complicate placement.
  • Research challenge: Low-level SLOs support placement decisions but raise the entry barrier for users without detailed continuum knowledge.The paper motivates high-level business vocabulary as a more accessible way to express placement requirements.
  • Proposed approach: MicroIntent translates natural-language user intents into actionable SLOs and combines them with infrastructure descriptions to recommend microservice placement.Its architecture contains a high-level intent parser and a placement generator using rule-based matchmaking.
  • Proposed approach: The paper proposes an LLM-based extraction method for converting natural-language intents into low-level SLOs.This uses generative AI and NLP capabilities to support placement decisions.
  • Evaluation: Experiments on a Minimum Viable Prototype demonstrate the feasibility of generating placement strategies.The contribution is intended to simplify placement for compute-continuum users and lower adoption barriers.

II. RELATED WORK

Prior work addresses continuum placement through resource management, workflow handling, performance adjustment, and intent translation. However, existing approaches generally rely on formal or lower-level inputs rather than natural human language for placement decisions.

  • Existing placement approaches: Existing continuum placement research primarily focuses on managing compute and network resources, while user-facing intent expression receives less attention.The literature includes approaches based on QoS, SLAs, load balancing, and resource adjustment.
  • Intent-based approaches: Fog-mesh approaches parse intents into workflows while considering end-user locality and QoS constraints, but do not support natural human language.This leaves an expertise barrier for users with limited technical knowledge.
  • Intent-based approaches: Some systems accept high-level vocabulary or intent descriptions but manage service resources or metadata rather than recommending service locations directly.Spillner et al. adjust resources at already selected nodes, while Filinis et al. require keyword-based metadata.
  • Natural-language translation: LLM-related intent translation appears in prior work, but some approaches still accept SLOs directly or use constrained language-processing frameworks.LUMI translates natural language for IBN deployment, while other work does not support unrestricted natural-language input for continuum placement.

C. Research Gap in Existing Work

The identified gap is the limited use of human-comprehensive business vocabulary for microservice placement. MicroIntent proposes a generic architecture that translates such intents into SLOs and supports interchangeable placement algorithms.

  • Research gap: Existing solutions emphasize formal intent inputs rather than human-comprehensive vocabulary for continuum placement.This limits direct accessibility for users who lack lower-level system expertise.
  • Proposed architecture: MicroIntent addresses this gap by providing service-placement strategies from high-level business vocabulary.The architecture is presented as a generic approach for intent-based placement.
  • Intent Parser: The architecture consists of an Intent Parser that translates natural-language intentions into low-level SLOs recorded in JSON.The JSON output is consumed by the next module.
  • Placement Generator: The Placement Generator combines parsed SLOs with a JSON infrastructure description to generate recommended placements using a placement algorithm.The two required inputs are the continuum infrastructure description and application intents.
  • Infrastructure description: The infrastructure description represents compute-node hardware and software together with networking details across continuum layers.Described resources include CPU, GPU, memory, storage, operating systems, bandwidth, and latency.

2) User Intents:

MicroIntent accepts natural-language service intents and infrastructure descriptions, uses an LLM to extract structured SLOs, and matches those SLOs to continuum nodes. The output is a service-to-node placement recommendation.

  • User Intents: Natural-language intents can specify deployment locations and resource needs, which the architecture translates into networking or compute SLOs.The architecture assumes containers host the microservices.
  • Intent Parser: The Intent Parser augments user intents with infrastructure information and formulates constrained prompts for an LLM to extract matching SLOs.Prompt constraints align extraction with user intents and the available infrastructure.
  • Intent Parser: The parser constrains LLM output to JSON-formatted SLOs, representing ranges with minimum and maximum values when needed.A single supplied value is represented by equal minimum and maximum bounds.
  • Intent Parser: The extracted JSON contains service names, target metrics, values, units, and optional preferred deployment locations.The LLM response is refined before being stored in the JSON container.
  • Placement Generator: The Placement Generator receives extracted SLOs and the infrastructure description, then uses matching to produce service-node recommendations.The SLO-Driven Node Matching Algorithm outputs pairs directing services to suitable continuum nodes.
  • Placement Generator: The placement module can replace its algorithm as improved methods become available and supports testing algorithms against parsed SLOs.Users can deploy according to the generated recommendations with tools of their choice or supported deployment tools.

IV. EVALUATION

The evaluation presents an MVP for the proposed placement architecture and validates it through scenarios using natural-language intents and compute-continuum infrastructure descriptions as inputs.

  • Validation: The evaluation validates whether placement decisions depend on both user intents and compute-continuum infrastructure characteristics.Two scenarios are used for validation.
  • MVP Implementation: The MVP implements the proposed architecture to evaluate microservice placement strategy recommendations.It includes an Application Interface layer and an API layer.
  • MVP Implementation: Figure 3 shows natural-language intents and infrastructure descriptions supplied to the architecture through the user interface.The interface invokes APIs and delivers the resulting placement strategy to users.

2) Application Programming Interface (API) Layer:

The API layer converts natural-language intents and infrastructure descriptions into structured SLOs, using an LLM and JSON-based processing before placement generation.

  • API Layer: The API layer exposes placement-strategy generation and uses the Intent Parser and Placement Generator as its core components.It is implemented with Flask and can be integrated into users’ preferred platforms.
  • Intent Parser: The Intent Parser uses an LLM to translate natural-language intents into SLOs using infrastructure information for metric and unit matching.The MVP uses GPT-4o, GPT-4o-mini, and GPT-4 models.
  • Intent Parser: The parser defaults the layer to any and requires each service to have a unique service, layer, and SLO structure.Latency between services or nodes in the same layer can be represented as zero under stated rules.
  • Intent Parser: The parser represents networking and hardware requirements with metric, unit, and minimum–maximum target fields.Networking includes metrics such as latency and bandwidth, while hardware includes memory and processor-related metrics.
  • Intent Parser: Units are matched to infrastructure metrics and converted when necessary, while unsupported metrics are excluded.Metric names must match those used in the infrastructure description.
  • Data Processing: The processed LLM response is cleaned and saved as JSON for use by the Placement Generator.The output includes service, target metrics, values, units, and an optional preferred deployment location.

4) Placement Generator:

The Placement Generator matches each service’s SLOs against eligible continuum nodes, supporting numeric and non-numeric requirements before producing service-to-node mappings.

  • Placement Algorithm: Algorithm 1 iterates over services and first restricts candidate nodes to the service’s declared layer when applicable.If no layer is declared, all layers are considered.
  • Placement Algorithm: The algorithm checks networking SLOs through switches and hardware SLOs against nodes to build potential placements.Nodes are retained when they satisfy the relevant SLO conditions.
  • Requirement Handling: The placement logic handles numeric and non-numeric metric values, including minimum and maximum numeric bounds.The prototype’s only explored non-numeric metric is location, distinguishing cloud and edge deployment.
  • Output: After mapping services to nodes, the generator outputs JSON objects containing each service and its selected node.The result is consumed by the Application Interface layer.

B. Validation

The validation examines whether the MVP generates service-to-resource mappings from user intents and infrastructure characteristics using the SLO-driven node-matching algorithm.

  • Validation: The experiments conclude that the MVP generated service-to-resource mappings based on prompted user intents and compute-continuum infrastructure characteristics.This is the stated validation outcome.
  • Validation Inputs: Validation requires both node configuration and output placement JSON to assess whether recommendations satisfy the supplied intent.The architecture maps recommended nodes to the intended services.
  • SLO-Driven Node Matching: The algorithm processes each service, selecting layers and nodes before evaluating networking and hardware SLOs.The pseudocode iterates through services and their SLOs, checking switches and nodes for compliance.
  • SLO-Driven Node Matching: Networking SLO checks add nodes attached to switches that satisfy the requirement, while hardware checks add nodes meeting the corresponding SLO.Potential nodes are accumulated from both resource categories.
  • Placement Output: The algorithm adds placement suggestions after evaluating candidate nodes and records the selected service-to-node association.The pseudocode includes the mapping of a service to the first selected node.

25 Return(placement suggestions)

Experiments were conducted across two scenarios to validate deployment strategies generated by the proposed architecture, varying user intent and compute continuum descriptions.

  • Two scenarios validate deployment strategies by changing user intent in one case and compute continuum descriptions in the other.

1) Scenario 1: Compute Location Verification:

Scenario 1 tests whether the system responds to service-specific intents using a fixed compute continuum description. It maps services to edge and cloud nodes that satisfy location and memory requirements.

  • Scenario 1: Compute Location Verification: Scenario 1 evaluates placement changes driven by user intent within infrastructure description Inf1.
  • Scenario 1: Compute Location Verification: The application contains Scheduling Service S1 and Data Aggregation Service S2, with intents requesting high memory and specified deployment locations.Intent i1 requests edge-layer deployment and high memory for S1, while i2 requests the highest memory capacity across the continuum for S2.
  • Scenario 1: Compute Location Verification: Inf1 describes compute resources distributed across edge and cloud layers, with nodes associated with network switches.The infrastructure includes cloud nodes n1–n3, edge nodes n4–n6, and switches w1–w3.
  • Scenario 1: Compute Location Verification: S1 → n6 ∈ Nedge and S2 → n3 ∈ Ncloud satisfy the location and memory intents.The selected nodes provide 64 GB for S1 at the edge and 256 GB for S2 as the highest-memory node in the continuum.

2) Scenario 2: Compute Resource Verification:

Scenario 2 tests infrastructure changes while keeping the user intents unchanged. The prototype adapts placement to newly added higher-memory nodes and demonstrates responsiveness to both intent and infrastructure changes.

  • Scenario 2: Compute Resource Verification: Scenario 2 changes the infrastructure description by adding two compute nodes with higher memory capacity while retaining the Scenario 1 intents.
  • Scenario 2: Compute Resource Verification: The prototype generated a different placement from Scenario 1 despite unchanged user intents.
  • Scenario 2: Compute Resource Verification: Updated infrastructure led the prototype to select n8 for S1 at the edge and n7 for S2 across the continuum.These selections satisfy the requested highest-memory conditions for the respective deployment scopes.
  • Scenario 2: Compute Resource Verification: Together, the scenarios demonstrate reactions to changes in intent and infrastructure when making placement decisions.
  • Scenario 2: Compute Resource Verification: Future work will add intent conflict management, feedback mechanisms, and LLMs trained to extract SLOs from human language.
Loading 2609.07927v1…