PaperlayerView exact revision on arXiv

Source-linked AI summary

Kirin: Cloud-native WebAssembly Service Orchestration

Joshua Bauer, Sebastian Werner, Maria C. Borges

arXiv:2609.39631v1cs.DC

TL;DR

Containers have overhead, and WebAssembly research beyond serverless and edge remains limited, leaving cloud-service efficiency and lifecycle questions underexplored. Kirin evaluates a WebAssembly service orchestrator against Docker, finding advantages for I/O-bound workloads but weaker results for CPU- and memory-bound ones.

  • Problem

    Research on WebAssembly beyond serverless and edge remains rare, and comparisons leave resource efficiency and lifecycle management underexplored.

    Source: §1 · p. 1

  • Method

    Kirin is a proof-of-concept WebAssembly service orchestrator evaluated against a container-based baseline across representative cloud-native workloads.

    Source: §1 · p. 1

  • Results

    WebAssembly outperforms Docker for I/O-bound workloads but underperforms on CPU- and memory-bound workloads; Kirin’s energy efficiency is 2.62x higher under continuous orchestration load.

    Source: §4.2.1 · p. 5, §6 · p. 7

  • Takeaways & Limitations

    The authors argue that WebAssembly may suit typical web services beyond serverless and edge, while integration with existing orchestrators such as Kubernetes remains needed.

    Source: §6 · p. 7, §5.2 · p. 7

    The evaluation covers isolated workloads and a purpose-built orchestrator, leaving transfer to production environments open.

    Source: §6 · p. 7

Abstract

from arXiv · show

Modern cloud computing infrastructure relies heavily on virtualization to provide workload isolation and resource efficiency. While containers have become the dominant deployment primitive due to their fast orchestration compared to traditional virtual machines, they still introduce non-trivial overhead. WebAssembly (Wasm) has emerged as an alternative isolation technology, offering a lightweight execution model. Because of compatibility limitations, WebAssembly has mainly been applied to Function-as-a-Service (FaaS) and Edge Computing scenarios, where it has attracted growing research interest. However, recent advances in the WebAssembly ecosystem have significantly matured the technology, raising the question of whether it can serve as a viable replacement for containers in cloud-native workloads. In this paper, we present Kirin, an orchestrator for cloud-native WebAssembly services. It supports core orchestration responsibilities, including resource scheduling, lifecycle management, scaling, and request routing. We evaluate Kirin against container-based deployments for several service workloads and demonstrate promising results, particularly in service lifecycle management. Simultaneously, we confirm known limitations in CPU-intensive workloads. However, for typical service workloads, Kirin demonstrates competitive performance, suggesting that WebAssembly is a viable candidate for broader adoption as a cloud-native deployment technology.

1 Introduction

Containers offer practical isolation and orchestration but retain overhead, while WebAssembly research beyond serverless and edge remains limited. Kirin investigates whether Wasm can support cloud-native services, with experiments focused on resource efficiency and lifecycle management.

1 Introduction

  • Container overhead and Wasm’s suitability beyond serverless and edge motivate testing Wasm for cloud-native services.Reported container costs include image size, startup latency, and orchestration overhead; Wasm offers small binaries and fast startup.Source: §1 · p. 1
  • Evidence for WebAssembly beyond serverless and edge remains rare, and existing comparisons leave resource efficiency and lifecycle management underexplored.The cited recent container-replacement studies had mixed results and tended to emphasize startup latency.Source: §1 · p. 1
  • The study characterizes cloud-native workloads and experimentally examines which may benefit from Wasm, emphasizing resource efficiency and service lifecycle management.The introduction frames the inquiry as empirical assessment of WebAssembly-based service orchestration.Source: §1 · p. 1
  • Kirin is a proof-of-concept Wasm service orchestrator evaluated against a container baseline across representative cloud-native workloads.Its stated orchestration responsibilities include scheduling, lifecycle management, and request routing.Source: §1 · p. 1

2 Related Work

Containers can impose overhead in cloud deployments, while WebAssembly’s lightweight, capability-based execution model offers a potential alternative. The paper builds a small benchmarking orchestrator to measure core Wasm service orchestration primitives without additional layers obscuring their behavior.

2 Related Work

  • Container overhead in I/O, context switching, and cold starts can constrain efficiency, especially in resource-constrained or high-density environments.The passages connect these overheads to limits on cloud-native deployment performance and efficiency.Source: §2 · pp. 1–2
  • WebAssembly’s userspace capability model provides fine-grained resource access control and avoids container-system system-call context switches.The paper presents this as a safer, lower-overhead execution environment.Source: §2 · p. 2
  • The authors built a small proof-of-concept Wasm service orchestrator as a benchmarking harness to test expected startup-latency and energy-consumption benefits.The stated benefits are hypotheses to measure, not results established by this passage.Source: §2 · p. 2
  • Kirin is a minimal Rust system intended to measure scheduling, lifecycle management, scaling, load balancing, and routing without complex orchestrator abstractions obscuring them.Existing Wasm orchestrators targeted serverless or edge settings, while Kubernetes complexity motivated a controlled measurement environment.Source: §2 · p. 2

3 Kirin

Kirin is a standalone WebAssembly service orchestrator designed to expose core orchestration behavior for measurement. It combines host-level service management with per-request Wasm execution and resource controls.

3 Kirin

  • Kirin is a WebAssembly service orchestrator for deploying Wasm-based services on a host.The paper introduces its requirements, architecture, usage, and operation.Source: §3 · p. 2

3.1 Requirements

  • Orchestrator requirements include service lifecycle and host-resource management, scaling replicas with demand, and service discovery in dynamic deployments.Lifecycle covers creation through destruction and recovery; scaling coordinates resources and load distribution.Source: §3.1 · p. 2
  • Kirin implements core Wasm orchestration as a standalone system to avoid obscuring performance and lifecycle differences with runc or Kubernetes abstraction layers.The paper notes that existing Wasm shims were still incubating and that suitable request-handling abstractions remained unclear.Source: §3.1 · p. 2

3.2 Architecture

  • Kirin’s client-server flow sends HTTP API requests to a daemon, which assigns orchestration tasks; listeners accept HTTP/gRPC connections and spawn Wasm service tasks for requests.The task output returns through the listener to complete the request flow.Source: §3.2 · pp. 2–3, Figure 1 · p. 3
  • A Tokio-based asynchronous runtime runs orchestration, service, and communication tasks; Wasmtime compiles and executes WebAssembly components and modules.The HTTP API also allows communication with a Kirin daemon across a network.Source: §3.2 · p. 3

3.3 Usage

  • Each valid HTTP request spawns an isolated service task with a Wasmtime store, which Kirin deallocates when the request finishes.This per-request isolation is stronger than container-based isolation but may add startup cost for each request.Source: §3.3 · p. 3

3.4 Orchestration

  • Kirin enables WASI capabilities per service, applies Wasmtime memory limits, and implements CPU limiting through epoch-based interruption and cooperative timeslicing.Users can configure the tick interval for interrupting running Wasm code.Source: §3.4 · p. 3
  • Users upload compiled Wasm binaries for storage; their typically small size and already-running Tokio processes keep startup costs low.The passage gives below 1 MB as a typical binary size.Source: §3.4 · pp. 3–4

4 Evaluation

The evaluation compares Kirin with Docker across HTTP service loads, cold starts, and orchestration actions, finding workload-dependent advantages and strong lifecycle results for WebAssembly.

4.1 Experiment Protocol

  • Kirin was compared with Docker-CE using the same Rust services and resource limits, rather than Kubernetes, to isolate core orchestration primitives.The evaluation included HTTP load, cold-start, and orchestration tests.Source: §4.1 · p. 4, §4 · p. 4
  • Energy use was estimated with a power model based on CPU cycles and stalled cycles, which together explained 95% of observed counter variance.The model's in-sample R2 was 0.91; perf sampling enabled finer-grained power measurements than RAPL for short workloads.Source: §4.1 · p. 4
  • The HTTP test measured request latency, throughput, data-transfer rate, and success rate, and varied concurrency to assess parallel resource use.The evaluation also measured CPU and memory utilization per operation and energy efficiency.Source: §4.1 · p. 4, §4.2 · p. 5

4.2.1 HTTP Load Test

  • Kirin outperformed Docker in every metric on short-lived, I/O-bound workloads, while Docker outperformed on compute-intensive workloads, with WebAssembly worst on matrix.The paper concludes WebAssembly is not the isolation technology of choice for long-running, CPU-intensive workloads.Source: §4.2.1 · p. 5, Table 2 · p. 6
  • 3.4x versus 2.8x was the overall concurrency factor for Wasm versus Docker, with Wasm showing higher base throughput at every tested concurrency.This was despite Kirin using an instance-per-request scheme and Docker using one instance.Source: §4.2.1 · p. 5, Table 3 · p. 6

4.2.2 Cold-Start Test

  • Cold-start latency measured the time to start a service instance from scratch until it was ready for requests, including process creation and initialization.Only hello-world results were reported because results were described as extremely similar across workloads.Source: §4.2.2 · p. 5
  • 720 Kirin service instances versus 180 Docker containers were created; WebAssembly also had five-times-better tail latency and 1.62x higher energy efficiency.The cold-start comparison reports the hello-world workload.Source: §4.2.2 · p. 5, Table 4 · p. 6

4.2.3 Orchestration Test

  • Kirin via WebAssembly outperformed Docker in orchestration-operation throughput and mean and tail latency, while also supporting more successful HTTP requests overall.The benchmark ran plausible orchestration actions while services were under load.Source: §4.2.3 · p. 5, Figure 2 · p. 5

5 Discussion

Kirin’s discussion highlights lighter service lifecycle management and strong fit for I/O-bound workloads, while identifying CPU- and memory-bound workloads as a limitation. The authors use service-resource patterns in the Alibaba trace to motivate WebAssembly’s potential role in cloud-native architectures, alongside the need for better orchestrator integration.

5.1 Result Analysis

  • Kirin provides lighter lifecycle management, primarily through WebAssembly’s improved startup and shutdown characteristics.The discussion attributes this to WebAssembly modules’ smaller footprint and reduced initialization and cleanup work compared with containers.Source: §5.1 · p. 6
  • Under load, WebAssembly’s HTTP metrics tend to outperform Docker’s except for mean latency; it performs well for I/O-bound workloads but underperforms for long-running CPU- or memory-bound workloads.The discussion also reports improved efficiency at higher concurrency factors.Source: §5.1 · p. 6, Figure 3 · p. 6

5.2 A case for WebAssembly in cloud native architectures

  • In one day of Alibaba Cluster Trace data, networked operations such as HTTP, gRPC, and events dominate the service-resource distribution.Services are assigned to the category matching their maximal standardized Compute, Memory, Network, or Database intensity.Source: §5.2 · p. 6, Figure 4 · p. 7
  • The authors connect WebAssembly’s fit for short-lived networked tasks to serverless platforms, while noting that hybrid deployments need better integration with existing orchestrators such as Kubernetes.They present this as a case for WebAssembly as a feasible alternative in cloud-native architectures, not as a claim that it matches native execution speed.Source: §5.2 · pp. 6–7

6 Conclusion

Kirin’s evaluation finds substantial benefits for I/O-bound services, but identifies long-running CPU- or memory-bound workloads as a poor fit. The conclusion presents WebAssembly as complementary to containers and notes that production applicability remains open because the evaluation used isolated workloads and a purpose-built orchestrator.

6 Conclusion

  • 2.62x better energy efficiency over Docker under continuous orchestration load, roughly four times the instance-creation throughput, and 1.62x better cold-start energy efficiency summarize Kirin’s gains.Source: §6 · p. 7
  • For long-running CPU- or memory-bound workloads, WebAssembly execution overhead outweighs cheaper isolation, making Docker the more appropriate choice.Source: §6 · p. 7
  • The evaluation covers isolated workloads and a purpose-built orchestrator, leaving production-environment transfer open; future work targets large microservice topologies and Kubernetes.Source: §6 · p. 7
Loading 2609.39631v1…