Empirical Static and Infrastructure Evaluation of Microservice Frameworks Across JVM, GraalVM Native Image, and Rust in Containerized Environments
Abstract
Framework and runtime selection for containerized microservices are usually guided by request-level benchmarks, yet deployment-facing costs often dominate operational expenditure in Kubernetes environments. This study empirically evaluates four such infrastructure characteristics: container image size, startup time, idle resource consumption, and horizontal scaling latency. Eight microservice framework configurations spanning three execution models are evaluated: JVM (Spring Boot, Spring WebFlux, Quarkus, and Ktor), GraalVM Native image (Quarkus variants, including distroless and UPX-compressed images), and Rust (Actix Web). All metrics are collected technology-agnostically at the container level via cAdvisor and Kubernetes lifecycle events. Three trade-off profiles emerged during the research: Rust achieves a 2.95 MiB idle memory footprint (a 69:1 ratio versus Spring Boot on a working-set basis, or 21:1 on the more conservative proportional-set-size basis) through garbage-collector-free memory management. GraalVM Native image variants start 1.2–1.7× faster and consume up to 1.9× less memory than their JVM equivalents, although this memory advantage is not uniform: the standard reactive Native image consumes more idle memory (115.0 MiB) than the corresponding JVM variant (98.0 MiB). A UPX compression paradox is identified and explained at the kernel level: compression shrinks images by approximately 2.5:1 yet inflates idle memory to 215–229 MiB, above JVM baselines, because decompression into private anonymous memory defeats shared page mapping. Scale-up latency (1.8–3.9 s) is governed by per-instance startup rather than framework-exclusive lifecycle optimizations, partially refuting one of four research hypotheses. The findings yield context-dependent selection guidance and a fully reproducible benchmark suite. All measurements were obtained on a single-node bare-metal K3s cluster, the primary metrics characterize the idle state of a minimal no-operation service, and the only load applied is a single fixed-rate validity check at 100 requests per second. The reported values therefore constitute lower-bound, deployment-facing infrastructure costs rather than predictions of behavior under production business workloads, multi-node topologies, or managed cloud substrates.