Open-sourcing the AWS Java Runtime Interface Client

At re:Invent 2020 a new packaging format for AWS Lambda functions was introduced; container images. With this functionality came a number of managed base images that customers can use too. They are patched and maintained by AWS and include functionality to simplify running your functions in a container image.

So what is that functionality? It’s an implementation of the Lambda runtime API. This isn’t just for containers, it’s just that with the introduction of this feature, the runtime API has a lot more visibility. You could always use this API to run other languages such as PHP or R.

So let's dive a little deeper and look at what was open-sourced and why it’s important to developers and builders.

Firstly there is the aws-lambda-java-runtime-interface-client (RIC) this is the implementation of the polling client which asks for the next invocation to execute. In a managed environment it knows which handler to execute through the configuration you’ve given. With container packaging, you can specify the handler in the CMD. The RIC uses a native binding to use CURL to make the required API calls. This reduces the latency compared to Java HTTP clients. It also handles all of the weird and wonderful ways in which a customer’s function can error and handles them gracefully.

By open-sourcing this library, AWS has shared a battle-hardened, highly optimized component for others to use. Digging deeper into the RIC, it actually helps even more. Lambda functions are triggered by a vast variety of different event sources, created by different AWS teams. They all produce their events differently and the Lambda service has to handle these. For the Java managed runtime additional work is done to make sure that these events are presented in the best way possible for developers in the form of the aws-lambda-java-events library. Java POJOs for most of the event sources are included. Occasionally there is clean up required to make these event sources match typical Java naming standards. This work is done in the aws-lambda-java-serialization library.

This behind the scenes transform has caused confusion in the past when developers have been writing unit tests for their functions. They would make an event with certain conditions and then fire it through the handler and assert certain reactions. The problems came when the events weren’t transformed by the tests, leading to a serialization error. Open sourcing the serialization library made unit testing much simpler and easier with the introduction of the aws-lambda-java-tests. It includes support for any required serialization of your events and handy ways to load your test events from files.

My hope is that other open-source frameworks such as Quarkus, Micronaut and Spring Native will use these libraries to improve their own Lambda functionality. I also hope that it will drive new innovation in this area.