Kirin: Cloud-native WebAssembly Service Orchestration

Kirin: Cloud-native WebAssembly Service Orchestration Preprint, compiled October 1, 2026 Joshua Bauer, Sebastian Werner

ID

, and Maria C. Borges

ID

Technische Universität Berlin {joba, sw, mb}@ise.tu-berlin.de

arXiv:2609.39631v1 [cs.DC] 30 Sep 2026

Abstract 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

In this work, we explore WebAssembly-based service orchestration as a foundation for more efficient cloud deployments. We characterize different workloads for cloud-native environments, investigate which types of workloads stand to benefit most from this approach, and conduct experiments with a particular focus on resource efficiency and service lifecycle management.

Modern cloud-native applications are typically built as a set of loosely coupled services that operate independently of one another [1]. Containers have become the de facto standard for deploying these services, offering several advantages such as process isolation, portability across environments, and runtime In summary, we make the following contributions: consistency [2]. Meanwhile, orchestration systems like Kubernetes [3] take care of the surrounding tasks, including resource • We design and implement Kirin, a proof-of-concept scheduling, lifecycle management, scaling, and request routorchestrator for Wasm-based services, addressing ing [4, 5]. Together, these technologies have made large-scale scheduling, lifecycle management, and request routservice deployments more efficient and practical [6, 7]. ing However, containers also come with well-known limitations, including large image sizes, start-up latency, and orchestration overhead. Earlier studies have, for example, measured overheads of up to 10% in network-heavy workloads [8, 9]. Recently, WebAssembly has emerged as a new isolation and deployment technology. It features a lightweight runtime with strong isolation, small binaries and fast startup [10, 11]. Already many studies have demonstrated Wasm’s suitability for serverless and edge scenarios, where container limitations are most pronounced [12–15].

• We evaluate our system across a representative set of cloud-native workloads, comparing it against a container-based baseline • We discuss the applicability of Wasm-based services based on results from above.

The paper is structured as follows: First, we review related work in Section 2. From this we extract requirements for Kirin in Section 3. Section 4 evaluates Kirin and presents results for resource efficiency, start-up latency, and lifecycle management. Finally, we discuss results in Section 5 before concludHowever, research on WebAssembly beyond serverless and ing in Section 6. edge use cases remains rare. In the past, the technology was admittedly very limited and unsuitable for cloud deployments. But thanks to WASI and other ecosystem improvements, Wasm 2 Related Work is maturing very rapidly. Two recent papers have already examined Wasm as a potential replacement for containers [10, 16], Cloud service architectures are built for horizontal scalability with mixed results. We argue that more empirical studies are and rely heavily on containerization and complex orchestrators needed. Existing comparisons tend to focus on start-up latency, like Kubernetes [17] to manage resources at scale. While conleaving operator-side questions of resource efficiency and life- tainers provide necessary isolation, they introduce some overcycle management underexplored. Plus, in such a fast-moving head, particularly during I/O operations, context switching, and ecosystem, results showing WebAssembly trailing containers cold-start events [8, 9]. These overheads, which can be substantial for resource-constrained or high-density environments, may not hold for long.

Preprint – Kirin: Cloud-native WebAssembly Service Orchestration

2

limit the overall efficiency and performance of cloud-native de- means automatically duplicating services to meet increased demand and reducing the number of service instances when ployments [18]. demand subsides. When scaling, the orchestrator must acWebAssembly (Wasm) has emerged as a promising alternacount for the host machine’s resource limits, thereby connecttive isolation technology [12]. Unlike traditional virtualizaing these two requirements. Scaling typically entails the aution or container runtimes, Wasm operates on a lightweight, tomatic scheduling of resources and services, as well as discapability-based model [16]. This design enables fine-grained tributing incoming load across service replicas according to a resource access control through explicit capabilities, impleload-balancing policy. Such scaling and load-balancing also mented entirely in userspace. This approach avoids the expenenables graceful rollouts and updates, critical for continuous sive context switches associated with system calls in container service operation. systems, offering a safer and lower-overhead execution environment [10, 19]. Service discovery Most orchestrators provide a way for each These savings should translate into measurable performance service to discover other services, which is essential for creatbenefits, such as lower start-up latency and energy consump- ing distributed applications where components need to commution. To test this, we developed a small proof-of-concept or- nicate with each other. In the dynamic environments typical for chestrator for WebAssembly services to serve as a benchmark- microservice systems, services are frequently deployed, scaled, ing harness. moved, or replaced across infrastructure, which makes static We chose to build a minimal system in Rust rather than ex- configuration impractical. tend an existing open-source orchestrator. Other existing Wasm orchestrators were either purpose-built for a different serverless/edge environment [11, 13, 20, 21] or, in the case of Kubernetes, are so complex that they obfuscate the core orchestration primitives we wanted to evaluate. Our intent was not to build a competitive orchestrator, but to construct a controlled environment in which the essential primitives such as resource scheduling, lifecycle management, scaling, load balancing, and routing could be measured in isolation.

Both Docker (containerd) and Kubernetes already support these requirements. For Wasm-based services, there are existing Runc-compatible shims that support lifecycle and resource management. However, these projects are still in the incubation stage. The goal of these projects is to integrate Wasm into existing ecosystems, but it remains unclear whether the same abstractions and separation of concerns that work well for Docker (containerd) also make sense for a Wasm runtime. For example, it is not obvious whether request handling should be delegated to processes running within a container, or whether request-based isolation should instead be provided directly by 3 Kirin the runtime. In this paper, we focus on the core orchestration primitives required to run Wasm-based services. Therefore, we In this paper, we develop Kirin, a WebAssembly-based service opted to implement a standalone orchestration that natively suporchestrator that can be used to deploy Wasm-based services ports Wasm-based services, which we call Kirin 1 . on a host. For this, we first lay out the basic requirements that a WebAssembly-based service orchestrator needs. Then, we This approach gives us better control over the relevant aspects describe the Architecture of Kirin, how it is used and how the of serving and managing Wasm services and avoids obscuring performance and lifecycle differences through additional aborchestrator works in detail. straction layers such as runc and Kubernetes. 3.1 Requirements 3.2 Architecture Lifecycle management A primary task of an orchestrator is to manage the lifecycle of services. This means that the or- Kirin is a small orchestrator for WebAssembly services imchestrator must accept a definition of a service and manage its plemented in Rust. We chose Rust because it performs well state throughout its lifecycle. The lifecycle of a service encom- on energy efficiency benchmarks and facilitates concurrent and passes all its state transitions from service creation to service multi-threaded programming. Additionally, Rust provides a rodestruction. Typically, the operations required include creat- bust ecosystem of libraries for interacting with WebAssembly, ing, starting, stopping, updating, and destroying the service. given that the Wasmtime2 WebAssembly runtime is also impleConsistent state management is required because services may mented in Rust, and Rust generally treats WebAssembly as a fail, and the orchestrator is responsible for moving the service first-class citizen in its tooling. to an appropriate state from which it can be restarted. Kirin (see fig. 1) follows a client-server architecture inspired by Kubernetes, a client that wraps an HTTP-API 1 to interResource management An orchestrator needs to distribute act with the orchestrator daemon 2 . The daemon turns API the resources of the host machine across the services that are requests into specific orchestration tasks 3 . The orchestrator orchestrated on that machine. This means that it must provide owns all running tasks (services), shared state and available serfacilities to partition and isolate host resources, such as the CPU vice listeners for a single node. Listeners 4 accept http/grpc and memory. More advanced orchestrators might also limit or connections from consumers and request a service from the orpartition the throughput on resources such as the network or the chestrator to spawn service tasks to handle requests. Each serfile system [5]. vice task 5 requests the Wasm function to handle the request Scaling Beyond resource management, the orchestrator must allow services to scale based on the load they receive. This

1 2

Kirin is available at https://github.com/nymphbox/kirin https://wasmtime.dev/

Preprint – Kirin: Cloud-native WebAssembly Service Orchestration

1

3.3

kirin-client

2

kirin-daemon

3

Orchestrator Task

Service Tasks State

State

WASM

WASM

5 HTTP Proxy

HTTP Proxy

6 7 HTTP Listener Task 4

7

4

4 Service consumers Figure 1: Kirin architecture

3 Usage

Taking inspiration from Kubernetes, Kirin distinguishes between a service specification and a service instance. A service specification is the abstract definition of a service consisting of a name, the associated WebAssembly bytecode, and configuration parameters, such as the port number or the maximum usable memory. A service is implemented through a listener task that can spawn service tasks. The listener task is spawned when Kirin receives a start command for a particular service. The listener task accepts TCP connections on the port defined in the service specification and will forward any valid HTTP requests received on that connection to a service task it spawns in response to each request. Thus Kirin provides per-request isolation, which is a stronger variant of isolation than what is provided by a container-based system. However, this creates potential start-up cost per request, as we have to create an isolated environment per request. Each service task instantiates a store. A store is a collection of WebAssembly instances and state and is provided by Wasmtime as the container for all relevant WebAssembly objects such as functions, instances, memories and so on. Stores are designed to live no longer than the WebAssembly instances they hold, and so Kirin follows this pattern by tying these lifetimes directly together, i.e. the store is deallocated as soon as the request is handled, whereas the listener task is designed to be long-running and will exit once the daemon receives the corresponding command.

and capture the output 6 . The captured output is then handed 3.4 Orchestration back to the listener 7 to complete the typical request flow. The system needs to be able to isolate and partition the host’s We build Kirin with concurrency and internal asynchronous 3 resources like the file system, the network, the CPU, and memcommunication in mind. We leverage the Rust-based Tokio ory. By default, it is impossible for a WebAssembly module runtime to run all orchestration, service and communication to perform anything other than pure computation, manipulatasks, akin to goroutines or lightweight threads in other envition of its own linear memory, and calling declared and bound ronments. Through this, we are able to have a single daemon host functions. This gives us strong isolation by default. To interact with a very large number of http clients and serve Wasm enable more useful programs, the host (Kirin) can define stantasks to them. The Kirin daemon is an HTTP API server built dardized WASI host functions, that allow for additional capa4 on top of Axum . The http-based API allows a potential multibilities such as network and disk access. These capabilities can node orchestration as we can communicate with a Kirin daebe enabled on a per-service basis, and are part of the service mon across a network. Internally, all tasks communicate using description in Kirin. Besides enabling general capabilities, an channels without any other synchronization mechanism. orchestrator also needs to manage memory and CPU resource We use the Wasmtime5 runtime to compile and execute We- allocation. For memory, Wasmtime already comes with easy bAssembly components and modules. Wasmtime performs rel- means to define a memory limit that will interrupt and termiatively well in benchmarks [11, 13]. For compilation Wasm- nate the execution of the service if it exceeds this limit. For time uses Cranelift6 , which is also developed by the ByteCode CPU usage, Wasmtime does not provide a built-in mechanism Alliance. Xu et al. [22] show that while Cranelift produces to limit CPU access but it allows for fine granular instruction native code that is marginally slower than V8 (2%), and rela- counting through fuel or by implementing an epoch time-based tively slower than LLVM (14%), it compiles code around 10x interruption mechanism to manage execution time. In Kirin, faster than LLVM. Wang et al. [12] show that Wasmtime and CPU limiting is thus implemented on top of this epoch mechCranelift outperform other WebAssembly code generators on anism. Users can configure a tick interval at which running real-world benchmark tasks. They also show that Wasmtime Wasm code will be interrupted. Additionally, the starting timesand Cranelift have the best startup performance, echoing the tamp of each Wasm service is tracked, so we can determine the significantly higher compilation speed of Cranelift. actual time that has passed since the start of execution. These two mechanisms taken together implement very simple cooperative timeslicing, which we can use to limit execution of a particular service. 3

https://tokio.rs/ https://docs.rs/axum/latest/axum/ 5 https://bytecodealliance.org/ 6 https://cranelift.dev/ 4

Kirin expects users to transmit the compiled Wasm binaries when creating a new service. The files are stored on disk. In comparison to docker images, such binaries are typically very small, e.g., below 1 MB, and thus relatively cheap to store and

Preprint – Kirin: Cloud-native WebAssembly Service Orchestration

4

Table 1: Overview of the different services used in the evalua- For the CPU and memory efficiency metrics, we record the CPU utilization and memory utilization as percentages of tion. available capacity. These utilization metrics can then be comWorkload Category Description pared against the number of operations achieved per benchhello-world External Most basic http request-response loop. mark, which leads to an efficiency metric that gives a utilization Network per operation performed. read-file

Disk

Sequential and random reads and writes on a temporary file .

For energy consumption, we opted to apply a power modeling approach [23]. For this, we collected and observed performance counters using perf under stress scenarios while also collecting n-body CPU N-body problem approximation causing RAPL [24] values. Through a principal component analysis, many floating point operations. we selected cycles and stalls, which together explain 95% of binary-tree Memory Construction and traversing on a large bithe variance in the observed counter data. Intuitively, cycles nary tree in memory. and stalls reflect two distinct aspects of power consumption, matrix-multiplication CPU/Memory Matrix multiplication with varying matrix where the former measures the power consumption when the sizes. CPU is actively executing instructions, and the latter measures power consumption in a less energy-intensive state. The resultsend through the network. Due to this, startup costs are also ing model with fitted coefficients for the Intel Xeon E3-1230 V2 low, as the time to start a service is limited only by the file size. is: The Tokio processes are already running, thus, loading in a new task adds very little overhead. P = 15.47 + 3.34x1 + 2.23x2 + ϵ (1) http-request

4

Internal Network

Calls other services in the network using http.

Evaluation

where P is power in watts, x1 is cycles, x2 is stalled cycles, In the following, we evaluate whether Wasm-based services ϵ is an error term and the intercept models the average baseshow improved performance, resource, and energy efficiency line power. The regression achieves an in-sample R2 value of 0.91, which is in line with the literature for similar models. The by comparing Kirin with Docker. main benefit of using this model over RAPL measurements for our experiments is the sampling frequency difference between 4.1 Experiment Protocol RAPL and perf, allowing us a more fine-grained power consumption measurements for short-running workloads. All experiments were run on an Intel Xeon E3-1230 V2 with 32 GB Memory. We disable Turboboost and set the CPU governor to performance (fixed frequency) for less variation in power measurements. As a system under test (SUT) we compare Kirin Benchmarks In total, we designed three benchmarks to evaland Docker-CE, running the same services (see Table 1) com- uate the SUT. First, a HTTP Load Test for individual services. piled from Rust to binaries or Wasm-binaries. For Wasm isola- We measure the request latency as the time it takes for a retion, the Rust code is scaffolded with a simple WASI http han- quest to be processed and the request throughput as the number dler. For container isolation, the Rust code is scaffolded with of requests per second. We further measure the data transfer a simple asynchronous http request handler. Both scaffolds are rate for throughput. We also measure the success rate across kept as simple as possible, using the same asynchronous frame- requests. This benchmark is designed to capture how the isowork. Each workload therefore conceptually represents a ser- lation layer affects each metric across different services. The vice that receives an http request and performs some computa- benchmark can be configured to run concurrently or sequention in response. All workloads were deployed with the same tially and we report results for both configurations. Additionresource limits. We compare against Docker rather than Kuber- ally, varying the concurrency allows us to examine the degree netes deliberately. Our aim is to isolate the core orchestration of parallel resource efficiency of each isolation technology. primitives, and a full cluster orchestrator adds scheduling, net- Second, a Cold-Start Test, where we create many instances working, and control-plane layers that would add noise to the of a service and measure the distribution of cold-start latency, per-operation measurements. i.e. the time it takes from instance creation to a healthy service ready to take requests. Measurements The aim of this evaluation is to find perforLastly, an Orchestration Test, which randomly selects from mance/energy trade-offs in each SUT. a set of plausible orchestration actions to investigate lifecycle For service performance, we mainly focus on latency and management. These actions are: (a) creating an instance, (b) throughput of the http API of the deployed tasks. As part of deleting an instance, (c) stopping an instance, (d) updating an the evaluations, we also investigate how the throughput met- instance configuration and (e) listing the current status of all ric changes with more deployed instances (a). For this, we service instances. This benchmark is designed to model the regcompute a concurrency factor by comparing the throughput ular operation of an orchestration system. During the orchestraachieved at one concurrency level a to the next a + 1. This tion test we configure the http-request service to make requests gives additional insight into how well each SUT is able to use to other services at random to model inter-service communication. available resources in parallel.

Preprint – Kirin: Cloud-native WebAssembly Service Orchestration Results

In the following we present the results of the three described benchmarks, comparing energy efficiency, resource efficiency, throughput and latency between Kirin and Docker.

kirin

HTTP Load Test

We also run the http benchmark with the hello-world workload in different concurrency configurations varying the number of threads and connections to evaluate how well each technology utilizes resources in parallel. We avoid excessive contention on the test machine by limiting the number of threads and connections to less than the available cores on the machine. We choose the hello-world benchmark because it is the simplest workload that reveals the basic differences in both technologies. Table 3 shows that WebAssembly provides a much higher base throughput in all concurrency settings, and has better incremental scaling factors and a better overall concurrency factor (3.4x for Wasm vs. 2.8x for Docker). Note that this is despite Kirin implementing an instance-per-request scheme versus the single Docker instance tested. 4.2.2

Cold-Start Test

For the cold-start benchmark, we try to spawn as many instances of a service with a particular workload as possible for 60 seconds without putting the system under load. Given that the results are (naturally) extremely similar across workloads, we only report the results for the hello-world workload in table 4. For this benchmark, the cold start latency is defined as the time it takes to start a new service instance with a particular workload from scratch until it is ready to respond to requests. Note that due to the way we execute the benchmarks via our runner, this time includes process creation and other initialization work, which however is the same for both technologies and thus will not affect the comparison. The efficiency metric for this benchmark is the number of created instances divided by the total power estimated by the energy model, and thus very similar to the efficiency metric in the http Load Test. The throughput metric for this benchmark is correspondingly the number of created instances per second. Table 4 shows that WebAssembly instances via Kirin are far cheaper to initialize, and that we therefore can create

memory efficiency [operations/% memory util.]

2.62x

2.00x

2.41x

kirin

17.57

35.14

0.00

13.45

26.89

0.00

0.41

0.83

throughput [operations/second]

mean operation latency [seconds]

tail operation latency [seconds]

2.77x

0.36x

0.23x

all

Table 2 shows the main results of the http Load test. Here, we can see a strong divide between I/O bound workloads and memory/CPU bound workloads, where Kirin dominates I/O workloads but underperforms for CPU/Memory bound workloads. Hence, we can see that WebAssembly is generally preferable for short-lived and I/O-bound services, where it outperforms Docker in every metric. We see that the less intensive a particular workload is, the more the isolation overhead of Docker drags on performance and efficiency. Conversely, Docker clearly outperforms for compute-intensive tasks, and this advantage seems to increase the more CPU-intensive a task is, with the matrix workload taking the longest time and simultaneously offering the worst results for WebAssembly. This confirms that WebAssembly is not the isolation technology of choice for orchestrating long-running, CPU-intensive workloads.

CPU efficiency [operations/% cpu util.]

docker 0.00

4.2.1

energy efficiency [operations/watt]

all

4.2

5

docker

0.00

4.66

9.32

0.0000

0.1482

0.2963

0.0000

0.4178

0.8355

Figure 2: Performance and Efficiency of Orchestration Benchmark

many more instances than Docker containers, as the throughput metrics show. We are able to create around 720 service instances with Kirin, but only 180 instances with Docker, as the four times higher throughput indicates. The tail latency, which shows how long instance creation can take in the worst case, is five times better for WebAssembly, and very close to the mean cold start latency. These performance characteristics are reflected in the efficiency metrics. As we have speculated, the driver of the better initialization performance is significantly smaller WebAssembly modules that have less overhead due to a more static isolation. Thus WebAssembly uses the available memory and the available CPU cores more efficiently than Docker, resulting in a 1.62x higher energy efficiency. 4.2.3

Orchestration Test

For the orchestration benchmark, we selected a random plausible orchestration action, e.g., creating, deleting, and updating a service, ensuring that we only selected actions that were possible given the systems state. For the update action, we have avoided modifying the base image for the service, as this would be so costly for Docker (requiring a full rebuild of the container) that it would make Docker wholly uncompetitive, leading to uninteresting results. Beyond these orchestration actions, we put each created service under load similar to what we did in the HTTP benchmark. This allows us to take into consideration how disruptive the orchestration actions are to the continued functioning of the services, and how http throughput and latency are affected by each orchestrator. Starting with the performance metrics for the orchestration actions, fig. 2 shows operation throughput as well as mean and tail latency across all operations. Evidently, Kirin via WebAssembly is able to outperform Docker in terms of pure orchestration performance across all metrics. This is primarily driven by the lighter isolation model, where we avoid additional work by the operating system, leading to better startup and shutdown performance, which dominates the benchmark results. The higher number and faster startup are also reflected in an overall better http performance (see fig. 3), where Kirin could service many more successful requests. One reason for the increased throughput is that the WebAssembly services were much faster in serving requests when started through random orchestration events, hence allowing overall more requests to succeed over time.

Preprint – Kirin: Cloud-native WebAssembly Service Orchestration

6

Table 2: HTTP benchmark: Kirin relative to docker baseline, expressed as ∆ = (Kirin − docker)/docker

Efficiency Workload

Performance

∆ Energy eff. ↑

∆ CPU eff. ↑

∆ Mem. eff. ↑

∆ Throughput ↑

∆ Mean lat. ↓

∆ Tail lat. ↓

[%]

[%]

[%]

[%]

[%]

[%]

+186.0 +63.0 +3.0

+207.0 +58.0 -7.0

+221.0 +98.0 +2.9

+213.0 +95.0 +6.7

-60.0 -54.0 -4.0

-68.0 -86.0 +1.0

-44.0 -2.0 -74.1

-34.0 -30.0 -72.0

-36.0 -31.7 -72.0

+67.0 +47.0 +255.0

-3.0 +39.0 +163.0

I/O workloads hello-world read-file http-request

CPU, memory and mixed workloads n-body binary-tree matrix-multiplication

-42.0 +2.86 -76.0

Table 3: Requests per second and concurrency factors for dif- be performed at initialization compared to containers. Conferent concurrency levels in the http benchmark. (Factors are versely, this leads to better shutdown performance as there are fewer structures to release and clean up than with containrelative to prior level). ers. WebAssembly thus offers far better operation throughput, Concurrency Level 1 2 4 6 which is also reflected in the improved efficiency metrics comKirin 11469 13671 (1.2x) 29206 (2.1x) 38261 (1.3x) pared to Docker containers, where the higher throughput exDocker 4635 7559 (1.6x) 11169 (1.4x) 12981 (1.1x) plains much of the efficiency gains. Moreover, because there is less disruption when performing orchestration operations while the system is under load, the HTTP metrics also tend to be betTable 4: Performance metrics of the cold start benchmarks for ter for WebAssembly when compared to Docker, with the exthe hello-world workload. ception of the mean latency. These results are also in line with Efficiency Performance the observations from the cold-start benchmarks, which show Energy eff. ↑ CPU eff. ↑ Mem. eff. ↑ Throughput ↑ Mean lat. ↓ Tail lat. ↓ overall better efficiency when starting new service instances. Runtime [instances/W] [req./% cpu util.] [req./% mem] [instances/s] [s] [s] Beyond the improvement in lifecycle management and cold kirin 8.91 10.16 0.0020 12.02 0.0850 0.0900 start, we confirmed that Wasm performs well for I/O-bound Docker 5.50 7.42 0.0017 3.06 0.3387 0.4542 workloads but underperformes for long running CPU or Memory based workloads. These trends also show overall improved efficiency at higher concurrency factors.

5

Discussion

all

5.2 A case for WebAssembly in cloud native architectures In the following we analyze the results of the evaluation in section 4 and review how these results motivate a broader adoption Coupled with the good performance on I/O dominant tasks, we of WebAssembly for cloud native architectures. can clearly see a space where WebAssembly-based web services make sense in a larger cloud-native architecture. More5.1 Result Analysis over, we do not claim that WebAssembly matches native execution speed; the matrix and n-body results show clearly that Summarizing the results, we conclude that Kirin provides more it does not. Indeed, we argue that most web services are not lightweight lifecycle management, primarily driven by the im- bound by CPU or memory but by network and IO, so the releproved startup and shutdown characteristics of WebAssembly, vant comparison is isolation cost, not peak compute. See fig. 4 as we also observed in the cold-start benchmarks. Recall that as an example. Here, we took one day’s worth of tracing this result is expected because WebAssembly modules have a data from the Alibaba Cluster Trace 2022 dataset [25] and resmaller footprint than Docker images and require less work to viewed what the most dominant resource was per recorded service during its lifetime7 . We observe that networked operations (HTTP, gRPC, events) dominate the distribution. Here, throughput [requests/second] mean req. latency [seconds] tail req. latency [seconds] successful requests [%] WebAssembly could be a feasible alternative to containers, offering1.95x smaller footprints and higher energy efficiency. This 2.02x 1.11x 0.49x kirin also confirms the trend for WebAssembly-based serverless platdocker

7 We arrived at this distribution by classifying all microservices in the data into each dominant-usage category (highest accumulated us0.00 51.63 103.26 0.00 0.02 0.04 0.00 0.22 0.44 0.00 7.73 15.45 age). Each service is first reduced to a service-level feature profile, its Compute, Memory, Network, and Database intensities are standardFigure 3: HTTP performance metrics in the orchestration ized across services, and the service is then assigned to the category benchmark corresponding to its maximal standardized intensity.

Preprint – Kirin: Cloud-native WebAssembly Service Orchestration

Services Type Distribution

7

For future work, we aim to examine WebAssembly-based services in the context of large microservice topologies and in the context of mature and distributed orchestrators such as Kubernetes.

Network Heavy

References 80.3% 2.8% 5.3% 11.6%

Data Heavy Compute Heavy Memory Heavy

Figure 4: Dominant resource need of service in the Alibaba Cluster Trace in one day [25]

forms [14, 15], which benefit the most from cold-start and orchestration overhead reduction because they typically host short-lived networked tasks. However, we still need to integrate this technology better into already existing orchestrators such as Kubernetes, to allow for such hybrid systems that combine the strengths of both.

6

Conclusion

In this work, we examined WebAssembly as an isolation technology for cloud-native services, with a particular focus on resource efficiency and service lifecycle management. For this, we designed, implemented, and evaluated Kirin. We compared WebAssembly-based web services against Docker. Here, we have shown that WebAssembly offers substantial advantages for I/O-bound services, where its lightweight isolation model translates directly into higher throughput, lower tail latency, and markedly better energy efficiency. Most notably, Kirin achieves a 2.62x improvement in energy efficiency over Docker under continuous orchestration load, sustains roughly four times the instance creation throughput, and improves coldstart energy efficiency by 1.62x. At the same time, our results delineate the boundaries of this approach. For longrunning, CPU- or memory-bound workloads, the overhead of WebAssembly’s execution model outweighs the gains from cheaper isolation, and Docker remains the more appropriate choice. WebAssembly is therefore best understood not as a wholesale replacement for containers, but as a complementary isolation technology. We argue that most web services are typically not performing heavy computation or need vast amounts of memory, therefore, inviting the WebAssembly benefits to cloud native services beyond its adoption for serverless and edge platforms. However, our evaluation was deliberately scoped to isolated workloads and a purpose-built orchestrator, which leaves open the question of how these results carry over to production environments.

[1] N. Kratzke and P.-C. Quint, “Understanding cloud-native applications after 10 years of cloud computing - a systematic mapping study,” Journal of Systems and Software, vol. 126, pp. 1–16, 2017. [2] D. Gannon, R. Barga, and N. Sundaresan, “Cloud-native applications,” IEEE Cloud Computing, vol. 4, no. 5, pp. 16–21, 2017. [3] B. Burns, B. Grant, D. Oppenheimer, E. Brewer, and J. Wilkes, “Borg, omega, and kubernetes,” Communications of the ACM, vol. 59, p. 50–57, Apr. 2016. [4] A. Khan, “Key characteristics of a container orchestration platform to enable a modern application,” IEEE Cloud Computing, vol. 4, no. 5, pp. 42–48, 2017. [5] M. A. Rodriguez and R. Buyya, “Container-based cluster orchestration systems: A taxonomy and future directions,” Software: Practice and Experience, vol. 49, no. 5, pp. 698–719, 2019. [6] V. Medel, R. Tolosana-Calasanz, J. Á. Bañares, U. Arronategui, and O. F. Rana, “Characterising resource management performance in kubernetes,” Computers & Electrical Engineering, vol. 68, pp. 286–297, 2018. [7] T. Chiba, R. Nakazawa, H. Horii, S. Suneja, and S. Seelam, “Confadvisor: A performance-centric configuration tuning framework for containers on kubernetes,” in 2019 IEEE International Conference on Cloud Engineering (IC2E), pp. 168–178, 2019. [8] R. Morabito, J. Kjällman, and M. Komu, “Hypervisors vs. lightweight virtualization: A performance comparison,” in 2015 IEEE International Conference on Cloud Engineering, pp. 386–393, 2015. [9] Z. Kozhirbayev and R. O. Sinnott, “A performance comparison of container-based technologies for the cloud,” Future Generation Computer Systems, vol. 68, pp. 175– 182, 2017. [10] M. Liu, H. Shen, Y. Zhang, H. Mei, and Y. Ma, “Webassembly for container runtime: Are we there yet?,” ACM Transactions on Software Engineering Methodology, vol. 34, July 2025. [11] M. van Hasselt, K. Huijzendveld, N. Noort, S. de Ruijter, T. Islam, and I. Malavolta, “Comparing the energy efficiency of webassembly and javascript in web applications on android mobile devices,” in Proceedings of the 26th International Conference on Evaluation and Assessment in Software Engineering, EASE ’22, (New York, NY, USA), pp. 140–149, Association for Computing Machinery, 2022. [12] Z. Wang, J. Wang, Z. Wang, and Y. Hu, “Characterization and implication of edge webassembly runtimes,” in 2021 IEEE 23rd Int Conf on High Performance Computing & Communications; 7th Int Conf on Data Science &

Preprint – Kirin: Cloud-native WebAssembly Service Orchestration

8

power measurements,” ACM Transactions on ModelSystems; 19th Int Conf on Smart City; 7th Int Conf on Deing and Performance Evaluation of Computing Systems pendability in Sensor, Cloud & Big Data Systems & Ap(TOMPECS), vol. 3, no. 2, pp. 1–26, 2018. plication (HPCC/DSS/SmartCity/DependSys), pp. 71–80, 2021. [25] S. Luo, H. Xu, K. Ye, G. Xu, L. Zhang, G. Yang, and C. Xu, “The power of prediction: Microservice auto scal[13] V. Kjorveziroski and S. Filiposka, “Webassembly as an ing via workload learning,” in Proceedings of the ACM enabler for next generation serverless computing,” JourSymposium on Cloud Computing, 2022. nal of Grid Computing, vol. 21, no. 3, 2023. [14] S. Shillaker and P. Pietzuch, “Faasm: Lightweight isolation for efficient stateful serverless computing,” in 2020 USENIX Annual Technical Conference (USENIX ATC 20), pp. 419–433, 2020. [15] S. Kang, M. Song, T. Kim, S. Lee, J. Han, H. Kim, and K. Lee, “Hybridserve: Adaptive webassembly-container runtime selection for edge serverless computing,” in Proceedings of the 11th International Workshop on Serverless Computing, pp. 1–6, 2025. [16] S. Kakati and M. Brorsson, “The small container: Lightweight compute for multi-architecture cloud-edge systems,” SN Computer Science, vol. 6, no. 8, p. 1023, 2025. [17] M. R. López and J. Spillner, “Towards quantifiable boundaries for elastic horizontal scaling of microservices,” in Proceedings of the 10th IEEE/ACM International Conference on Utility and Cloud Computing Companion, UCC ’17 Companion, (New York, NY, USA), pp. 35–40, Association for Computing Machinery, 2017. [18] M. Warade, K. Lee, C. Ranaweera, and J.-G. Schneider, “Monitoring the energy consumption of docker containers,” in 2023 IEEE 47th Annual Computers, Software, and Applications Conference (COMPSAC), pp. 1703–1710, 2023. [19] A. Hall and U. Ramachandran, “A hybrid runtime for function-as-a-service at the edge,” in Proceedings of the 26th International Middleware Conference, p. 469–481, 2025. [20] M. Nurul-Hoque and K. A. Harras, “Nomad: Crossplatform computational offloading and migration in femtoclouds using webassembly,” in 2021 IEEE International Conference on Cloud Engineering (IC2E), pp. 168–178, 2021. [21] S. Kakati and M. Brorsson, “An investigative study of webassembly performance in cloud-to-edge,” in 2024 International Symposium on Parallel Computing and Distributed Systems (PCDS), pp. 1–5, 2024. [22] H. Xu and F. Kjolstad, “Copy-and-patch compilation: a fast compilation algorithm for high-level languages and bytecode,” Proc. ACM Program. Lang., vol. 5, Oct. 2021. [23] R. Bertran, M. Gonzalez, X. Martorell, N. Navarro, and E. Ayguade, “Decomposable and responsive power models for multicore processors using performance counters,” in Proceedings of the 24th ACM International Conference on Supercomputing, ICS ’10, (New York, NY, USA), pp. 147–158, Association for Computing Machinery, 2010. [24] K. N. Khan, M. Hirki, T. Niemi, J. K. Nurminen, and Z. Ou, “Rapl in action: Experiences in using rapl for

Related documents

• Kirin: Cloud-native WebAssembly Service Orchestration#1144598
• Sarus Suite: Cloud-native Containers for HPC#120483
• A Forensic Study of Artifact Persistence in Containerd-Based Kubernetes WorkloadsWhitepaperDigital Forensics and Incident Response12 May 2026#175105
• A Virtual Processor brings back the Free Lunch#246543
• OpenDT: Exploring Datacenter Performance and Sustainability with a Self-Calibrating Digital Twin#10309