Short comparison: Building Graal Native Images with Quarkus, Micronaut and Helidon

The technological innovations of the last years such as the adoption of containers, cloud-native technologies, the microservice architectural style, the inception of GraalVM and the end of JavaEE (as we know it) has energized the Java framework market.

As of May 2019, there are at least three frameworks supporting GraalVM native images out of the box, targeting cloud-native microservices:

• Quarkus,
• Micronaut and
• Helidon.

As building GraalVM native images is a bit challenging, I was curious to find out how these three frameworks keep up with their promises. I worked through the respective getting started guides and wrote down some similarities and differences resulting in this short (and surely incomplete) comparison of the three frameworks. See the following table for an overview.

General comparison

	Quarkus	Micronaut	Helidon
Core Project Source	quarkusio/quarkus	micronaut-projects/micronaut-core	oracle/helidon
Website	quarkus.io	micronaut.io	helidon.io
Started/Backed By	RedHat	objectcomputing	Oracle
First Commit	2018-06-22	2017-03-06	2018-08-28
GitHub Stars (05/2019)	1693	2283	1371
GitHub Contributers (05/2019)	88	120	26
# Commits (05/2019)	3970	5907	617
Supported languages	Java, Kotlin	Java, Groovy, Kotlin	Java
Supported build tools	mvn, Gradle	mvn, Gradle	mvn
Supported APIs for graal native	Microprofile, vert.x,	Micronaut, ReactiveX/RxJava	Helidon SE (Microprofile, without native image)
Programming paradigms for graal native	Imperative, reactive	Reactive, imperative?	Reactive (imperative, without native image)
Code generation via	mvn plugin	CLI (mn)	mvn archetype
Getting Started (Graal native)	Guide	Docs	Blog
Resulting src of Getting Started	schnatterer/quarkus-getting-started	schnatterer/micronaut-getting-started	schnatterer/helidon-getting-started
Size of getting started docker image
Getting started base docker image	fedora-minimal	alpine-glibc	scratch
Getting started uses native image?	N	N	Y
Size of getting started in scratch docker image

All three projects are rather young (grandpa Micronaut is about 2 years old as of 05/2019) but have what looks like extensive documentation at first glance. The only thing that made my stumble a bit was that Helidon’s docs don’t return a result for “graal”. I later found a brand new getting started with graal on oracle’s developers blog. Hopefully, this will be added to the docs soon.

There are a couple of notable differences between the three frameworks:

• • Programming style (reactive vs. imperative)
    • Quarkus explicitly supports both (reactive as an extension),
    • Helidon claims to support both, but only reactive in conjunction with native images right now
    • Micronaut is reactive only From the docs it seems that micronaut focuses on reactive, but blocking approaches are supported (see Graeme Rocher’s comment).
  • Language
    • Micronaut and Quarkus both support Java and Kotlin.
      Micronaut also supports Groovy 🎉 (having Graeme Rocher, the creator of Grails, on board it’s probably a must)
    • Helidon only supports Java
  • Build tool / code generation
    • Micronaut and Quarkus support Maven and Gradle.
      • Quarkus uses a Maven plugin for code generation (bad luck for Gradle users) whereas
      • Micronaut brings its own CLI tool that thankfully can easily be installed using sdkman.
    • Helidon supports only Maven and has only initial code generation support via a Maven archetype.
  • Kubernetes
    • Helidon is the only one to feature Kubernetes resources as part of the getting started, making the first deployment really easy.
    • Quarkus Maven plugin features a generator for kubernetes resources
  • Community
    Hard to tell. The amount of discussions on my tweet about Quarkus makes me think they’re the ones that are most interested in feedback and people getting involved.

GraalVM native Image / Docker Image

• The Dockerfiles provided by the getting started of Quarkus and Micronaut each require an external Maven build.
  The images base on fedora-minimal (resulting in a 44MB compressed image) or alpine-glibc (resulting in a 32MB compressed image) respectively.
  A base image containing a libc is required because the native image is linked dynamically.
• Helidon provides a proper self-contained Dockerfile that can be built by simply calling docker build, not requiring anything locally (except Docker, of course).
  Here, the native image is linked statically. Therefore the binary can run in an empty scratch image (resulting in an 8MB compressed image).

Bearing in mind that a Java 8 JRE Image requires about 100MB (debian) or 50 MB (alpine), 44MB or even 32MB for a small webapp is not so bad. OTOH the 8 MB for the statically linked image are a real revelation, leaving me stunned.

The fact that Helidon plays well with GraalVM shouldn’t be too surprising, as they both are official Oracle products.

Beyond getting started

As Quarkus was the first framework I tried, I wondered why they rely on fedora and not just compile a static binary (later, I learned about some of their reasons on twitter). So I tried a couple of other images, eventually setting the switch for creating a static binary and using a scratch image. Voilà: It results in a 7MB image, even a wee bit smaller than the Helidon one. See the table bellow for an overview of images and their features and sizes (taken from the README of my getting started repo).

Base Image	Size	Shell	Package Manager	libc	Basic Linux Folders	Static Binary	Dockerfile
fedora		☒	☒	☒	☒	☐	📄
debian		☒	☒	☒	☒	☐	📄
alpine-glibc		☒	☒	☒	☒	☐	📄
distroless-base		☐	☐	☒	☒	☒	📄
busybox		☒	☐	☒	☒	☒	📄
distroless-static		☐	☐	☐	☒	☒	📄
scratch		☐	☐	☐	☐	☒	📄

I applied more or less the same on Micronaut. Here, the scratch image is only 5 MB smaller than the alpine one – 27 MB. This is not too surprising, because the plain alpine-glibc image is only about 6MB. It also felt like the native image generation took longer and needed more memory (observed with docker stats).

As for Helidon’s self-contained, scratch image containing only a static binary, there was not much to be done. I only extend the Dockerfile by a maven cache stage for faster Docker builds.

There’s one last thing I changed in all Dockerfiles: Don’t run as root. I used the USER statement in the Dockerfile. docker run -u ... would also be fine. This way, it’s much more unlikely that possible vulnerabilities (such as CVE-2019-5736 in runc) are exploited.

So summing up: Quarkus and Helidon can be used to create really small docker images, Micronauts are “only” small 😉. It’s worth mentioning that I didn’t look what features are included in those images, so maybe it’s a bit naive to just compare the minimal sizes resulting from the individual getting started guides.

Going even further

If I were to continue my comparison at this point (which I won’t because it’s only a short comparison) I would look into the following features of each framework:

• integration and unit testing,
• extensions (e.g. Cloud Native features, Tracing, Monitoring, etc.)

Summary

So, for a new green field project, which one of e frameworks would I use?

As far as I can tell after completing the getting started, all three look promising. As for all architectural decisions, I’d definitely try to build a walking skeleton (technical roundtrip) before finally deciding, in order to gain more field experience and find out what’s beyond getting started.

I’d base this decision on the experience or preferences of the team

• reactive vs. imperative
• Maven vs. Gradle
• Java vs. Kotlin (or even groovy)
• APIs – Microprofile, vert.x, RxJava

Personally, I like the fact that Quarkus builds on existing APIs such as Microprofile, so existing experience can be reused for faster results. It also seems to me the most flexible of the three, supporting Java, Kotlin, Maven, Gradle, reactive and imperative.

As for native images, I’d definitely either try it from the beginning or stick to a regular JRE. I suppose switching from plain JRE-based to native could be complicated for an existing app, due to the native image limitations. If the app under development does not have the requirement to be scaled horizontally, this could be an argument for skipping the native image part. But this is beyond the scope of this article.

As for the docker image – it’s obviously not only the size that matters. An image without shell and package manager is always more secure but harder to debug.

 

Edits:

• 2019/05/17: John Clingan pointed out that Quarkus supports Kubernetes resource generation an multiple reactive extensions
• 2019/05/19: As commentef by Graeme Rocher’s, Micronaut also supports blocking workloads

Advertisement