Early Thoughts: Quarkus / GraalVM

Containerization has become very important in recent years.  Starting about 4 years ago, jobs I've had went from no containerization in local data centers to running dockerized images in a cloud such as AWS or Azure. Initially this was just using docker directly on a cloud server.  Over time, the work has gradually migrated more towards Kubernetes though.

There are a lot of lessons learned and a few still being learned. One area of continued learning is in the area of cost. It is so easy to spend big $ in any cloud environment. The choices we make in the tech stack and architecrual areas has a huge impact on final costs.  

Native serverless solutions can become cost prohibitive when the call rate is extremely high. Slow virtual server startups means you must over-provision more initially to prevent lag time issues with auto-scaling. Fat dockerized images eat up memory typically requiring larger underlying hardware to provide additinal memory.  High initial docker container processing results in further over-provisioning to compensate for lag-time. Choices in runtime/language affect memory requirements as well.

With that said, I've been starting to toy with some relatively new technologies in the bits of spare time I have at home - Quarkus (https://quarkus.io/) which also integrates with GraalVM (https://www.graalvm.org/).

The ability to create an optimized container from Java microservice code which prunes out unused functionality and converts to a native application has some benefits.  The biggest touted benefit appears to be lower memory requirements for the deployed container and startup speed but I also think it might help improve security overall - needs some research.

My initial work with Quarkus (non-native, just local images) has been pretty straight forward. I am able to work with it from Eclipse without significant issues.  I wil say that memory requirments tend be excessive for the build process (especially native application image). Without limiting memory, it consumed too much and caused system instability and trying to tweak the memory setting for the build itself is a bit of art.  Here is a snipped of the out of memory failure with 5Gb dedicated.

[INFO] [io.quarkus.deployment.pkg.steps.NativeImageBuildStep] Running Quarkus native-image plugin on GraalVM Version 19.3.1 CE[INFO] [io.quarkus.deployment.pkg.steps.NativeImageBuildStep]...
[notesvc-quarkus-1.0.0-SNAPSHOT-runner:24] Exception in thread "ForkJoinPool-2-worker-9" java.lang.OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects
Fatal error: Exception in thread "main" java.lang.OutOfMemoryError: Java heap spaceError: Image build request failed with exit status 1

Once I bumped the setting in the POM file to 6Gb and reran build it succeeded.  Here is the profile that worked:

   <profile>

      <id>native</id>

      <activation>

        <property>

          <name>native</name>

        </property>

      </activation>   

      <build>

        <plugins>

          <plugin>

            <artifactId>maven-failsafe-plugin</artifactId>

            <version>${surefire-plugin.version}</version>

            <executions>

              <execution>

                <goals>

                  <goal>integration-test</goal>

                  <goal>verify</goal>

                </goals>

                <configuration>

                  <systemProperties>

                    <native.image.path>${project.build.directory}/${project.build.finalName}-runner</native.image.path>

                  </systemProperties>

                </configuration>

              </execution>

            </executions>

          </plugin>

        </plugins>

      </build>

      <properties>

        <quarkus.package.type>native</quarkus.package.type>

        <quarkus.native.additional-build-args>-J-Xmx6G</quarkus.native.additional-build-args>

      </properties>

    </profile>

The startup time does appear significantly faster on first tests.  I'll come back and add some of those details soon (hopefully).

Hope your day is blessed!
Scott