Pith. sign in

REVIEW 4 major objections 7 minor 46 references

GoldFish: Serverless Actors with Short-Term Memory State for the Edge-Cloud Continuum

T0 review · 4 major / 7 minor · reviewed 2026-08-11 · deepseek-v4-flash

Pith's one-line read GoldFish claims that adding a short-term memory phase to the serverless lifecycle, and letting actors govern future messages, cuts data-exchange latency by up to 92 percent and raises throughput up to 10x against OpenFaaS and Spin.

desk verdict A real warm-pool actor system with a working prototype, but the scale-to-zero claim is unsupported and the evaluation lacks stateful baselines. read the letter →

arxiv 2412.02867 v1 pith:NA5WLPMQ submitted 2024-12-03 cs.DC

classification cs.DC
keywords serverlesscomputingWebAssemblyactormodelactorslifecycleinvocationedge-cloudcontinuumshort-termstate
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that the serverless function model, not the underlying hardware, is what forces workflow data through remote storage, and that this cost can be removed by treating functions as short-term actors. It introduces two models: a lifecycle model with a SUSPENDED phase in which an actor keeps its state alive between messages, and an invocation model in which a busy actor can queue or reject future messages. These are implemented in GoldFish, a WebAssembly-based serverless actor platform. Against OpenFaaS and Spin, GoldFish reports data-exchange latency reductions of up to 92 percent and throughput increases of up to 10x. The intended payoff is that ephemeral workflow data no longer needs a round-trip to an external key-value store or object storage.

What carries the argument

The load-bearing mechanism is the GoldFish actor, composed of an addressable channel, a Wasm Host Interface sidecar that owns the WebAssembly VM, and the user Handler compiled to Wasm. The lifecycle phases CREATED, SUSPENDED, RUNNING, COMPLETED, ERROR, and TERMINATION let the same VM persist between messages for a user-defined period, while the invocation middleware's waiting, ready, and done queues decide whether a message goes to a suspended actor, waits for a busy actor, or is routed elsewhere. The Wasm Host Interface blocks new messages while one is being processed, giving actors single-message-at-a-time semantics without data races.

What would settle it

Run an actor that increments an in-memory counter on each message, let it enter SUSPENDED, wait past the platform's idle scale-to-zero threshold, send the next message, and check whether the counter resets; if it resets, short-term state does not survive scale-to-zero as claimed.

Watch

Extended reading notes

Core claim

The central claim is that short-term actor state can live inside the WebAssembly VM across message executions, so a chain of related events is processed by one actor instance instead of a fresh instance per request. GoldFish's lifecycle model adds SUSPENDED as a first-class phase between RUNNING and COMPLETED, and its invocation model lets the actor tell the middleware buffer whether the next message should be delivered, kept waiting, or forwarded to another actor. This removes the dominant latency cost the paper attributes to remote state services while preserving direct addressability and single-message-at-a-time processing. The reported measurements support the claim with up to 92 percent lower message-exchange latency and up to 10x higher throughput than the two baselines in sequential and fan-out experiments.

Load-bearing premise

The design assumes that an actor's state can remain in the WebAssembly VM while the actor sits in SUSPENDED and that this still qualifies as serverless scale-to-zero; if evicting the idle VM destroys that state, the latency and throughput advantage over remote-state systems collapses.

Editorial extensions

If this is right

  • Actor state survives between executions for a user-defined window, so a sequence of connected workflow events can be handled by one instance rather than re-instantiating an actor per message.
  • Ephemeral workflow data can pass directly between actors through the middleware buffer, avoiding remote key-value store and object storage round-trips for that data.
  • A busy actor can reject or defer the next message, and the buffer's time and size limits eventually create a new actor, so workflows get built-in backpressure without message loss.
  • WebAssembly sandboxing keeps each actor isolated while remaining lightweight enough for resource-constrained edge nodes, and container-based packaging preserves interoperability with existing serverless platforms.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The compatibility with scale-to-zero is the point most worth probing: if an idle actor is evicted during SUSPENDED, its in-memory state vanishes, so a production deployment would need to checkpoint state to stable storage before eviction, re-introducing some remote-state cost.
  • The reported gains combine the lifecycle model, the message middleware, and WebAssembly, so an ablation that isolates each component would sharpen the causal claim behind the 92 percent and 10x figures.
  • A natural extension is to snapshot SUSPENDED state to local disk just before eviction, preserving the short-term state property while restoring the strong scale-to-zero guarantee.
  • The design could be tested against stateful serverless systems that tier local and remote state, to see whether purely in-memory short-term state remains competitive when workflows grow beyond a single edge node.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 7 minor

Summary. The paper proposes GoldFish, a WebAssembly-based serverless actor platform whose two contributions are a lifecycle model (LCM) that keeps an actor alive in a SUSPENDED phase with in-memory state between invocations, and an invocation model (SIM) with a middleware buffer that lets busy actors queue or reject messages. The authors claim these models reduce reliance on remote state services and report experiments against OpenFaaS and Spin in chained-function and workflow benchmarks, with latency reductions up to 92% and throughput improvements up to 10x. The paper includes an architecture description, prototype implementation details, and an evaluation on a single ARM64 machine with 4 cores and 8 GB of RAM.

Significance. If the claims are supported, the contribution is a lightweight, open-source stateful actor runtime that preserves ephemeral state inside a Wasm VM and processes bursts of related messages with lower overhead than general-purpose FaaS. The open-source prototype and concrete workload suite are genuine strengths, as is the use of Wasm for lightweight isolation. However, the significance of the results as stated depends on two unresolved points: whether the system truly preserves serverless scale-to-zero semantics while keeping state in memory, and whether the performance advantage generalizes beyond the two chosen baselines and continuous workloads. There are no formal proofs or mathematical derivations; the contributions are architectural and empirical, so the evaluation quality is load-bearing for the central claims.

major comments (4)
  1. [2.1, RC-1, 3.1.2] The scale-to-zero claim is unsupported and possibly inconsistent with the SUSPENDED phase. Section 2.1 says GoldFish 'still scales down to zero when not in use,' and the RC-1 discussion says actors 'can scale to zero in the absence of invocations while still providing the advantages of stateful functions.' However, Section 3.1.2 defines SUSPENDED as a phase in which the actor is 'not currently processing any tasks but is ready and waiting,' with the duration determined by the user, after which the actor moves to TERMINATION and GoldFish releases resources. Since the short-term state is kept in the Wasm VM's memory, a true scale-to-zero event that destroys the VM would lose that state. The design therefore provides state continuity only within a user-defined idle timeout, and after a longer idle period it reverts to the cold-start or remote-state behavior the paper claims to avoid. The evaluation never exercises this case, because all workloads send messages continuously. Please either characterize GoldFish as a warm-pool actor system with a bounded idle-retention window, or provide a concrete mechanism such as checkpointing that preserves state across scale-to-zero, and add experiments that measure behavior across idle gaps.
  2. [6.1, 6.2, 6.3] The performance claims are not supported by the statistical and methodological detail provided. Section 6.1 states that experiments were executed seven times and averaged, but no standard deviation, confidence interval, or significance test is reported, and Figures 7-11 show no error bars. In addition, the workloads are continuous sequences of messages, so they never measure cold starts or scale-to-zero transitions, and all experiments run on a single local machine rather than a distributed edge-cloud deployment. Because the headline claims are 'up to 92% latency reduction' and 'up to 10x throughput,' the evaluation needs per-point variance, an indication of warm and cold start conditions, and ideally a comparison under idle-gap or scale-to-zero scenarios.
  3. [6.2, 6.3, 7] The chosen baselines do not support the paper's positioning against stateful serverless actor systems. OpenFaaS and Spin are general-purpose FaaS platforms, so the measured gains may largely reflect the absence of an HTTP gateway hop and the use of a warm actor pool, rather than the novel LCM and SIM mechanisms. Section 7 argues that existing actor approaches such as microActor, Durable Functions, Faasm, and Cloudburst rely on external services and incur overhead, but none of these is evaluated. Adding at least one stateful serverless baseline or a remote-state actor implementation is necessary to substantiate the claim that GoldFish's short-term in-actor state, rather than the absence of HTTP ingress, is what produces the improvements.
  4. [3.2, 4.2] The paper has not specified the mechanism by which an actor influences message processing. The text states that GoldFish actors 'decide the processing of future messages based on the actor input' and that an actor can accept, queue, or reject a message, but Figure 6 and the surrounding flow only describe the middleware querying the actor lifecycle phase and buffer availability. There is no description of an API, host function, or protocol through which user-level code signals acceptance or rejection of a particular message before dispatch. As written, SIM reduces to a busy-actor queue with timeout-based escalation. Please specify the actor-facing control interface and demonstrate with a small example how a user function rejects or accepts a message.
minor comments (7)
  1. [3.1] There are several typos: 'Golfish' in the Section 3.1 heading, 'real-wold' in Section 6, 'Sping' in Section 6.3, and 'comercial' in Section 7.
  2. [2.2, RC-3] The citation '[28? -30]' is malformed; it should likely be '[28-30]' or the intended references should be listed explicitly.
  3. [6.1] Reporting only the mean of seven runs without any spread is insufficient; please report medians and percentiles or standard deviations, and add error bars to Figures 7-11.
  4. [6] The benchmark setup should state the concurrency level of the load generator, the client configuration, and how requests per second is measured; otherwise the throughput comparison is hard to interpret.
  5. [3.1.1] The sentence 'Channel ... enables actors to carry their previous state to the next one' is misleading, since state is retained in the Wasm VM or actor rather than in the channel; rephrase to describe the actor as stateful.
  6. [5] The open-source repository is cited without a commit hash, release tag, or dependency versions; adding a reproducibility appendix or a tagged release would help.
  7. [7] The claim that GoldFish 'implements the actor [as] a standard container which can be used by most open source and commercial Serverless platforms' is not demonstrated; either provide a deployment test on a second platform or soften the claim.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: benchmark-based evaluation; only a non-load-bearing self-citation.

full rationale

GoldFish makes no equation-level predictions and fits no parameters to the evaluation data. The central claims—short-term state retention in a WebAssembly VM and message-queue-based invocation—are implemented mechanisms, and the reported latency reduction and throughput gains are measured against external OpenFaaS and Spin baselines rather than derived from the paper's own definitions. The only self-citation appears where [28], the authors' Cwasi work, is cited to support the general importance of low-latency edge communication and Wasm cold starts; the cold-start statement is also supported by independent references [29,30], and Cwasi is not the load-bearing premise for LCM, SIM, or the evaluation numbers. The SUSPENDED/scale-to-zero tension noted by a reader is a consistency gap—the paper asserts scale-to-zero while the lifecycle keeps SUSPENDED actors alive until a user-defined timeout—but it is not a circular reduction, because the performance claims do not formally depend on that assertion. Overall, the derivation is self-contained against external benchmarks; no circularity is exhibited.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

No curve fitting or parameterized derivation is present. The user-defined suspend timeout and buffer limits are configuration knobs rather than fitted constants. The axiomatic assumptions are typical for a systems paper: the motivation relies on external-state latency, the isolation mechanism is Wasm, the state-retention model is assumed, and the single-machine evaluation is treated as representative of the edge-cloud continuum.

free parameters (2)
  • SUSPENDED phase timeout = user-defined
    Determines how long an actor keeps short-term state before termination; directly affects reuse and thus latency and throughput.
  • Buffer queue time and message size limits = user-defined
    Limits how long a message waits before a new actor is created; shapes queueing behavior and latency.
assumptions (4)
  • domain assumption External state services dominate serverless function latency.
    Motivates the design; based on cited work [25,26], not re-verified in this paper.
  • domain assumption WebAssembly sandboxing provides adequate isolation for multi-tenant serverless actors at the edge.
    The platform relies on Wasm as the security boundary (Section 3.3, RC-3).
  • domain assumption Actor state in VM memory is safe and consistent across executions during the SUSPENDED phase.
    Core design premise in Section 3.1; not proven and conflicts with scale-to-zero if memory is reclaimed.
  • domain assumption Single-machine benchmark results generalize to the distributed Edge-Cloud Continuum.
    All experiments run on one 4-core node; the paper generalizes to multi-node deployment without a distributed evaluation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of GoldFish: Serverless Actors with Short-Term Memory State for the Edge-Cloud Continuum." pith.science (2026). https://pith.science/paper/NA5WLPMQ

@misc{pith2026241202867,
  author       = {Pith},
  title        = {Pith review of: GoldFish: Serverless Actors with Short-Term Memory State for the Edge-Cloud Continuum},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/NA5WLPMQ}},
  note         = {Machine review of arXiv:2412.02867}
}
read the original abstract

Serverless Computing is a computing paradigm that provides efficient infrastructure management and elastic scalability. Serverless functions scale up or down based on demand, which means that functions are not directly addressable and rely on platform-managed invocation. Serverless stateless nature requires functions to leverage external services, such as object storage and KVS, to exchange data. Serverless actors have emerged as a solution to these issues. However, the state-of-the-art serverless lifecycle and event-trigger invocation force actors to leverage remote services to manage their state and exchange data, which impacts the performance and incurs additional costs and dependency on third-party services. To address these issues, in this paper, we introduce a novel serverless lifecycle model that allows short-term stateful actors, enabling actors to maintain their state between executions. Additionally, we propose a novel serverless Invocation Model that enables serverless actors to influence the processing of future messages. We present GoldFish, a lightweight WebAssembly short-term stateful serverless actor platform that provides a novel serverless actor lifecycle and invocation model. GoldFish leverages WebAssembly to provide the actors with lightweight sandbox isolation, making them suitable for the Edge-Cloud Continuum, where computational resources are limited. Experimental results show that GoldFish optimizes the data exchange latency by up to 92% and increases the throughput by up to 10x compared to OpenFaaS and Spin.

Figures

Figures reproduced from arXiv: 2412.02867 by the authors.

Figure 1
Figure 1. Simplified Serverless Workflow for Disease Control [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. GoldFish Serverless Lifecycle Model memory. Thus, LCM optimizes resource usage, reduces latency, and improves performance and scalability across the dynamic envi￾ronments of the Edge-Cloud Continuum by ensuring that existing actors are efficiently utilized and consequently minimizing the over￾head associated with creating new actors. 3.1.1 GoldFish Actor [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. shows how SIM introduces a new way of triggering server￾less actors in response to events such as incoming messages. The GoldFish SIM model ensures that new actors are created only when necessary while existing actors are reused by introducing a in￾vocation Middleware with three queues: waiting, ready and done. GoldFish SIM model enables GoldFish Buffer to identify the avail￾ability and state of actors via the actor… view at source ↗
Figures from the paper (6 more)
Figure 5
Figure 5. Figure 5: GoldFish Serverless Lifecycle Management [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 7
Figure 7. Figure 7: Message Exchange Latency In [PITH_FULL_IMAGE:figures/full_fig_p006_7.png]
Figure 8
Figure 8. Figure 8: Sequential Execution: Chained Functions 1 10 20 30 40 50 0 2 4 6 8 10 12 Input Size (MB) Seconds GoldFish OpenFaaS Spin (a) Latency 1 10 20 30 40 50 0.07 0.5 3.9 23 Input Size (MB) Request per second (b) Throughput [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]
Figure 9
Figure 9. Figure 9: Sequential Execution: Serverless Workflow [PITH_FULL_IMAGE:figures/full_fig_p007_9.png]
Figure 10
Figure 10. Figure 10: a presents the latency from the parallel execution experi￾ments, where the 𝑥 axis represents the number of parallel execu￾tions and the 𝑦 axis reflects latency in milliseconds. Fig. 10a that GoldFish maintains a relatively stable latency ranging from 6.9 milliseconds …
Figure 11
Figure 11. Figure 11: a showcases the latency from parallel execution for Server￾less Workflows, where the 𝑥 axis indicates the number of parallel 20 40 60 80 100 5.5 7.5 20 50 Parallel Executions Milliseconds GoldFish OpenFaaS Spin (a) Latency 20 40 60 80 100 17 40 80 120 170 Parallel Exe…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

46 extracted references · 37 canonical work pages

  1. [1]

    Gonzalez, Raluca Ada Popa, Ion Stoica, and David A

    Eric Jonas, Johann Schleier-Smith, Vikram Sreekanti, Chia-Che Tsai, Anurag Khandelwal, Qifan Pu, Vaishaal Shankar, Joao Carreira, Karl Krauth, Neeraja Yad- wadkar, Joseph E. Gonzalez, Raluca Ada Popa, Ion Stoica, and David A. Patterson. Cloud programming simplified: A berkeley view on serverless computing, 2019

  2. [2]

    Serverless edge comput- ing—where we are and what lies ahead

    Philipp Raith, Stefan Nastic, and Schahram Dustdar. Serverless edge comput- ing—where we are and what lies ahead. IEEE Internet Computing, 27(3):50–64,

  3. [3]

    A serverless computing fabric for edge & cloud

    Stefan Nastic, Philipp Raith, Alireza Furutanpey, Thomas Pusztai, and Schahram Dustdar. A serverless computing fabric for edge & cloud. In 2022 IEEE 4th International Conference on Cognitive Machine Intelligence (CogMI) , pages 1–12,

  4. [4]

    SONIC: Application-aware data passing for chained server- less applications

    Ashraf Mahgoub, Karthick Shankar, Subrata Mitra, Ana Klimovic, Somali Chaterji, and Saurabh Bagchi. SONIC: Application-aware data passing for chained server- less applications. In 2021 USENIX Annual Technical Conference (USENIX ATC 21) , pages 285–301. USENIX Association, 2021. ISBN 978-1-939133-23-6

  5. [5]

    Towards a serverless platform for edge computing

    Luciano Baresi and Danilo Filgueira Mendonça. Towards a serverless platform for edge computing. In 2019 IEEE International Conference on Fog Computing (ICFC), pages 1–10, 2019. doi: 10.1109/ICFC.2019.00008

  6. [6]

    Rise of the planet of serverless computing: A systematic review

    Jinfeng Wen, Zhenpeng Chen, Xin Jin, and Xuanzhe Liu. Rise of the planet of serverless computing: A systematic review. ACM Trans. Softw. Eng. Methodol., 32 (5), 2023. ISSN 1049-331X. doi: 10.1145/3579643. URL https://doi.org/10.1145/ 3579643

  7. [7]

    Serverless Computing: One Step Forward, Two Steps Back

    Joseph M Hellerstein, Jose Faleiro, Joseph E Gonzalez, Johann Schleier-Smith, Vikram Sreekanti, Alexey Tumanov, and Chenggang Wu. Serverless computing: One step forward, two steps back. arXiv preprint arXiv:1812.03651, 2018

  8. [8]

    Akka actor systems

    Akka. Akka actor systems. URL https://doc.akka.io/docs/akka/current/general/ actor-systems.html

Show all 46 references
  1. [9]

    Actor- Based Designs for Distributed Self-organisation Programming , pages 37–58

    Roberto Casadei, Ferruccio Damiani, Gianluca Torta, and Mirko Viroli. Actor- Based Designs for Distributed Self-organisation Programming , pages 37–58. Springer Nature Switzerland, Cham, 2024. ISBN 978-3-031-51060-1. doi: 10.1007/978-3-031-51060-1_2. URL https://doi.org/10.100...

  2. [10]

    Meiklejohn

    Sebastian Burckhardt, Chris Gillum, David Justo, Konstantinos Kallas, Connor McMahon, and Christopher S. Meiklejohn. Durable functions: semantics for stateful serverless. Proc. ACM Program. Lang., 5(OOPSLA), 2021. doi: 10.1145/ 3485510. URL https://doi.org/10.1145/3485510

  3. [11]

    On the faas track: Building stateful distributed applications with serverless architectures

    Daniel Barcelona-Pons, Marc Sánchez-Artigas, Gerard París, Pierre Sutra, and Pedro García-López. On the faas track: Building stateful distributed applications with serverless architectures. In Proceedings of the 20th International Middleware Conference, Middleware ’19, page 41...

  4. [12]

    Jordan, and Ion Stoica

    Philipp Moritz, Robert Nishihara, Stephanie Wang, Alexey Tumanov, Richard Liaw, Eric Liang, Melih Elibol, Zongheng Yang, William Paul, Michael I. Jordan, and Ion Stoica. Ray: A distributed framework for emerging AI applications. In 13th USENIX Symposium on Operating Systems De...

  5. [13]

    µactor: Stateful serverless at the edge

    Raphael Hetzel, Teemu Kärkkäinen, and Jörg Ott. µactor: Stateful serverless at the edge. In Proceedings of the 1st Workshop on Serverless Mobile Networking for 6G Communications , MobileServerless’21, page 1–6, New York, NY, USA,

  6. [14]

    Faasm: Lightweight isolation for efficient stateful serverless computing

    Simon Shillaker and Peter Pietzuch. Faasm: Lightweight isolation for efficient stateful serverless computing. In 2020 USENIX Annual Technical Conference (USENIX ATC 20), pages 419–433. USENIX Association, 2020. ISBN 978-1-939133- 14-4. URL https://www.usenix.org/conference/atc...

  7. [15]

    Actors: a model of concurrent computation in distributed systems

    Gul Agha. Actors: a model of concurrent computation in distributed systems . MIT Press, Cambridge, MA, USA, 1986. ISBN 0262010925

  8. [16]

    On the integration of the actor model in mainstream technologies: the scala perspective

    Philipp Haller. On the integration of the actor model in mainstream technologies: the scala perspective. In Proceedings of the 2nd Edition on Programming Systems, Languages and Applications Based on Actors, Agents, and Decentralized Control Abstractions, AGERE! 2012, page 1–6,...

  9. [17]

    Studying the feasibility of serverless actors

    Daniel Barcelona Pons, Alvaro Ruiz Ollobarren, David Arroyo Pinto, and Pe- dro Garcia Lopez. Studying the feasibility of serverless actors. In Proceedings of the European Symposium on Serverless Computing and Applications, ESSCA@UCC 2018, Zurich, Switzerland, December 21, 2018...

  10. [18]

    Springer Nature Switzer- land, Cham, 2024

    Jonas Spenger, Paris Carbone, and Philipp Haller.A Survey of Actor-Like Program- ming Models for Serverless Computing , pages 123–146. Springer Nature Switzer- land, Cham, 2024. ISBN 978-3-031-51060-1. doi: 10.1007/978-3-031-51060-1_5. URL https://doi.org/10.1007/978-3-031-51060-1_5

  11. [19]

    Tracking the state of aws lambda functions, 2019

    Chris Munns. Tracking the state of aws lambda functions, 2019. URL https: //aws.amazon.com/blogs/compute/tracking-the-state-of-lambda-functions

  12. [20]

    Abad, Alexandru Iosup, Ian Foster, Prashant Shenoy, Omer Rana, and Andrew A

    Samuel Kounev, Nikolas Herbst, Cristina L. Abad, Alexandru Iosup, Ian Foster, Prashant Shenoy, Omer Rana, and Andrew A. Chien. Serverless computing: What it is, and what it is not? Commun. ACM, 66(9):80–92, 2023. ISSN 0001-0782. doi: 10.1145/3587249. URL https://doi.org/10.114...

  13. [21]

    Larus, Ravi Pandya, and Jorgen Thelin

    Sergey Bykov, Alan Geller, Gabriel Kliot, James R. Larus, Ravi Pandya, and Jorgen Thelin. Orleans: cloud computing for everyone. In Proceedings of the 2nd ACM Symposium on Cloud Computing, SOCC ’11, New York, NY, USA, 2011. Association for Computing Machinery. ISBN 97814503097...

  14. [22]

    A programming model for context-aware applications in large-scale pervasive systems

    Sanjin Sehic, Fei Li, Stefan Nastic, and Schahram Dustdar. A programming model for context-aware applications in large-scale pervasive systems. In Proceedings of the IEEE 8th International Conference on Wireless and Mobile Computing, Network- ing and Communications (WiMob 2012...

  15. [23]

    Boki: Stateful serverless computing with shared logs

    Zhipeng Jia and Emmett Witchel. Boki: Stateful serverless computing with shared logs. In Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles, SOSP ’21, page 691–707, New York, NY, USA, 2021. Association for Computing Machinery. ISBN 9781450387095. doi:...

  16. [24]

    Process-as-a-service: Elastic and stateful server- less with cloud processes

    Marcin Copik, Alexandru Calotoiu, Rodrigo Bruno, Gyorgy Rethy, Roman Böhringer, and Torsten Hoefler. Process-as-a-service: Elastic and stateful server- less with cloud processes. Technical report, Tech. rep.(Jan. 2022), 2022

  17. [25]

    Faastlane: Accelerating Function-as-a-Service workflows

    Swaroop Kotni, Ajay Nayak, Vinod Ganapathy, and Arkaprava Basu. Faastlane: Accelerating Function-as-a-Service workflows. In 2021 USENIX Annual Technical Conference (USENIX ATC 21), pages 805–820. USENIX Association, 2021. ISBN 978-1-939133-23-6

  18. [26]

    SAND: Towards High-Performance serverless computing

    Istemi Ekin Akkus, Ruichuan Chen, Ivica Rimac, Manuel Stein, Klaus Satzke, Andre Beck, Paarijaat Aditya, and Volker Hilt. SAND: Towards High-Performance serverless computing. In 2018 USENIX Annual Technical Conference (USENIX ATC 18), pages 923–935, Boston, MA, 2018. USENIX As...

  19. [27]

    A survey on the role of iot in agriculture for the implementation of smart farming

    Muhammad Shoaib Farooq, Shamyla Riaz, Adnan Abid, Kamran Abid, and Muhammad Azhar Naeem. A survey on the role of iot in agriculture for the implementation of smart farming. IEEE Access, 7:156237–156271, 2019. doi: 10.1109/ACCESS.2019.2949703

  20. [28]

    Cwasi: A webassembly runtime shim for inter-function communication in the serverless edge-cloud continuum

    Cynthia Marcelino and Stefan Nastic. Cwasi: A webassembly runtime shim for inter-function communication in the serverless edge-cloud continuum. In Proceedings of the Eighth ACM/IEEE Symposium on Edge Computing , SEC ’23, page 158–170, New York, NY, USA, 2024. Association for C...

  21. [29]

    Frangoudis, and Schahram Dustdar

    Philipp Gackstatter, Pantelis A. Frangoudis, and Schahram Dustdar. Pushing serverless to the edge with webassembly runtimes. In2022 22nd IEEE International Symposium on Cluster, Cloud and Internet Computing (CCGrid) , pages 140–149,

  22. [30]

    We- bassembly as a common layer for the cloud-edge continuum

    Jämes Ménétrey, Marcelo Pasin, Pascal Felber, and Valerio Schiavoni. We- bassembly as a common layer for the cloud-edge continuum. In Proceedings of the 2nd Workshop on Flexible Resource and Application Management on the Edge, FRAME ’22, page 3–8, New York, NY, USA, 2022. Asso...

  23. [31]

    Wasmedge, 2024

    WasmEdge. Wasmedge, 2024. URL https://wasmedge.org/. Accessed: 2024-06-30

  24. [32]

    Docker: Accelerated, containerized application development, 2024

    Docker. Docker: Accelerated, containerized application development, 2024. URL https://www.docker.com/. Accessed: 2024-06-30

  25. [33]

    Wasmedge rust sdk, 2024

    WasmEdge. Wasmedge rust sdk, 2024. URL https://github.com/WasmEdge/ wasmedge-rust-sdk. Accessed: 2024-06-30

  26. [34]

    doi: 10.1109/CCGrid54584.2022.00023

  27. [35]

    Openfaas - serverless functions made simple, 2024

    OpenFaaS. Openfaas - serverless functions made simple, 2024. URL https: //www.openfaas.com/. Accessed: 2024-06-30

  28. [36]

    Spin - fermyon developer documentation, 2024

    Fermyon Technologies. Spin - fermyon developer documentation, 2024. URL https://developer.fermyon.com/spin/v2/index. Accessed: 2024-06-30

  29. [37]

    Faabric: Fine-grained distribution of scientific workloads in the cloud

    Simon Shillaker, Carlos Segarra, Eleftheria Mappoura, Mayeul Fournial, Lluis Vilanova, and Peter Pietzuch. Faabric: Fine-grained distribution of scientific workloads in the cloud. arXiv preprint arXiv:2302.11358, 2023

  30. [38]

    Open container initiative runtime specification, 2024

    The Linux Foundation. Open container initiative runtime specification, 2024. URL https://github.com/opencontainers/runtime-spec/blob/main/spec.md

  31. [39]

    Redis, 2024

    Redis. Redis, 2024. URL https://redis.io/. Accessed: 2024-06-30

  32. [40]

    Anna: A kvs for any scale

    Chenggang Wu, Jose Faleiro, Yihan Lin, and Joseph Hellerstein. Anna: A kvs for any scale. In 2018 IEEE 34th International Conference on Data Engineering (ICDE) , pages 401–412, 2018. doi: 10.1109/ICDE.2018.00044

  33. [41]

    Vate: Edge-cloud system for object detection in real-time video streams

    Maximilian Maresch and Stefan Nastic. Vate: Edge-cloud system for object detection in real-time video streams. In The 8th IEEE International Conference On Fog and Edge Computing (ICFEC 2024) , 2024

  34. [44]

    Faleiro, Joseph E

    Vikram Sreekanti, Chenggang Wu, Xiayue Charles Lin, Johann Schleier-Smith, Jose M. Faleiro, Joseph E. Gonzalez, Joseph M. Hellerstein, and Alexey Tumanov. Cloudburst: Stateful functions-as-a-service. Proc. VLDB Endow., 13:2438–2452, 2020

  35. [2012]

    Vortrag: IEEE 8th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob 2012), Barcelona, Spain; 2012-10-08 – 2012-10-10

    ISBN 978-1-4673-1428-2. Vortrag: IEEE 8th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob 2012), Barcelona, Spain; 2012-10-08 – 2012-10-10

  36. [2021]

    ISBN 9781450386036

    Association for Computing Machinery. ISBN 9781450386036. doi: 10.1145/ 3469263.3470828. URL https://doi.org/10.1145/3469263.3470828

  37. [2022]

    doi: 10.1109/CogMI56440.2022.00011

  38. [2023]

    doi: 10.1109/MIC.2023.3260939

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.