Would there be much interest in a #serverless channel? I've often wondered if Ktor could compile to Javascript to run on AWS Lambda...

It doesn’t get much traffic, but you might check out #kotless

Yeah, I keep checking #kotless for updates, but the project seems to be moribund.

Java is a Lambda target too.

Sure, I do have some stuff running on Kotlin jvm lamba. I guess I need to check out graalvm though. Helps with the cold start problem, I've heard.

Liam this is a very interesting topic, I have been working in the last couple of years pretty intensively with AWS Lambda and at the very beginning I tried to use Kotlin. Even worked on this library: https://github.com/SuprGames/serverless-kdsl-generator

You may consider #http4k - it has tutorials on running in AWS Lambda and also with graal. https://www.http4k.org/guide/tutorials/going_native_with_graal_on_aws_lambda/

Http4k does seem to be the most cloud - aware Kotlin framework under active development. But I'll need to learn pulumi or Terraform to make it work, I fear.

well, yes to a certain extent, but you can get it going by copying the examples - don't need to learn much to get the "hello world" examples going. you'll need one of those to do serverless in any case, most likely.

I'd be super curious about Ktor start times in native mode. I've been trying to run a simple Spring Boot Kotlin server in GCP AppEngine free tier (256MB RAM + autoscaling) and it's been challenging to say the least

Different technologies will give you vastly different start times - even without throwing serverless idiosyncracies into the equation. They can range from a few milliseconds in technology A to many tens of seconds for technology B for equivalent real-world apps, both kotlin, both JVM.

Cold start is still an overall problem for JVM AWS lambda, but the package size and choice of serialisation tech will also have an effect - which is why we generally look at using Moshi/kotshi instead of Jackson and reflection. Jackson alone takes a while to instantiate - and with the kotlin reflect jar as well you're adding a decent chunk to the size as well. The funny thing is that even node lambdas suffer - you don't see it in the hello world benchmarks, but add a few npm dependencies and the overall size immediately starts to bloat... As a reference on size, a JVM http4k lambda with moshi we expect 8-12mb and graalvm makes that up to 30mb (but you also get the speed boost). IMHO attempting to configure GraalVM at all is a nightmare - with http4k and the graalvm lambda runtime you can sidestep that entirely (as long as you choose your other dependencies wisely 😉).

a JVM http4k lambda with moshi we expect 8-12mb and graalvm makes that up to 30mb

@dave this is the size of the binary, right? (8-12 mb for .jar and 30 mb for graalvm executable?) Do have any rough idea how that translates into runtime RAM usage?

Ah - well that is an interesting question! Because the max memory setting also contributes to the performance of the lambda call! So although an http4k JVM lambda will run with 100-150mb ram (80mb for Graal) you might want to up the max memory to get better performance (Also - to answer your question - yes - that is the total zip file size you upload.)

Thanks for the insight!

You're welcome. 🙃. I should also say that http4k on lambda is absolutely a proven technology that has been used in production systems. and it has the advantage that for us, Serverless is merely another backend, so you can seamlessly switch between - say- in memory testing, local server, fargate and lambda with zero code changes to your app.

Just did a little test of infrastructure deployment using Pulumi, written in Java. Goodness, that framework needs a nice Kotlin DSL. It's all Java Builder classes just now and felt very clunky.

Yeah - we use the Typescript version for precisely that reason...

Just checked Terraform cdktf... Not much better.

yes - they are all pretty bad (the java versions) 😂

I think I'll just ignore multi cloud and just write for AWS. It's only a personal project anyway.