IEEE Internet Computing
Orchestrating Serverless Applications in the Edge-Cloud-Space Continuum: What Breaks and What’s Next? Hadi Tabatabaee Malazi ‡ , School of Computer Science, University College Dublin, Ireland Reza Farahani ‡∗ , Distributed Systems Group (DSG), TU Wien, Austria Nitinder Mohan, Faculty of Electrical Engineering, Mathematics, and Computer Science, TU Delft, Netherlands
arXiv:2605.04316v1 [cs.DC] 5 May 2026
Schahram Dustdar, Distributed Systems Group (DSG), TU Wien, Austria and ICREA Barcelona, Spain ‡ Hadi Tabatabaee Malazi and Reza Farahani contributed equally to this work. ∗ Corresponding author: [email protected]
Abstract—Serverless computing has matured into an effective execution model for edge-cloud environments, enabling function-level decomposition, demand-driven scaling, and workflow execution across stable, well-provisioned infrastructure. This success motivates extending it to the edge-cloud-space continuum, where Low Earth Orbit (LEO) constellations are increasingly explored as distributed compute substrates. However, existing serverless orchestration is not directly applicable in this setting, where LEO systems impose time-varying contact graphs, intermittent link availability, and strict feasibility constraints on energy, memory, communication, and operational cost. This article identifies ten broken assumptions in existing serverless orchestration and organizes them into three core challenges: spatiotemporal execution over dynamic graphs, constraint-aware function placement and scaling, and correctness and progress under decentralized and delayed state. It then proposes an architecture that enables robust and efficient serverless execution across the continuum, grounded in these challenges and demonstrated through a representative flood-response use case.
From Stable Clouds to Dynamic Orbits: Why Serverless Orchestration Breaks Serverless computing has become a dominant execution model in edge-cloud environments by abstracting resource management and enabling eventdriven, function-level execution. In this context, the orchestrator determines where and when functions execute, how they scale, and how to access intermediate states through managed services. These decisions implicitly rely on stable connectivity, continuous resource availability, and timely global control. These assumptions break down when execution moves beyond terrestrial edge/cloud
XXXX-XXX © 2026 IEEE Digital Object Identifier 10.1109/XXX.0000.0000000 May
Published by the IEEE Computer Society
infrastructure to include Low Earth Orbit (LEO) satellites [1], forming an edge-cloud-space (ECS) continuum. In this setting, execution is no longer purely resource-driven but is constrained by time-varying connectivity, delayed observations, and restrictions on where intermediate states can be stored and moved. The following flood response scenario makes these differences explicit. Consider a severe storm hitting a rural river basin overnight. At 06:00, hundreds of residents use an emergency application to report roads being overtopped, while rain gauges show a sharp rise. Edge-side functions remove duplicate reports, group them by location, and generate a flood alert that identifies likely affected road segments and assigns an initial confidence score to the alert. The system must produce a road-closure risk map for downstream towns within a strict 20-minute decision window. The initial risk map can be generated from local reports IEEE Internet Computing
1
IEEE Internet Computing
FIGURE 1. Serverless flood detection and response workflow across the edge-cloud-space continuum.
and sensors, but an accurate assessment of flood extent and road-closure risk requires satellite imagery. This data is not continuously available. It becomes accessible only when a suitable LEO satellite has an observation or communication opportunity. The workflow thus produces an initial map and refines it as new observations become available. Cloud services fuse these updates with historical data to stabilize predictions. At the same time, governance constraints require that raw reports remain within the local domain, while only anonymized aggregates and derived products can be shared. This workflow highlights that correctness depends not only on processing data, but also on aligning computation with when data becomes available and where that data is permitted to move. Executing this workflow requires more than reactive placement and scaling. The orchestrator must transform bursty inputs into a validated trigger, schedule a multi-stage workflow under a strict deadline, and support progressive refinement as new data arrives. This introduces three tightly coupled requirements: 1) Time-dependent execution. Function placement and scheduling must align with communication 2
opportunities defined by satellite contact windows and evolving paths. 2) State-dependent execution. The workflow relies on an evolving intermediate product, the operational flood state, whose placement and movement determine whether downstream stages can progress without repeated multi-hop transfers. 3) Policy-constrained execution. Trust boundaries restrict where functions can execute and how data can move, coupling orchestration decisions with governance requirements. In conventional cloud and edge settings, serverless platforms react to events, place functions based on available compute, and scale replicas to meet demand. The network is assumed to be continuously reachable, application state is externalized to backend services, and a centralized control plane adapts execution based on global telemetry. In such a flood response scenario, none of these assumptions holds. Connectivity is intermittent, and the topology evolves over time. Resource availability is bounded and heterogeneous, particularly in the space tier. Moreover, control decisions must often be made from stale and incomplete views of the system. Hence, correctness
Orchestrating Serverless Applications in the Edge-Cloud-Space Continuum
May 2026
IEEE Internet Computing
Takeaway. The ECS continuum changes the nature of serverless orchestration. It introduces temporal constraints, state locality challenges, and policy coupling that invalidate the assumptions underlying existing systems. depends not only on where functions execute, but also on when they execute and how state is propagated across the system. This article identifies ten broken assumptions in existing serverless orchestration, organizes them into concrete system-level challenges, and designs an architecture for robust and efficient execution across the ECS continuum, demonstrated through a representative flood-response use case.
Broken Assumptions in Serverless Orchestration Conventional orchestration methods are effective in cloud and terrestrial edge settings because their core assumptions, i.e., continuous reachability, stable topology, low-latency state access, elastic scaling, and centralized control, largely hold. In the ECS continuum, these assumptions break systematically due to orbital motion, intermittent connectivity, and hard resource constraints [2]. As a result, orchestration strategies that are valid in the cloud become infeasible or suboptimal when applied across the ECS continuum. This section identifies ten broken assumptions (BA1– BA10) and maps them onto three core orchestration challenges (C1–C3). These challenges define the core responsibilities of an ECS continuum-aware orchestrator and directly motivate the architecture presented in the next section.
C1: Spatiotemporal Execution over Dynamic Graphs In the ECS continuum, execution feasibility is not a static property of nodes but a time-dependent one, determined by communication opportunities [3], endto-end paths [4], and execution bindings. Orchestration must therefore ensure both computation and data exchange remain feasible over the entire execution horizon. BA1: Instantaneous reachability implies execution feasibility. Serverless orchestration assumes that reachability at invocation time is sufficient to admit, execute, and complete a function. • Breakage. Reachability is bounded by short contact windows [3]; nodes reachable at invocation may be unreachable before execution, state transfer, or result delivery completes [5]. May 2026
• Implication. Execution must be temporally feasible, aligning placement and data exchange with predicted contact windows across workflow stages. BA2: Connectivity implies path feasibility. Existing systems implicitly assume that network connectivity guarantees usable end-to-end communication for state access and function chaining. • Breakage. In space-ground networks, connectivity does not guarantee feasible communication [6]. Endto-end paths change over time, and the properties of different link types (e.g., RF vs. FSO) introduce variability in latency, throughput, and reliability [7]. Multi-hop paths may therefore fail to meet the required data transfer deadlines [5]. • Implication. The orchestrator must evaluate timevarying path feasibility, including whether required data transfers can complete within service-level objective (SLO) constraints. BA3: Execution binding is stable. Serverless systems assume that once a function is placed, its execution context (node, resources, and data dependencies) remains stable during execution. • Breakage. Execution and communication bindings change as LEO satellites move and handovers occur [8], while compute, memory, and accelerator availability fluctuate under concurrent workloads and onboard constraints [5]. • Implication. Execution must be time-indexed and re-bindable, supporting dynamic reassignment and continuity under changing conditions.
These broken assumptions jointly indicate that execution feasibility must be enforced over time, not at a single decision point. This leads to the first research question (RQ1): “How should an orchestrator place and schedule workflow stages over a time-varying space-ground graph such that computation and data exchange remain feasible throughout execution under SLO constraints?” Addressing this requires the orchestrator to enforce spatiotemporal feasibility as a first-class constraint, leading to the following design implications: • Contact window-aware scheduling: Align execution and data transfer with predicted communication windows. • Time-indexed planning: Make placement decisions over execution horizons rather than single time points. • Path-aware feasibility analysis: Evaluate end-toend data movement feasibility over dynamic multihop paths.
Orchestrating Serverless Applications in the Edge-Cloud-Space Continuum
3
IEEE Internet Computing
• Re-bindable execution: Support migration and reassignment under changing associations and resource conditions.
• Accelerator-aware placement: Allocate scarce heterogeneous resources efficiently under constraints.
C2: Constraint-Aware Function Placement and Scaling
C3: Correctness and Progress under Decentralized and Delayed State
In the ECS continuum, execution is not governed by elastic resource availability but by hard feasibility constraints, including energy budget, onboard thermal headroom [9], memory capacity [5], and accelerator availability [10]. Orchestration must therefore ensure that placement and scaling decisions remain feasible under these constraints. BA4: Elasticity implies available headroom. Serverless systems assume that additional capacity can be activated on demand.
In the ECS continuum, the orchestrator must maintain forward progress despite intermittent connectivity, stale system state, and cross-domain constraints. Execution correctness can no longer rely on a single control plane and must instead be maintained under weak connectivity.
• Breakage. Execution is bounded by energy, thermal limits [9], and memory headroom [5]. Scaling decisions may violate feasibility even when computational resources are available [5]. • Implication. Scaling must be feasibility-aware, constrained by resource limits rather than driven solely by demand. BA5: Execution configuration is static. Execution modes (e.g., CPU vs. GPU) are typically fixed or developer-defined. • Breakage. Static configurations fail under dynamic load and heterogeneous resources, leading to inefficient utilization or SLO violations [10]. • Implication. Execution must be adaptively configured, with orchestration co-deciding placement and execution mode at runtime.
These breakage points reveal that execution feasibility is bounded by hard system constraints rather than elastic resource provisioning. This motivates the second research question (RQ2): “How should an orchestrator control scaling and choose execution configurations so that workflow stages remain feasible under energy, onboard thermal, memory, and accelerator constraints?” An orchestrator must therefore treat resource feasibility as a primary decision constraint, which leads to the following design implications: • Energy- and thermal-aware admission control: Admit or defer execution based on predicted resource margins. • Time-aware execution planning: Align execution with periods of sufficient resource availability. • Dynamic execution-mode selection: Adapt CPU/GPU configurations based on workload and system state. 4
BA6: Remote state is close enough. The statelessby-default serverless model externalizes state to managed services and typically assumes those services are reachable with predictable overhead. • Breakage. Remote state access can dominate workflow latency and bandwidth consumption under intermittent connectivity and multi-hop paths [11]. This cost can become asymmetric when constrained uplinks limit state propagation and the exchange of intermediate data. • Implication. State must be explicitly placed and propagated, treating data movement as ratelimited and direction-dependent rather than implicitly available. BA7: Workflow handoff overhead is negligible. Workflow composition of serverless functions assumes that inter-function data exchange is insignificant [12]. • Breakage. Repeated state reads/writes and handoffs amplify latency and bandwidth overheads across constrained space-ground, inter-satellite, and edge-cloud paths [11]. • Implication. Execution must be compositionaware, applying fusion and co-location to reduce unnecessary data movement. BA8: Cloud-style failure and recovery assumptions. Serverless systems assume frequent monitoring and rapid, centrally coordinated recovery. • Breakage. Recovery must operate under partitions and constrained coordination, where connectivity to control planes or replicas may be unavailable [13]. • Implication. Execution must be partition-tolerant, supporting checkpoint-aware scheduling [8] and recovery mechanisms that remain feasible under intermittent connectivity. BA9: Centralized control assumes timely and consistent state. Serverless orchestration typically
Orchestrating Serverless Applications in the Edge-Cloud-Space Continuum
May 2026
IEEE Internet Computing
TABLE 1. Mapping between broken assumptions, research questions, and orchestration implications. BA
Broken assumption
BA1
Instantaneous reachability execution feasibility
BA2
Connectivity implies path feasibility
RQ1
BA3
Execution binding is stable
RQ1
BA4
Elastic scaling assumes resource headroom
BA5
Execution configuration is static
RQ2
BA6
Remote state is close enough
RQ3
BA7
Workflow handoff overhead is negligible
RQ3
BA8
Cloud-style assumptions
recovery
RQ3
BA9
Centralized control assumes timely and consistent global state
RQ3
BA10
Single-domain governance
RQ3
failure
uniform
and
implies
available
policy
and
Mapped RQ
Implication for orchestration
RQ1
Execution must be temporally feasible over the stage lifetime, aligning placement and data exchange with predicted contact windows. Orchestration must ensure time-varying end-to-end path feasibility, accounting for dynamic topology and link characteristics. Execution must be time-indexed and re-bindable, supporting reassignment under mobility, handovers, and changing resource conditions. Scaling must be feasibility-aware, constrained by energy, thermal, and memory limits rather than reactive demand. The orchestrator must co-decide placement and execution mode, adapting configurations (e.g., CPU/GPU) at runtime. State placement and propagation must be explicit decisions, treating data movement as rate-limited and asymmetric. Composition must be optimized via fusion and colocation to reduce data movement overheads. Recovery must be partition-tolerant, supporting checkpoint-aware execution under constrained coordination. Orchestration must tolerate stale and partial information, requiring prediction-aware decisions and delayed reconciliation. Orchestration must be policy-aware, enforcing trust, compliance, and data movement constraints across domains.
RQ2
relies on a centralized (or logically centralized) control plane operating on up-to-date global system state [12]. • Breakage. In the ECS continuum, telemetry is delayed, partial, and dependent on intermittent connectivity [5]. The control plane operates on stale and potentially inconsistent views of the system [5]. • Implication. Centralized orchestration must be robust to stale and partial information, incorporating prediction, uncertainty-aware decision-making, and delayed state reconciliation. BA10: Single-domain uniform policy and governance. Serverless systems assume a single administrative domain with uniform access and compliance. • Breakage. Execution spans multiple domains with heterogeneous governance, trust, and security constraints [5], where data movement and execution must comply with domain-specific policies [14]. In orbital environments, orchestration may operate under adversarial conditions, including jamming, spoofed connectivity predictions, compromised nodes, or untrusted supply chains [13]. • Implication. Orchestration must be policy- and trustaware, enforcing placement, data movement, and execution constraints as part of scheduling decisions while tolerating potentially unreliable or adversarial system information. May 2026
These assumption failures show that correctness must be ensured under partial knowledge, constrained coordination, and cross-domain restrictions. The resulting research question (RQ3) is: “How can an orchestrator ensure correctness and forward progress by managing state, composition, recovery, and policy under intermittent connectivity and stale system state?” Addressing this requires the orchestrator to enforce progress-with-assurance under weak connectivity, leading to the following design implications:
• State-aware placement and propagation: Decide where the intermediate state resides and how it is staged or replicated to minimize remote access. • Composition-aware optimization: Apply fusion and co-location to reduce data movement overheads. • Partition-tolerant progress and recovery: Support checkpointing, rollback, and decentralized recovery under limited coordination. • Decentralized control under stale telemetry: Enable local autonomy with eventual consistency. • Policy-aware orchestration across domains: Enforce governance constraints on placement and data movement.
Orchestrating Serverless Applications in the Edge-Cloud-Space Continuum
5
IEEE Internet Computing
ECS Continuum Orchestration Architecture Continuum Control Layer Placement Engine
n tio ell a ns t Co O LE
Energy Planning Engine
Communicator
Policy Manager
ISL
Contact Window
Federation Engine
Migration Engine
Processor
Ground Station
Service Orchestration Layer Trust Manager
State Manager Connectivity Manager Event Dispatcher
Cl
ou d
Workflow Engine Data Locality Manager
Ed ge
Function Execution Layer FaaS Runtime Execution Controller Telemetry Agent Energy Coordinator
Resource Abstraction
FIGURE 2. ECS continuum orchestration system architecture.
ECS Continuum Orchestration Architecture Fig. 2 presents the proposed Edge-Cloud-Space (ECS) orchestration architecture, designed to address the fundamental mismatches identified in the previous section. The architecture explicitly models the continuum as a composition of edge nodes, cloud infrastructure, and LEO constellations. It assumes that a subset of satellites are processing-capable (processors) and may expose heterogeneous compute profiles (e.g., CPU-only or accelerator-enabled nodes), while others primarily operate as communication relays (communicators) [15]. These entities are interconnected via inter-satellite links (ISLs) and time-bounded ground contacts (contact windows). Control decisions may be coordinated from terrestrial infrastructure, orbital nodes, or hybrid deployments, depending on connectivity and mission requirements. Consequently, orchestration operates under delayed, partial, and time-varying system visibility rather than assuming a continuously synchronized global state. Unlike cloud-based designs, execution feasibility in this continuum is governed by time-varying connectivity, constrained resources, and delayed system state. The architecture, thus, separates concerns into three layers: (i) a continuum control layer for global, constraint-aware decision making, (ii) a service orchestration layer for workflow coordination under dynamic conditions, and (iii) a function 6
execution layer for on-node execution of serverless functions. This decomposition directly aligns with the three challenges C1 (spatiotemporal feasibility), C2 (resource feasibility), and C3 (correctness under delayed and decentralized state). Revisiting the flood response workflow. In the motivating scenario, initial flood detection is triggered at the edge, refined using satellite imagery, and stabilized in the cloud. This requires (i) aligning execution with satellite contact windows (C1), (ii) respecting onboard energy and compute limits (C2), and (iii) ensuring progress despite delayed observations and cross-domain constraints (C3). The proposed architecture operationalizes these requirements as follows.
Continuum control layer This layer performs global, constraint-aware optimization over a logically centralized but physically distributed control plane. It explicitly addresses spatiotemporal feasibility (RQ1) and resource feasibility (RQ2). • Placement engine: Computes the initial placement of workflow stages by jointly considering node capabilities, predicted contact windows, and timevarying path feasibility [16]. This directly resolves BA1–BA3 by ensuring that placement decisions remain valid over the execution horizon rather than at invocation time.
Orchestrating Serverless Applications in the Edge-Cloud-Space Continuum
May 2026
IEEE Internet Computing
• Energy planning engine. Models energy availability, thermal limits, and memory headroom across nodes, particularly in LEO processors. It enforces feasibility-aware scaling (BA4) and prevents invalid deployments under constrained onboard resources (RQ2). • Migration engine: Enables time-indexed rebinding of execution by relocating functions when connectivity, resource availability, or associations change. It operationalizes continuity under mobility (BA3) and maintains feasibility across evolving contact windows (C1). • Policy manager: Encodes SLOs, placement restrictions, and governance rules as hard constraints. It ensures that orchestration decisions remain policy-compliant across administrative domains (BA10) and integrates governance into scheduling. • Federation engine: Coordinates execution across multiple administrative domains (edge, cloud, satellite), enabling cross-domain orchestration while preserving trust and policy constraints, directly addressing BA10 and RQ3.
Service orchestration layer This layer translates global decisions into executable workflows while maintaining consistency under intermittent connectivity and delayed state. • Workflow engine. Manages DAG-based workflow execution and dependency resolution under timevarying feasibility. It integrates scheduling decisions from the control layer and ensures stage execution aligns with contact opportunities (C1). • Connectivity manager. Maintains a time-indexed view of the space-ground graph, including ISLs and contact windows. It enables spatiotemporal reasoning over links and paths, directly addressing BA1 and BA2 by exposing when and how communication is feasible. • State manager. Maintains distributed workflow state and supports checkpointing and recovery. It enables partition-tolerant execution (BA8) and ensures forward progress under intermittent connectivity (C3). • Data locality manager. Controls placement and movement of intermediate data across tiers, minimizing remote state access penalties (BA6) via co-locating computation and data. • Trust manager. Ensures that sensitive operations remain within trusted domains and validates orchestration constraints under federated and potentially adversarial environments, directly addressing BA10. May 2026
• Event dispatcher. Implements event-driven invocation across the continuum. It transforms bursty inputs (e.g., flood reports) into coordinated workflow triggers and routes them under connectivity constraints.
Function execution layer This layer realizes execution on edge devices, cloud servers, and LEO processors. • Function-as-a-Service (FaaS) runtime. Executes fine-grained functions with lightweight isolation across heterogeneous hardware. • Execution controller. Implements local scheduling and enforces resource allocations under constraints imposed by upper layers. • Resource abstraction. Provides a unified interface to heterogeneous compute resources and accelerator profiles (CPU, GPU, NPUs, domainspecific accelerators), enabling adaptive execution modes under heterogeneous onboard capabilities (BA5). • Energy coordinator. Applies platform-exposed runtime power-management actions, such as throttling or concurrency limiting, where available, to enforce energy-aware decisions from the control layer (BA4). • Telemetry agent. Continuously collects system state, including resource usage, energy, and connectivity. Given delayed and partial visibility (BA9), telemetry is used for prediction-aware and uncertainty-aware decision-making rather than instantaneous control.
Cross-layer interaction and guarantees. The architecture forms a closed loop: telemetry flows upward from execution nodes, while placement, scaling, and migration decisions flow downward. Unlike cloud systems, this loop operates under a delayed and partial state, requiring predictive and time-indexed reasoning. Across layers, the architecture enforces three invariants: • Spatiotemporal feasibility: Execution and data movement are aligned with contact windows and time-varying paths. • Resource feasibility: Placement and scaling respect energy, thermal, and hardware constraints. • Progress-with-assurance: Workflows continue execution under partitions, delayed state, and crossdomain policies.
By explicitly integrating connectivity dynamics, resource constraints, and distributed control into orchestration decisions, the architecture addresses the ten broken assumptions (BA1–BA10) and provides a
Orchestrating Serverless Applications in the Edge-Cloud-Space Continuum
7
IEEE Internet Computing
concrete blueprint for serverless execution across the edge–cloud–space continuum.
ECS Orchestration Implementation Challenges The ECS architecture defines the orchestration responsibilities needed to execute serverless workflows across edge, cloud, and LEO infrastructures. However, realizing this architecture as an interoperable platform requires more than adding satellite nodes to existing serverless systems. The main gap is standardization: current FaaS platforms, workflow engines, telemetry stacks, and resource managers do not expose common abstractions for contact windows, time-varying paths, onboard feasibility limits, stale telemetry, or cross-domain policies. This section summarizes seven implementation challenges (IC1IC7 ) that must be addressed before ECS orchestration becomes a standardized platform capability. IC1: Contact-window and path abstraction. Existing schemes typically expose node availability and network metrics, but not time-indexed contact windows, ISL links, or predicted path feasibility. Standardized interfaces are needed for representing when links exist, how long they persist, and whether a workflow stage can exchange its required data within an SLO. This directly supports C1/RQ1 and the connectivity manager, placement engine, and workflow engine. IC2: Feasibility-aware resource model. Current serverless runtimes mostly expose CPU, memory, and concurrency limits. ECS execution requires richer models that capture energy budgets, onboard thermal state, accelerator availability, memory capacity, and communication cost [17]. Without a common feasibility model, placement and scaling remain cloud-style decisions that may be invalid on LEO processors or constrained edge nodes [18]. This supports C2/RQ2 and the energy planning engine, resource abstraction, execution controller, and energy coordinator. IC3: Time-indexed orchestration APIs. Standard FaaS and workflow systems are invocation-centric. They trigger functions in response to events and scale based on demand signals such as request rate, queue depth, or concurrency. ECS workflows require plans over execution horizons. APIs must support deferred execution, validity intervals, contact-aware reservations, re-binding, and migration triggers. This connects C1 and C2 to the placement, migration, and workflow engines. IC4: State and data locality primitives. Serverless platforms externalize state to storage services and 8
assume remote access overhead remains within acceptable bounds. ECS orchestration requires explicit state placement, staging, replication, checkpointing, and function-state fusion to avoid repeated multi-hop transfers [19]. These primitives are central to C3/RQ3 and map to the state and data locality managers. IC5: Stale telemetry and uncertainty handling. Cloud controllers assume fresh telemetry. In ECS, telemetry can be delayed, partial, or unavailable during partitions. Implementations, therefore, need telemetry freshness metadata, confidence intervals, prediction hooks, and reconciliation mechanisms. This supports C3/RQ3 and maps to the telemetry agent, connectivity manager, and control layer. IC6: Cross-domain policy and trust interface. ECS workflows cross administrative boundaries among edge operators, cloud providers, satellite operators, and data owners. Standard orchestration interfaces must express placement constraints, data locality rules, trust levels, identity, authorization, and compliance requirements. This supports BA10/C3 and maps to the trust manager, policy manager, and federation engine. IC7: Failure semantics under intermittent connectivity. Current platforms usually define retry, timeout, and failure semantics under the assumption of continuous control-plane reachability. ECS execution needs partition-aware semantics, i.e., when to retry, defer, checkpoint, migrate, or continue locally under disconnected operation. This supports C3/RQ3 and maps to the state manager, execution controller, and migration engine. Overall, these challenges show that ECS orchestration is not only an implementation problem but also a standardization problem. Existing platforms provide useful building blocks, but they lack shared abstractions for time, feasibility, state, and policy across space-ground environments. Closing this gap is necessary before serverless orchestration can become a portable execution model for the edge-cloud-space continuum.
ECS Orchestration in Action: Representative Use Cases To demonstrate how the proposed ECS architecture operates in practice, we revisit and extend the motivating flood response scenario as a representative use case from the disaster response and humanitarian operations domain. This scenario stresses all three orchestration challenges (C1–C3) and exposes the necessity of ECS-specific design decisions.
Orchestrating Serverless Applications in the Edge-Cloud-Space Continuum
May 2026
IEEE Internet Computing
TABLE 2. Implementation challenges and their mapping to ECS orchestration requirements. ID IC1
Implementation challenge Contact-window and abstraction
IC2
Feasibility-aware resource model
RQ2 / C2
IC3
Time-indexed orchestration APIs
RQ1–RQ2 / C1–C2
IC4
State and data locality primitives
RQ3 / C3
State manager, data locality manager
IC5
Stale telemetry and uncertainty handling
RQ3 / C3
IC6
Cross-domain policy and trust interface Failure semantics under intermittent connectivity
RQ3 / C3
Telemetry agent, connectivity manager, continuum control layer Trust manager, policy manager, federation engine State manager, execution controller, migration engine
IC7
path
Main RQ/C RQ1 / C1
RQ3 / C3
Use Case Overview: Flood Detection and Response A flood event is initially detected by edge sensors (e.g., river gauges, cameras). The objective is to generate timely situational awareness, including flood extent maps and evacuation recommendations, by combining edge data, satellite imagery, and cloudbased analytics. The workflow consists of three stages: 1) Edge detection: Lightweight anomaly detection is triggered at edge nodes. 2) Satellite refinement: High-resolution imagery is processed onboard LEO satellites during contact windows. 3) Cloud aggregation: Results are consolidated, fused with historical data, and disseminated to authorities. This workflow spans heterogeneous domains and must execute under intermittent connectivity, constrained resources, and delayed system state.
Mapping to ECS Architecture The execution of this workflow is realized through coordinated interaction across the three ECS layers (Fig. 2). Continuum control layer: when each stage executes:
Determines where and
• Placement engine: Schedules the satellite refinement stage only within predicted contact windows, ensuring that image acquisition, processing, and result transmission are temporally feasible [20] (addresses BA1–BA2). • Energy planning engine: Selects satellites with sufficient onboard energy and thermal headroom to execute image processing tasks, avoiding infeasible deployments (addresses BA4). May 2026
Key components Connectivity manager, placement engine, workflow engine Energy planning engine, resource abstraction, execution controller, energy coordinator Placement engine, migration engine, workflow engine
Required standardization gap Common model for contact windows, ISLs, ground links, path validity, and transfer feasibility. Standard resource descriptors for energy budget, thermal headroom, accelerator availability, memory pressure, and communication cost. APIs for deferred execution, validity intervals, reservations, migration, and rebinding. Portable primitives for state placement, staging, replication, checkpointing, and function-state fusion. Telemetry freshness, confidence metadata, prediction hooks, and reconciliation semantics. Common policy model for trust, identity, locality, authorization, and compliance. Standard semantics for retry, defer, checkpoint, migrate, and local execution under disconnection.
• Migration engine: Reassigns processing to alternative satellites when contact conditions change or handovers occur, maintaining execution continuity (addresses BA3). • Policy and federation engines: Ensure that sensitive data (e.g., critical infrastructure maps) is processed only within trusted domains (e.g., cloud or authorized satellites), enforcing cross-domain constraints (addresses BA10). Service orchestration layer: Ensures correct execution progression under dynamic conditions: • Workflow engine: Coordinates progressive, dependency-aware workflow execution so that stages can run, defer, or resume as inputs, contact windows, and feasible data paths become available. • Connectivity manager: Maintains a time-indexed view of ISLs and ground contacts, enabling the system to decide whether intermediate data can be transferred within deadlines (addresses BA2). • State manager: Stores intermediate flood maps and supports checkpointing when connectivity is lost, enabling continuation after partitions (addresses BA8). • Data locality manager: Ensures that image processing is performed close to where data is generated (e.g., onboard satellites), minimizing costly multi-hop transfers (addresses BA6–BA7). • Event dispatcher: Transforms sensor-triggered flood alerts into workflow executions across the continuum. Function execution layer: node-level constraints:
Realizes execution under
• FaaS runtime: Executes flood detection and image processing functions across edge, cloud, and LEO nodes.
Orchestrating Serverless Applications in the Edge-Cloud-Space Continuum
9
IEEE Internet Computing
• Execution controller: Enforces local scheduling decisions and resource limits, ensuring compliance with energy and compute constraints (addresses BA4–BA5). • Resource abstraction: Enables adaptive execution modes (CPU vs. GPU) depending on available hardware. • Telemetry agent: Continuously reports system state (e.g., energy, load, connectivity), although telemetry may be delayed, incomplete, or stale. The control layer uses this information for prediction-aware decisions (addresses BA9).
ECS Orchestration Invariants The key reason this architecture is suitable is that it enforces three invariants that directly address the broken assumptions: • Spatiotemporal feasibility: Execution is aligned with contact windows and time-varying paths, ensuring that all stages complete within connectivity constraints. • Resource feasibility: Placement and execution respect energy, thermal, and hardware limits, avoiding invalid deployments. • Progress-with-assurance: Workflow execution continues under partitions via checkpointing, state propagation, and policy-aware control.
In contrast to conventional serverless systems, which assume continuous connectivity, elastic resources, and fresh global state, ECS orchestration explicitly models time, feasibility, and uncertainty as first-class concerns. This enables reliable execution of cross-domain workflows such as flood response, where correctness and timeliness depend on coordinated operation across edge, cloud, and space.
Generalization Across Domains Although demonstrated for disaster response, the same orchestration pattern applies across other domains (e.g., environmental monitoring, maritime surveillance, infrastructure inspection) [6]. In all cases, workflows exhibit time-dependent connectivity, constrained execution resources, and cross-domain coordination requirements. Thus, the ECS architecture provides a general blueprint for serverless orchestration across the edge-cloud-space continuum.
Conclusion This article identified fundamental mismatches between conventional serverless orchestration and 10
the requirements of the edge-cloud-space continuum, formalized as ten broken assumptions across three core challenges: spatiotemporal feasibility, resource feasibility, and progress-with-assurance under delayed and decentralized state. To address these gaps, we presented a multi-layer ECS orchestration architecture that elevates time-varying connectivity, hard resource constraints, and stale system state to first-class concerns, providing a concrete, implementable model aligned with the raised research questions. We further highlighted key implementation gaps that prevent current platforms from supporting ECS orchestration and demonstrated, through a representative floodresponse workflow, how the architecture enables correct and feasible execution across heterogeneous and intermittently connected domains. The next step is to turn these architectural responsibilities into portable orchestration interfaces, so that serverless platforms can treat time, feasibility, and trust as first-class execution concerns in space-ground environments.
REFERENCES 1. S. Wang and Q. Li, “Satellite Computing: Vision and Challenges,” IEEE Internet of Things Journal, 2023. 2. B. Denby and B. Lucia, “Orbital Edge Computing: Nanosatellite Constellations as a New Class of Computer System,” in International Conference on Architectural Support for Programming Languages and Operating Systems. Association for Computing Machinery, 2020. 3. V. Bhosale, A. Gavrilovska, and K. Bhardwaj, “Krios: Scheduling Abstractions and Mechanisms for Enabling a LEO Compute Cloud,” in ACM Symposium on Cloud Computing. Association for Computing Machinery, 2024. 4. S. Basak, A. Pal, and D. Bhattacherjee, “LEOCraft: Towards designing performant LEO networks,” in Annual Technical Conference, ser. USENIX ATC ’25. USENIX Association, 2025. 5. T. Pusztai, C. Marcelino, and S. Nastic, “HyperDrive: Scheduling serverless functions in the edgecloud-space 3D continuum,” in 2024 IEEE/ACM Symposium on Edge Computing. IEEE, 2024. 6. C. Guimarães, A. Netti, M. Sauer, F. Zeiger, H.P. Huth, and E. Boriskova, “A Survey on Satellite Computing: Connecting the Dots Between Networks and Applications,” IEEE Communications Surveys & Tutorials, 2026. 7. H. Wu, Y. Han, M. Rajpal, Q. Zhang, and J. Wang, “SaTE: Low-latency traffic engineering for satellite networks,” in ACM SIGCOMM 2025 Conference. Association for Computing Machinery, 2025.
Orchestrating Serverless Applications in the Edge-Cloud-Space Continuum
May 2026
IEEE Internet Computing
8. T. Pfandzelter and D. Bermbach, “Komet: A serverless platform for low-earth orbit edge services,” in 2024 ACM Symposium on Cloud Computing. Association for Computing Machinery, 2024. 9. R. Xing, M. Xu, A. Zhou, Q. Li, Y. Zhang, F. Qian, and S. Wang, “Deciphering the Enigma of Satellite Computing with COTS Devices: Measurement and Analysis,” in Annual International Conference on Mobile Computing and Networking. Association for Computing Machinery, 2024. 10. M. Reisecker, C. Marcelino, T. Pusztai, and S. Nastic, “Gaia: Hybrid Hardware Acceleration for Serverless AI in the 3D Compute Continuum,” in IEEE/ACM 12th International Conference on Big Data Computing, Applications and Technologies. Association for Computing Machinery, 2025. 11. C. Marcelino, L. Guelmino, T. Pusztai, and S. Nastic, “Databelt: A continuous data path for serverless workflows in the 3D compute continuum,” Journal of Systems Architecture, 2025. 12. Z. Li, L. Guo, J. Cheng, Q. Chen, B. He, and M. Guo, “The Serverless Computing Survey: A Technical Primer for Design Architecture,” ACM Computing Surveys, 2022. 13. E. Xue, Z. Zhang, J. Xue, H. Wang, I. E. CarvajalRoca, Z. He, H. Zhang, H. Wang, Z. Wan, and C. Li, “Space Computing: Architectures, Challenges, and Future Directions,” Intelligent Computing, 2025. 14. H. Shi, X. Zhang, P. Wu, J. Chen, and Y. Zhang, “ComEdge: Cloud-native platform for integrated computing and communication in satellite–terrestrial network,” Electronics, 2023. 15. H. Wang, K. Yao, L. Gong, Y. Jin, P. Zhang, Y. Liu, Y. Yuan, J. Xue, Z. Wan, Y. Liu, X. Li, C. Li, and Z. Zhao, “Space Computing Constellation: System Architecture, Implementations and Challenges,” IEEE Internet of Things Journal, 2026. 16. R. Zhang, J. Zhang, X. Wang, and W. Shi, “Utility optimization for computation offloading and splitting in time-varying hap and LEO satellite integrated mec networks,” Computer Networks, 2024. 17. L. Wang, Q. Liu, Q. Li, S. Wang, X. Liu, and C. Xu, “Emulating space computing networks with RHONE,” in Annual International Conference on Mobile Computing and Networking, 2025. 18. F. D. Rossi, P. S. S. d. Souza, and M. C. Luizelli, “Resource Allocation on Low-Earth Orbit Edge Infrastructure: Taxonomy, Survey, and Research Challenges,” IEEE Access, 2025. 19. Z. Yin, C. Wu, C. Guo, Y. Li, M. Xu, W. Gao, and C. Chi, “A Comprehensive Survey of Orbital Edge Computing: Systems, Applications, and Algorithms,” Chinese Journal of Aeronautics, 2025. May 2026
20. S. Liu, Z. Zhang, and S. Zeadally, “Device-SatelliteSatellite Collaborative Task Offloading Computing and Resource Allocation in 6G Satellite-Ground Edge Computing Network,” Computer Networks, 2026.
HADI TABATABAEE MALAZI is an Assistant Professor in the School of Computer Science at University College Dublin, Ireland. He leads the Sustainable Orchestration in Computing Continuum (SOC2 ) Lab and is an IEEE Senior Member. His research focuses on sustainable and resilient services computing. He is particularly interested in carbon-aware, constraint-aware, and reliability-aware orchestration of distributed services across edge–cloud, multi-cloud, and space-enabled computing environments. Contact him at: [email protected]. REZA FARAHANI (Corresponding author) is a Postdoctoral Researcher (University Assistant) at the Distributed Systems Group (DSG), TU Wien, Austria, and a Lecturer at the University of Klagenfurt, Austria. He has recently coordinated the Austrian EdgeAI-Drone project and participated in the ENFIELD Exchange Scheme funded by the European Union, focusing on Green AI. From 2019 to 2023, he was with the Christian Doppler Laboratory ATHENA and, from 2023 to 2026, contributed to the EU Graph-Massivizer project, where he led WP5 on serverless orchestration and large-scale edge–cloud testbeds. He was a Visiting Scholar at the University of Surrey, UK. His research interests include distributed and networked systems, edge-cloud continuum, serverless computing, distributed multimedia, agentic AI, and Green AI. Contact him at: [email protected]. NITINDER MOHAN is an Assistant Professor at the Delft University of Technology (TU Delft), Netherlands where he leads the Systems and Protocols for EdgeEnabled Internet (SPEAR) lab associated with Networked Systems group. His research has been awarded with several awards such as "Outstanding Ph.D. Dissertation Award 2020" by the IEEE TCSC, IETF/IRTF Applied Networking Research Prize, and several best paper awards at IEEE and ACM venues. His research interests are in edge computing, orchestration systems, nextgeneration cyber-physical systems, satellite networks, and wide-scale Internet measurements. Contact him at [email protected]. SCHAHRAM DUSTDAR is a Full Professor of Computer Science and Head of Distributed Systems Group (DSG) at TU Wien, Vienna, Austria, and is affiliated with ICREA, Barcelona, Spain. He holds several honorary positions, including Honorary Professor at Nanjing University of Science and Technology (since 2023) and Francqui Chair Professor at the University of Namur (2021–2022). He has held visiting positions at institutions including the University of Southern California (Los Angeles), Monash University, Shanghai University, Macquarie University, Universitat Pompeu Fabra (Barcelona), the University of Sevilla, and UC Berkeley. Contact him at [email protected].
Orchestrating Serverless Applications in the Edge-Cloud-Space Continuum
11