Introduction

In the part 1 of the series we gave an introduction to the GraalVM and especially its Native Image capabilities. We also explained its benefits for the Serverless applications. In the this part of the series we'll explain how to develop and deploy AWS Lambda function with custom runtime containing GraalVM Native Image.

Sample Application

For the sake of explanation we'll use our sample application. In this application we'll create and retrieve products and use DynamoDB as the NoSQL database. We'll re-use the application introduced in the article Measuring Java 21 Lambda cold starts and adjust it to be deployed as Lambda Custom Runtime containing GraalVM Native Image.

General Setup

In order to build GraalVM Native Image we'll need to do the following:

• Setup m5.large AWS Cloud9 EC2 instance. You can of course use your own (local) Linux environment.
• Install SDKMAN

curl -s "https://get.sdkman.io" | bash  

source "/home/ec2-user/.sdkman/bin/sdkman-init.sh"

• Install the latest GraalVM version. I used version 22 in my example (but you can use the newest one):

sdk install java 22.0.1-graal  (or use the newest GraalVM version)

• Install Native Image

sudo yum install gcc glibc-devel zlib-devel 
sudo dnf install gcc glibc-devel zlib-devel libstdc++-static

• Install Maven capable of building with the installed GraalVM version. We need Maven version capable of dealing with the Java 21 and higher version of the source code. For example :

wget https://mirrors.estointernet.in/apache/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz tar -xvf apache-maven-3.8.5-bin.tar.gz sudo mv apache-maven-3.8.5 /opt/

M2_HOME='/opt/apache-maven-3.8.5' 

PATH="$M2_HOME/bin:$PATH" 

export PATH

If this mirror becomes unavailable, please use another one available for your operating system.

Making sample application GraalVM Native Image capable

In order to our sample application to run as GraalVM Native Image we need to declare all classes which objects will be instantiated per reflection. These classes needed to be known by AOT compiler at compile time. This happens in reflect.json. As we can see we need to declare there

• all our Lambda functions like GetProductByIdHandler and CreateProductHandler
• entities like Product and Products that will be converted from JSON payload and back
• APIGatewayProxyRequestEvent and all its inner classes because we declared this event type as request event in our Lambda functions like GetProductByIdHandler and CreateProductHandler
• org.joda.time.DateTime which will be used to convert timestamp as from String and back which is a part of the APIGateway proxy request and response events

In order to avoid errors with Loggers during the initialization described in the article Class Initialization in Native Image we need to add GraalVM Native Image build arguments in the native-image.properties.

Args=--allow-incomplete-classpath \
    --initialize-at-build-time=org.slf4j.simple.SimpleLogger,\
      org.slf4j.LoggerFactory
    -- --trace-class-initialization=org.slf4j.simple.SimpleLogger,\
      org.slf4j.LoggerFactory

The native-image.properties should be placed in the META-INF/native-image/${MavenGroupIid}/${MavenArtifactId}

As we use slf4j-simple Logger in pom.xml we need to place native-image.properties in the path META-INF/native-image/org.slf4j/slf4j-simple.

Lambda Custom Runtime

In order to deploy the Lambda function as custom runtime we need to package everything into the file with .zip extension which includes the file with the name bootstrap. This file can either be the GraalVM Native Image in our case or contain instructions how to invoke GraalVM Native Image placed in another file. Let's explore it.

Building GraalVM Native Image

We'll build GraalVM Native image automatically in the package phase defined in the pom.xml. The relevant part is defined in the following plugin:

<plugin>
      <groupId>org.graalvm.nativeimage</groupId>
      <artifactId>native-image-maven-plugin</artifactId>
      <version>21.2.0</version>
      <executions>
            <execution>
                  <goals>
                        <goal>native-image</goal>
                  </goals>
                  <phase>package</phase>
            </execution>
      </executions>
      <configuration>
            <skip>false</skip>
            <mainClass>com.formkiq.lambda.runtime.graalvm.LambdaRuntime</mainClass>
            <imageName>aws-pure-lambda-java21-graalvm-native-image</imageName>
            <buildArgs>
                  --no-fallback
                  --enable-http
                  -H:ReflectionConfigurationFiles=../src/main/reflect.json
                </buildArgs>
      </configuration>
</plugin>

We use native-image-maven-plugin from org.graalvm.nativeimage tools and execute native-image in the package phase. This plugin requires the definition of the main class which Lambda function doesn't have. That's why we use Lambda Runtime GraalVM and define its main class com.formkiq.lambda.runtime.graalvm.LambdaRuntime. Lambda Runtime GraalVM is a Java library that makes it easy to convert AWS Lambda written in Java programming language to the GraalVM. We defined it previously in pom.xml as dependency

<dependency>
   <groupId>com.formkiq</groupId>
   <artifactId>lambda-runtime-graalvm</artifactId>
   <version>2.3.1</version>
</dependency>

We then give the native image name aws-pure-lambda-java21-graalvm-native-image and include some GraalVM Native Image arguments and previously defined reflect.json.

  <buildArgs>
    --no-fallback
    --enable-http
    -H:ReflectionConfigurationFiles=../src/main/reflect.json
 </buildArgs>

In order to zip the built GraalVM Native Image as function.zip required by Lambda Custom Runtime we use the maven-assembly plugin:

<plugin>
      <artifactId>maven-assembly-plugin</artifactId>
      <executions>
            <execution>
                  <id>native-zip</id>
                  <phase>package</phase>
                  <goals>
                        <goal>single</goal>
                  </goals>
                  <inherited>false</inherited>
            </execution>
      </executions>
      <configuration>
            <finalName>function</finalName>
            <descriptors>
                  <descriptor>src/assembly/native.xml</descriptor>
            </descriptors>
      </configuration>
</plugin>

The finalName we define as function and id as native-zip We also include native.xml assembly. This assembly defines file format as zip (the complete file name will be ${finalName}-${id}.zip, in our case function-native-zip.zip), adds the previously built GraalVM Native Image with the name aws-pure-lambda-java21-graalvm-native-image and adds the already defined bootstrap which basically invoked the GraalVM Native Image :

#!/bin/sh

cd ${LAMBDA_TASK_ROOT:-.}

./aws-pure-lambda-java21-graalvm-native-image 

In the end we have to build GraalVM Native Image packaged as a zip file which can be deployed as Lambda Custom Runtime with :

mvn clean package

Deploying GraalVM Native Image as a Lambda Custom Runtime

In the AWS SAM template we the Lambda runtime as provided.al2023, which is the newest version of the custom runtime) and provide the path to the previously built GraalVM Native Image function-native-zip.zip.

Globals:
  Function:
    CodeUri: target/function-native-zip.zip
    Runtime: provided.al2023

Now we are ready to deploy our application with

sam deploy -g

Conclusion

In this part of the series, we explained how to develop and deploy AWS Lambda function with custom runtime containing GraalVM Native Image. In the next part of the series we'll measure the cold and warm start times of the Lambda function for such scenario for different memory settings of the Lambda function.