You own a Spring Boot service moving to native images. How do you structure the Maven native build in CI/CD, and what are the operational tradeoffs?

## Framing the decision Native image is an architectural tradeoff, not a free win. The Maven tooling (`native-maven-plugin` + Spring Boot's `native` profile) is easy to invoke; the hard part is the operational envelope. As the owner I'd design the pipeline and rollout around the constraints. ## Pipeline structure 1. **Fast lane (every push):** ordinary `mvn verify` on a JVM — unit/integration tests, static analysis. This is where developers get feedback in seconds/minutes. 2. **Native lane (separate stage/job):** `mvn -Pnative native:compile` (or `spring-boot:build-image` for an OCI image) on a **GraalVM JDK**. This runs on beefier runners (native-image is CPU- and RAM-intensive) and is gated to PR/merge/release rather than every commit. 3. **Native tests:** `mvn -PnativeTest test` runs the test suite *as a native image*, which is the only reliable way to catch missing reflection/resource metadata before production. Non-negotiable before shipping a native artifact. 4. **Release build:** full optimization (`-O3`, optionally PGO: instrument → run representative load → rebuild with `.iprof`; and `--gc=G1` on Oracle GraalVM), arch-pinned (`-march=compatibility` or a specific supported arch), metadata repo version **pinned** for reproducibility. ## Build environment concerns - **Toolchain:** must be a GraalVM JDK with `native-image`. Standardize the exact distribution/version across dev and CI. - **Target platform:** the binary is OS+arch specific. Build inside a container matching production (usually Linux x86_64/aarch64). Buildpacks (`spring-boot:build-image`) conveniently produce a Linux container even from macOS/Windows dev machines. - **Minimal images:** consider `--static --libc=musl` to land on `scratch`/distroless for tiny, low-attack-surface containers. - **Reproducibility:** pin `metadataRepository` version (or mirror it), pin the GraalVM version, and avoid `-march=native`. - **Resource budget:** native-image can need several GB of builder heap; size runners accordingly and cache dependencies. Builds of minutes are normal. ## Operational tradeoffs (the real interview content) **Wins:** - **Startup:** tens of ms vs seconds — enables scale-to-zero, FaaS, fast autoscaling and rollouts. - **Memory:** much smaller RSS — cheaper per-instance, higher density. - **Security/footprint:** smaller, static binaries; no full JDK in the image. **Costs / risks:** - **Build time & cost:** minutes-long, RAM-heavy builds slow the pipeline; you can't native-build on every commit cheaply. - **Peak throughput:** AOT lacks the JIT's runtime profiling, so long-running high-throughput services can be *slower* than the JVM (PGO narrows but doesn't always close the gap). - **Closed-world constraints:** reflection/resources/proxies must be known at build time; dynamic class loading and some libraries/agents don't work. - **Observability:** no `-agentlib` attach, JFR/JMX support is limited/evolving, heap dumps and profilers differ — incident tooling changes. - **Debuggability:** stack behavior and native debugging differ from the JVM; reproducing prod issues locally is harder. ## Rollout strategy - Keep a **JVM deployment as fallback** and run native in parallel (canary) until soak tests validate latency, memory, and correctness. - Add **native smoke/soak tests** hitting real endpoints, since some failures only manifest at runtime under real traffic (missing hints on rare code paths). - Track a **metadata-coverage checklist** for third-party libs; own a process for contributing/overriding reachability metadata. - Decide per-service: native suits **short-lived, latency-sensitive, scale-to-zero** workloads; the JVM often stays better for **steady high-throughput** services. ## Summary judgment Adopt native where startup/memory dominate the cost model and the dependency set is native-friendly; keep the JVM path alive, isolate the slow native build in CI, test natively, and pin everything for reproducibility. The plugin is trivial; the discipline around it is the job.