[Paper] Serverless Abstractions for Short-Running, Lightweight Streams

Source: arXiv - 2603.03089v1

Overview

The paper introduces stream functions, a new serverless abstraction that treats a short‑lived, lightweight data stream as the fundamental unit of execution, state, and scaling. By marrying the elasticity of Function‑as‑a‑Service (FaaS) with the iterator‑style processing of stream engines, the authors show how to handle unpredictable, stateful workloads far more efficiently than traditional serverless or stream‑processing platforms.

Key Contributions

• Stream‑function abstraction: Extends the classic FaaS model so that a stream (not a single event) is the execution boundary.
• Iterator‑based API: Provides a simple next()‑style interface that lets developers write per‑event logic while the runtime manages state and scaling.
• Zero‑to‑many elasticity: Retains serverless benefits such as instant scale‑to‑zero and automatic scaling up to many concurrent instances.
• Performance evaluation: Demonstrates up to 99 % reduction in processing overhead compared with a mature stream‑processing engine (Apache Flink) on a video‑processing benchmark.
• Prototype implementation: Built on top of an existing serverless platform (OpenWhisk) to validate feasibility and measure latency, cost, and resource usage.

Methodology

1. Problem framing – The authors first identify a gap: short, bursty streams (e.g., a few seconds of video frames, IoT sensor bursts) are too heavy for pure FaaS (which incurs cold‑start cost per event) and too light for traditional stream processors (which keep long‑running jobs alive).
2. Design of stream functions –
   • Execution unit: A stream is materialized as a temporary container that lives only for the duration of the stream.
   • State handling: State is kept in‑memory inside the container and automatically checkpointed when the stream ends, avoiding external storage round‑trips.
   • API: Developers write a function that receives an iterator (for event in stream:) and can emit results or update internal state.
3. Prototype – Implemented as a layer on top of OpenWhisk, leveraging its existing scheduler, container pool, and auto‑scaling logic.
4. Benchmark – A video‑processing pipeline (frame extraction → filter → aggregation) is executed both with the stream‑function prototype and with Apache Flink. Metrics collected: end‑to‑end latency, CPU‑seconds, and monetary cost.

Results & Findings

The results confirm that for short‑running, lightweight streams, the overhead of maintaining a full stream‑processing job dwarfs the actual compute work. Stream functions eliminate that overhead while still offering exactly‑once semantics and stateful processing.

Practical Implications

• Edge & IoT workloads – Devices that emit bursts of sensor data (e.g., a few seconds of accelerometer readings) can be processed with near‑zero latency and cost, without provisioning a dedicated stream cluster.
• Media pipelines – Short video clips, live‑stream highlights, or user‑generated GIFs can be transformed on‑the‑fly using serverless containers that spin up for the clip’s duration and disappear afterward.
• Micro‑service orchestration – Complex event chains that need intermediate state (e.g., a multi‑step fraud‑check) can be expressed as a single stream function, simplifying deployment and observability.
• Cost optimization – Since containers terminate as soon as the stream ends, you pay only for the actual compute, making it attractive for pay‑as‑you‑go cloud budgets.
• Developer ergonomics – The iterator API feels like ordinary Python/Node.js loops, lowering the learning curve compared with learning a full stream‑processing DSL.

Limitations & Future Work

• Stream length bound – The current prototype assumes streams are short (seconds to minutes). Very long streams would re‑introduce the same resource‑waste issues seen in traditional engines.
• State durability – In‑memory state is lost if a container crashes mid‑stream; future work could integrate lightweight checkpointing or external state stores.
• Platform dependence – The implementation relies on OpenWhisk’s container model; portability to other serverless runtimes (AWS Lambda, Azure Functions) needs further engineering.
• Scheduling granularity – The prototype uses a simple “one container per stream” policy; more sophisticated packing algorithms could improve resource utilization for high‑concurrency scenarios.

Bottom line: Stream functions offer a compelling middle ground for developers who need the elasticity of serverless functions but also require stateful, per‑event logic over short-lived data bursts. As cloud providers continue to evolve their serverless offerings, this abstraction could become a standard building block for real‑time, cost‑effective data pipelines.

Authors

• Natalie Carl
• Niklas Kowallik
• Constantin Stahl
• Trever Schirmer
• Tobias Pfandzelter
• David Bermbach

Paper Information

• arXiv ID: 2603.03089v1
• Categories: cs.DC
• Published: March 3, 2026
• PDF: Download PDF