- Article
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.
Appl. Sci.
12 September 2026


![System architecture of the experimental environment. Framework pods run inside a bare-metal K3s cluster with resource limits of 1 GiB and 1 CPU core. cAdvisor exposes container metrics to Prometheus via HTTP scraping; Kubernetes lifecycle timestamps are queried through the API server. Measurement scripts orchestrate deployment lifecycle events via kubectl and collect aggregated results in CSV/JSON format. Controlled variables: the framework configuration (eight levels, Table 1) is the only manipulated factor, while the resource profile (requests of 512 MiB memory and 500 millicores, limits of 1 GiB memory and 1000 millicores), the shared Kafka broker and PostgreSQL instance, the container runtime, the kernel, and the image-cache state are held constant across all configurations. Measured indicators: container_memory_working_set_bytes and container_memory_rss in MiB, rate (container_cpu_usage_seconds_total [1 m]) in cores, and the PodScheduled-to-Ready interval in seconds. Collection cycle: Prometheus 2.48.0 scrapes the kubelet cAdvisor endpoint at a 5 s scrape interval with a matching 5 s evaluation interval and a 7-day retention window; series are restricted at scrape time to the measurement namespace and to non-empty container labels, and CPU is averaged over a one-minute rate window at query time, so each reported CPU value summarizes twelve scrapes. Kubernetes lifecycle transitions are observed on a watch stream and timestamped locally at millisecond resolution. No arrow enters a framework pod from the monitoring stack, which denotes that no value reported in this study originates from application-level instrumentation.](https://mdpi-res.com/cdn-cgi/image/width=470%2Cheight=317/https://mdpi-res.com/applsci/applsci-16-09069/article_deploy/html/images/applsci-16-09069-g001-550.jpg)




![Schematic diagram of the MCr unit used: (A) membrane module, (B) peristaltic pump; (C) feed tank and (D) permeate tank (adapted from [22]).](https://mdpi-res.com/cdn-cgi/image/width=281%2Cheight=192/https://mdpi-res.com/applsci/applsci-16-07136/article_deploy/html/images/applsci-16-07136-g001-550.jpg)




