Deploying a Camel Route in AWS Lambda using Quarkus

Do you fancy running camel route as functions in AWS Lambda. Well I did a small Proof Of Concept to test this and the results were interesting. Thanks to the Quarkus and Camel-Quarkus communities for their efforts to make this technically possible.

You can find the working sample in the Camel Quarkus Examples github repo

#Deploying a Camel Route in AWS Lambda : A Camel Quarkus example

This project uses the following framework

Quarkus - The Supersonic Subatomic Java Framework for building Cloud Native Applications
Apache Camel - The Swiss Army Knife of Enterprise Application Integration for integrating heterogeneous systems
AWS Lambda - Event-driven, serverless computing platform provided by Amazon as a part of Amazon Web Services

Provided Code

Quarkus Camel Amazon Lambda Integration example

This example contains a sample Greeter service build using Quarkus & Camel framework implementing Dependency Injection design principle which can be deployed as functions into the Amazon Lambda.

:warning: INCOMPATIBLE WITH DEV MODE: Amazon Lambda Binding is not compatible with dev mode yet!

Quarkus Extensions / Dependencies Used

Apache Camel
- camel-quarkus-core
- camel-quarkus-direct
- camel-quarkus-log
- camel-quarkus-bean
Quarkus
- quarkus-amazon-lambda
Testing
- quarkus-junit5
- quarkus-junit5-mockito
- quarkus-test-amazon-lambda

Running the application in dev mode

You can run your application in dev mode that enables live coding using:

./mvnw compile quarkus:dev

NOTE: Quarkus now ships with a Dev UI, which is available in dev mode only at http://localhost:8080/q/dev/.

Building and Packaging the Java code as Quarkus JVM application

The application can be packaged using:

./mvnw clean package

This will compile and package your code.

It produces the quarkus-run.jar file in the target/quarkus-app/ directory. Be aware that it’s not an uber-jar as the dependencies are copied into the target/quarkus-app/lib/ directory.

If you want to build an uber-jar, execute the following command:

./mvnw package -Dquarkus.package.type=uber-jar

The application is now runnable using java -jar target/quarkus-app/quarkus-run.jar.

It also generates a zip file target/function.zip. This zip file contains your java code along with the dependencies.

##Building and Packaging the Java code as Quarkus Native executable

If you want a lower memory footprint and faster initialization times for your lambda, you can compile your Java code to a native executable. Just make sure to rebuild your project with the -Pnative switch.

:warning: Building Native Executables will take much longer time and depends on the underlying system

./mvnw package -Pnative

:information_source: If you are building on a non-Linux system Or, if you don’t have GraalVM installed, you can run the native executable build using docker container. You need to pass in a property instructing quarkus to use a docker build as Amazon Lambda requires linux binaries. You can do this by passing this property to your Maven build: -Dquarkus.native.container-build=true. However, This requires to have docker installed locally.

./mvnw package -Pnative -Dquarkus.native.container-build=true

Either of these commands will compile and create a native executable image. You can then execute your native executable with: ./target/code-with-quarkus-1.0.0-SNAPSHOT-runner

It also generates a zip file target/function.zip. This zip file contains your native executable image renamed to bootstrap. This is a requirement of the AWS Lambda Custom (Provided) Runtime.

If you want to learn more about building native executables, please consult https://quarkus.io/guides/maven-tooling.html.

Extra Build Generated Files

NOTE: After you run the build, there are a few extra files generated by the quarkus-amazon-lambda extension. These files are in the build directory: target/

function.zip - lambda deployment file
manage.sh - wrapper around aws lambda cli calls
bootstrap-example.sh - example bootstrap script for native deployments
sam.jvm.yaml - (optional) for use with sam cli and local testing
sam.native.yaml - (optional) for use with sam cli and native local testing

Please click here to know more on how to use these scripts for automated deployment

Deploying the Quarkus JVM application to AWS Lambda via AWS Web Console

Go to AWS Web console and search for Lambda Service
Click Create Function and select Author From Scratch
Give the name for your function which should be unique
Select Java 11 (Corretto) as Runtime
Under Permission feel free to create / use existing role to give the required permission for your lambda function
Once the function is created click the function name to upload the generated function.zip file and configure it.
Scroll down and select the Code tab. Click the upload from dropdown on right hand side of the screen and select .zip or .jar file
Click upload and browse to the path where the generated zip file is created target/function.zip and select the function.zip file and click save
Under the Code tab scroll down to the Runtime settings and click edit
For the Handler details please provide the Quarkus Handler

io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler::handleRequest

Testing the AWS Lamda Function

Now select the Test tab for executing a quick test. Copy paste the below json payload and hit Test
```
{
 "name": "Ravishankar"
}
```
If everything goes fine you should get the below response along with the lambda execution logs & stats
```
Hello Ravishankar ! How are you? from GreetService
```

Deploying the Quarkus Native executable to AWS Lambda via AWS Web Console

NOTE: Please ensure that you have built your Java code as Quarkus Native executable

Go to AWS Web console and search for Lambda Service
Click Create Function and select Author From Scratch
Give the name for your function which should be unique
For Runtime please scroll down and Select Provide your own bootstrap on Amazon Linux 2 under Custom Runtime
Under Permission feel free to create / use existing role to give the required permission for your lambda function
Once the function is created click the function name to upload the generated function.zip file and configure it.
Scroll down and select the Code tab. Click the upload from dropdown on right hand side of the screen and select .zip or .jar file
Click upload and browse to the path where the generated a zip file is created target/function.zip and select the function.zip file and click save
Under the Code tab scroll down to the Runtime settings and click edit
For the Handler details please provide the below Handler
```
    not.used.in.provided.runtime
```
Then Select the Configuration tab and click Environment Variables
For Key enter DISABLE_SIGNAL_HANDLERS & for Value enter true

Testing the AWS Lamda Function

Now select the Test tab for executing a quick test. Copy paste the below json payload and hit Test
```
{
 "name": "Ravishankar"
}
```
If everything goes fine you should get the below response along with the lambda execution logs & stats
```
Hello Ravishankar ! How are you? from GreetService
```

JVM vs Native : Results based on lambda execution logs & stats

JVM vs Native Results

The above table is populated based on the execution stats provided in the AWS Lamda Logs

Based on the data captured sharing few comments:

It’s interesting to see that native uses less memory than JVM which might reduce the cost in running AWS Lambda
The execution time seems faster in native mode from 2nd to 5th invocations, it would be interesting to see if this trend continues on subsequent calls as the JIT compiler might kick in.
It’s clear that the init duration is by magnitude faster in native mode. However, I am curious to see that for the first call the total billed duration includes the Init duration in native mode where as in JVM mode, Init duration is ignored in the total billed duration. Not sure, If this is a billing issue in AWS or a feature provided by AWS for executing Java runtime in Lambda ?