Lightweight Java Part II — Quarkus

Author
Jason Feng, DigIO

If you haven’t read Part I, which includes a brief introduction to GraalVM and Spring Native, please have a read here

Introducing Quarkus

Quarkus, from Red Hat, is another popular option in the market when working on GraalVM native image. It’s a Kubernetes-native framework, optimised for a serverless environment. It’s designed to work with popular Java standards, frameworks and libraries, like Spring, MicroProfile, Vert.x, JAX-RS, Kafka and more. It offers fast startup time, low memory consumption, improved Java app performance and increased developer productivity.

Here is an example Quarkus application:

A Handler implements the AWS RequestHandler

Build a native image with the custom runtime. In order to have the native executable able to run on the AWS custom runtime, the application must build within the same OS. This can be achieved by building the project in a docker image with Amazon Linux 2 as the OS and Graalvm(Gradle/Maven etc) installed. Here is the docker image.

Deployment package. As per AWS documentation, the deployment package requires both a bootstrap file that lambda runs and the executable. Here is a sample of bootstrap

Trigger of Lambda function. Here we have an API Gateway with a custom domain(optional) that trigger the lambda function.

The application will take a while to build and deploy to AWS. Grab a ☕️ , sit back and relax. Once the build and deployment are finished, you should be able to see the URL as the output. Let’s, again, perform a quick HTTP request to both the standard Java and Quarkus lambda. The difference, as expected, is gigantic. For lambda code start, it’s 1.65s vs 15.2s, lambda warmed up is 737ms vs 1.28s.