I'm curious on folks thoughts about AWS new <lambd...
# server
t
I'm curious on folks thoughts about AWS new lambda snapstart feature, which I'm excited about. It allows for the full cold start (including any "static" init) to be snapshotted and restored, drastically reducing cold start. It seems like a great win for JVM based AWS microservices. I've tried in out in with a small test case (using cloudformation), and it seems to live up to it's promises so far. It has a few caveats, but they don't seem like big issues for most use cases. It does require using Lambda versioning/alias, but that is pretty much abstracted away with cloudformation AutoPublishAlias. Example someone has posted: https://serverlessland.com/patterns/apigw-lambda-snapstart Thread in Slack Conversation
a
Interesting! I've been tackling this issue from the opposite direction: by eliminating reflection and bloated dependencies such as jackson and log4j. This might be an interesting supplement to help bring back more choices.
d
We're actively looking at confirming that http4k support for snapstart in Lambda won't involve any changes. We already have support for standard JVM, the custom http4k Runtime and GraaalVM versions so we envisage no problems at all. It's all pretty exciting tbh. One thing to consider is that the cost of lambda invocation is still basically
memory x time
, so if you've got heavyweight ZIP files or frameworks then that will still cost. (http4k of course is super lightweight so we hope snapstart will continue to give us an edge in this 😉 )
❤️ 1
Jackson was one of the reasons we built out own runtime - we use Moshi with compile time generated adapters - which also allows for zero configuration conversion to graalvm. (The Amazon sdk is also a bit of a sticking point if you decide to use it instead of something more lightweight)
a
Very cool! AWS Lambda support in http4k is amazing, basically just one line. If only Amazon would release a Java 17 runtime... 😩
d
@andyg you should be able to easily use the http4k custom runtime with or without going to graalvm. The latest version of the JVM is based on Corretto and java 11/17/19. https://github.com/http4k/docker-images/tree/master/amazoncorretto-lambda-runtime
Images are in DockerHub: https://hub.docker.com/r/http4k/
So you have runtime options of: • AWS runtime with jvm • Http4k custom runtime with jvm • Http4k custom runtime with graalvm the problem we've found with the first one is that that one relies on (a re-jarred) Jackson mapper inside their runtime. This has a penalty on startup. The http4k AWS custom runtime is just another backend, which you can convert your app to (
app.asServer(AwsLambdaRuntime())
) and stick it inside a main. So this means it's trivial to test your entire app locally as well, as outside the runtime requests are just http - so you can just run them in the normal way. The http4k AWS adapter layer handles the transition between the AWS JSON format and standard http. https://github.com/http4k/http4k/blob/master/http4k-serverless/lambda-runtime/src/main/kotlin/org/http4k/serverless/AwsLambdaRuntime.kt
I should probably do a talk on this stuff. 🤣
a
I'm aware of some non-AWS custom runtimes supporting JVM 17+ ( https://sigpwned.com/2022/07/23/aws-lambda-base-images-for-java-17/), although I did not know http4k had built one. My assumption was that you'd have to package the application as a Docker container to use these. Is that not the case?
d
For the http4k lambda tutorials, we package them as a ZIP file.
Copy code
Your custom runtime runs in the standard Lambda execution environment. It can be a shell script, a script in a language that's included in Amazon Linux, or a binary executable file that's compiled in Amazon Linux.
https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html
In pulumi, we specify this with:
Copy code
const lambdaFunction = new aws.lambda.Function("hello-http4k", {
    code: new pulumi.asset.FileArchive("HelloHttp4k.zip"),
    handler: "unused",
    role: defaultRole.arn,
    runtime: "provided.al2"
});
although actually you might be right that you need Docker if you want to use something with Java in it as opposed to GraalVM...... 🤔