PaperlayerView exact revision on arXiv

Source-linked AI summary

Ermes: a Stateful Serverless Platform for the Edge-to-Cloud Continuum

Matteo Cenzato, Dario d'Abate, Arianna Dragoni, Giacomo Orsenigo, Luca Tosetti, Matteo Briscini, Alessandro Margara

arXiv:2609.18924v1cs.DC

TL;DR

Stateless FaaS can force edge functions to fetch state from remote stores, and replicated state brings consistency trade-offs. Ermes jointly distributes functions and state with per-collection consistency choices; its evaluation reports low client-perceived latency across workloads and consistency requirements.

  • Problem

    Stateless FaaS commonly leaves state in external stores, while replicated edge state requires balancing access latency against consistency guarantees.

    Source: §1 · pp. 1–2

  • Method

    Ermes jointly places functions and state across edge-to-cloud nodes and supports fine-grained replication with per-collection consistency levels.

    Source: §1 · p. 2

  • Results

    Ermes brings state close to computation and sustains low client-perceived latency across workloads and consistency requirements in an emulated geo-distributed deployment.

    Source: §8.5 · p. 16, §9 · p. 17

  • Takeaways & Limitations

    Ermes lets developers choose per-collection consistency, from sequential to eventual, to prioritize stronger guarantees or lower access latency.

    Source: §1 · p. 2

    Current placement weighs storage capacity but not compute availability; making placement fully resource-aware remains future work.

    Source: §9 · p. 17

Abstract

from arXiv · show

Function-as-a-Service (FaaS) is a widely adopted paradigm to simplify application deployment across the edge-to-cloud continuum. However, its stateless nature forces functions to retrieve their state from external, typically cloud-centric, data stores, reintroducing the very latency that edge computing aims to eliminate. This issue is further exacerbated by location-agnostic schedulers and rigid, one-size-fits-all consistency models that fail to capture the diverse requirements of edge applications. In this paper, we propose Ermes, a distributed platform that natively integrates state management into the FaaS paradigm, enabling the joint distribution of computational workloads and application state across the edge-to-cloud continuum. Ermes organizes application state into logical units, termed collections, and employs a distributed coordination algorithm that jointly maps collections and functions onto the available nodes seeking to minimize the latency perceived by the clients. In addition, it supports fine-grained replication and per-collection consistency levels, ranging from sequential to eventual consistency, leaving developers the choice of how to resolve the trade-off between consistency and performance. The experimental evaluation shows that Ermes quickly turns remote state accesses into local ones and sustains low latency as the workload grows, and as clients move across the edge.

1. Introduction

Stateless FaaS can leave edge functions fetching application state from remote stores, while existing placement and consistency approaches do not resolve the locality–consistency trade-off. Ermes jointly places functions and state across the edge-to-cloud continuum and lets developers set consistency per collection.

1. Introduction

  • Stateless FaaS leaves application state in external, often cloud-centralized storage, so edge functions may reintroduce remote-access latency.Locality-aware function placement alone can still leave a function making a remote round-trip for state.Source: §1 · p. 1
  • Stateful edge applications face a trade-off: replication can reduce access latency, but stronger consistency requires coordination that can offset that benefit.Weaker consistency reduces coordination overhead but permits temporary divergence across replicas.Source: §1 · p. 2
  • Ermes jointly maps functions and state across available nodes to minimize client-perceived latency, distributing collections near users and steering execution toward their state.Its distributed coordination algorithm builds on a heuristic studied in companion work [15].Source: §1 · p. 2
  • Ermes supports fine-grained collection replication and per-collection consistency, from sequential to eventual, letting developers choose between stronger guarantees and lower access latency.The choice is framed as prioritizing strict consistency or lower access latency for performance-critical tasks.Source: §1 · p. 2
  • The paper evaluates the fully implemented platform on real infrastructure against a centralized baseline and reports benefits in request latency and throughput.This evaluation extends companion work [15], which studied the placement and scheduling heuristic in simulation.Source: §1 · p. 2

2. Related Work

Prior systems variously provide lightweight execution, state management, replication, or distributed scheduling, but the supplied related-work discussion identifies no platform combining the full set of Ermes features. Ermes brings these capabilities together in a full platform.

2. Related Work

  • Lightweight runtimes focus on single-node execution; most are stateless, and even stateful Faasm lacks coordination for scheduling and state placement across geographically distributed nodes.WASP is modular but likewise runs on a single node without coordinating execution across the hierarchy.Source: §2 · pp. 2–3
  • Existing platforms divide capabilities: some offer replication or state abstraction but rely on centralized or limited scheduling, while others decentralize scheduling yet omit replication or state abstraction.For example, StructMesh lacks replication, while FaDO lacks state abstraction; Enoki has trivial scheduling that does not account for resource availability.Source: §2 · pp. 3–4
  • No existing platform combines a decentralized stateful model, state abstraction, distributed locality-aware scheduling, and native replication with configurable per-collection consistency.The related-work comparison identifies this combination as the gap Ermes addresses.Source: §2 · p. 4
  • Ermes is a full platform built on WASP that combines multi-node coordination with the decentralized heuristic for joint computation and state placement from companion work [15].The related-work discussion positions this as a combination not offered by existing systems.Source: §2 · p. 4

3. Programming Model

Ermes makes persistent application state part of its FaaS programming model through collections that functions access on clients’ behalf. Collection policies govern access and consistency, while function metadata lets the platform resolve which collections an invocation uses.

3. Programming Model

  • Collections are persistent sets of key-value records that functions create, read, and write; clients interact with application state only through functions.Collection access policies distinguish private, public, and shared access.Source: §3 · pp. 4–5
  • At deployment, function metadata declares accessed collections by properties rather than identity, and invocation arguments let the platform match those declarations to collection metadata.This allows the same function to operate on different collections depending on the invoking client and supplied arguments.Source: §3 · p. 5
  • Sequential consistency provides ordered operations and read-your-writes, whereas eventual consistency permits transiently different reads and concurrent updates that may not all be preserved.Developers fix a collection’s consistency policy when creating it.Source: §3 · p. 5
  • An invocation may access at most one sequentially consistent collection, avoiding cross-collection distributed commit, while it may access any number of eventually consistent collections.The restriction supports total ordering without a consensus protocol for an invocation spanning multiple strongly consistent collections.Source: §3 · p. 5

4. System Overview

Ermes aims to reduce client-observed latency by jointly deciding where functions execute and where their state resides. Its distributed runtime operates across a hierarchical edge-to-cloud infrastructure, with cooperating function- and state-management functions.

4. System Overview

  • Ermes jointly places functions and the state they access near clients because latency includes both code execution and state access.It relies on a heuristic that approximates the optimum and adapts to dynamic scenarios [15].Source: §4 · p. 6
  • The infrastructure is modeled as a rooted hierarchy: capacity grows from constrained edge leaves toward the cloud, and clients invoke through the nearest edge tier.The paper uses a three-tier edge, fog, and cloud instance of this model.Source: §4 · p. 6
  • Each node keeps partial reachability information indicating the direction to collection replicas and, for sequentially consistent collections, to their leader; the cloud retains a fallback replica of every collection.Nodes learn their views through interaction with neighbors rather than holding a global system view.Source: §4 · p. 6
  • Distributed function management schedules and executes invocations, while state management accesses, monitors, places, and replicates collections across the hierarchy.Scheduling may serve an invocation locally or forward it to another node; monitoring demand informs placement as clients’ needs shift.Source: §4 · p. 6

5. Function Management

Function management routes each invocation toward a node holding its required state, then runs it locally in an isolated, portable environment. Scheduling uses local reachability information and the collections’ consistency policies to choose whether to execute or forward.

5. Function Management

  • Scheduling selects a node that already holds the needed data when possible, keeping function execution beside state to reduce client-perceived latency.The scheduling decision is on every invocation’s critical path and consults only neighboring nodes.Source: §5 · p. 7
  • Each node uses its partial reachability view to route an invocation one hop at a time, forwarding unknown collections toward the parent and terminating by the root.Nodes either execute locally or forward; an invocation climbs at most to the root.Source: §5 · p. 7
  • Sequentially consistent collections constrain execution: writes route to their leader, while reads go to the nearest known replica; with only eventual collections, scheduling favors local co-location or the neighbor covering the most required collections.Missing eventually consistent collections are fetched from the nearest known replica while the function runs.Source: §5 · p. 7
  • Every invocation runs in an isolated environment that supports concurrent execution and lets the same function run unmodified across constrained edge devices and cloud servers.Ermes realizes this environment on WASP.Source: §5 · p. 7

6. State Management

State management keeps collections near the clients that use them through demand-aware placement and replication, while coordinating access and updates according to each collection’s consistency policy. Its placement and replication mechanisms account for changing demand, limited storage, and collections moving while updates are in flight.

6. State Management

  • State management combines access, monitoring, placement, and replication: access serves reads and writes, monitoring measures demand, placement relocates or replicates collections, and replication keeps copies consistent.Access is on the invocation critical path; the other three functions run in the background.Source: §6 · pp. 7–8
  • Functions use get and put operations without needing to know where a collection resides; a node serves locally when it holds a replica and otherwise forwards the operation to one.Monitoring reports record access type and accumulated latency, then travel toward a node holding the collection.Source: §6 · p. 8
  • Each node periodically cycles through idle, gossip, and decision phases, exchanging neighbor capacity reports before independently deciding whether to keep, migrate, or replicate each collection.The phases form an epoch; migrations proceed asynchronously after the decision phase.Source: §6 · p. 8
  • With eventual consistency, requests drive hop-by-hop replication toward accessing edge nodes, subject to neighbor storage capacity; hierarchical LRU eviction moves replicas upward when space is needed.Eviction is reactive when an incoming collection will not fit and proactive when occupancy exceeds a configured safe level.Source: §6 · pp. 8–9
  • With sequential consistency, leader placement balances write locality against scarce edge storage, while followers are placed independently to serve read demand.Demand pulls replicas toward clients; storage pressure pushes them upward. The leader moves toward write-heavy regions when the pull outweighs sibling demand, external-write tension, and storage costs; follower provisioning compares child read demand with storage pressure.Source: §6 · pp. 8–9
  • Writes are batched per collection and committed atomically after function execution; sequential writes commit before the response, whereas eventual writes commit asynchronously after it.A failed execution leaves no partial writes behind.Source: §6 · pp. 9–10
  • Sequential replicas apply ordered, numbered updates monotonically and delay reads until they reach the client’s previously observed sequence number; eventual replicas accept reads and writes without critical-path coordination, resolving concurrent record updates by last-writer-wins.The sequential read check preserves read-your-writes across invocations served by different replicas.Source: §6 · p. 10
  • Transfer safeguards preserve updates in flight, and leader handoff maintains at most one leader while briefly rejecting requests that reach the collection during the transfer.Follower provisioning does not block ongoing writes.Source: §6 · pp. 10–11

7. Implementation

Ermes is implemented in Go, with each node running a runtime for receiving direct and forwarded invocations. Function execution uses portable WASM workers and caching, while state management is built around Redis and HTTP-based coordination.

7. Implementation

  • Ermes is implemented in Go to support its asynchronous, message-driven platform.Each node runs a runtime that exposes one HTTP endpoint for direct and forwarded invocations.Source: §7 · p. 11, §7.1 · p. 11

7.1. Function Management

  • WASM sandboxes isolate invocations while allowing the same function binary to run across the continuum; a two-tier cache makes warm calls pay for compilation and hot calls bypass retrieval and compilation.Pre-warmed workers bound concurrent invocations; compiled modules are shared, while each invocation receives fresh linear memory.Source: §7.1 · p. 11, Figure 9 · p. 11

7.2. State Management

  • State management uses Redis for collections and protocol metadata, with HTTP for access forwarding, placement transfers, and ordered update propagation.Placement uses age-weighted demand buffers and concurrent per-collection decisions; Redis Lua scripts provide atomic operations such as batch commits and last-writer-wins updates.Source: §7.2 · pp. 11–12

8. Evaluation

The evaluation measures end-to-end client latency as Ermes places state near computation, testing state-management latency, scalability, and adaptation to static and mobile clients. Across these experiments, Ermes retains a latency advantage over cloud-based baselines, with consistency policy, workload, and client movement shaping the results.

8.1. Experimental Setup

  • The testbed emulates a three-tier edge-to-cloud hierarchy with injected 5–20 ms link RTTs; reported latencies are end-to-end measurements from the running platform.Clients communicate through edge nodes, with negligible latency to them; Ermes state is held in memory in Redis.Source: §8 · pp. 12–13, §8.1 · p. 13

8.2. State Management and Perceived Latency (RQ1)

  • Readers’ latency falls from ≈20–60 ms to ≈1 ms after local followers are provisioned, while the writer settles around ≈1 ms without disrupted writes.Figure 10 shows five clients: one writer and four readers; nearer readers converge at epoch 2 and distant readers at epoch 4.Source: Figure 10 · p. 13, §8.2 · pp. 13–14
  • Under sequential consistency, opposite-edge writers settle around ≈18 ms; under eventual consistency, latency is ≈1 ms from the first epoch as requests are served locally.The sequential result reflects single-leader serialization; eventual synchronization proceeds asynchronously without blocking user requests.Source: Figure 11 · p. 13, §8.2 · p. 14

8.3. Scalability under a Growing Workload (RQ2 and RQ4)

  • Across concurrency and state cardinality, Ermes latency remains below CD, whose latency is ≈32 ms; at its worst, Ermes is ≈10 ms.Ermes eventual consistency rises only from ≈1.5 ms with one client to ≈1.75 ms with 1024; high concurrency with 1000 collections widens the IQR under memory pressure.Source: Figure 12 · p. 14, §8.3 · p. 15
  • With 1–10 reads per invocation, CD latency rises from ≈32 ms to ≈301 ms, while Ermes stays at ≈1.4–3 ms and CO at ≈31–42 ms.The comparison fixes Nusers = 64 and Ncol = 100; CD incurs a cloud round-trip per read, whereas Ermes serves reads locally at the edge.Source: Figure 13 · p. 15, §8.3 · p. 15

8.4. Adaptation to Static and Mobile Clients (RQ3 and RQ4)

  • For static clients, Ermes converges to ≈8 ms under sequential and ≈3 ms under eventual consistency; for mobile clients, it recovers from move-related spikes while staying below the ≈25–30 ms baselines between moves.Figure 15 uses clients changing edge access points every five epochs; eventual-consistency spikes are ≈10 ms and sequential-consistency spikes reach ≈20 ms.Source: Figure 14 · p. 16, Figure 15 · p. 16, §8.4 · p. 16

8.5. Discussion

  • Across the evaluated edge-to-cloud setting, Ermes turns remote accesses local, maintains low latency as workloads grow, adapts to mobile clients, and outperforms both cloud-based baselines.The advantage is greatest for read-intensive, eventually consistent, and mobile workloads.Source: §8.5 · p. 16

9. Conclusion

Ermes integrates state management into FaaS and jointly distributes computation and application state across the edge-to-cloud continuum. An emulated geo-distributed evaluation reports low client-perceived latency across workloads and consistency requirements, while several extensions remain future work.

9. Conclusion

  • Ermes brings state close to computation and sustains low client-perceived latency as demand shifts across workloads and consistency requirements.The evaluation used an emulated geo-distributed deployment and reports performance against realistic deployment solutions.Source: §9 · pp. 16–17
  • Current placement weighs node storage capacity; extending it to account for compute resources and adapting collection guarantees to access patterns remain planned work.The authors also plan evaluation on larger-scale physical infrastructures.Source: §9 · p. 17
  • Sequential consistency still needs leader re-election to survive leader failure, a fault-tolerance mechanism left to future work.The authors contrast this with recovery in most scenarios for eventually consistent collections, which use multi-leader design and retain a cloud replica.Source: §9 · p. 17

CRediT authorship contribution statement

The statement lists each author's contributions to the paper, including conceptualization, methodology, software, validation, visualization, writing, supervision, and resources.

CRediT authorship contribution statement

Funding

The authors report that the research received no specific grant from the listed funding sectors.

Funding

  • The research received no specific grant from funding agencies in the public, commercial, or not-for-profit sectors.Source: Funding · p. 17

Related papers

Loading 2609.18924v1…