Stepping back from bad decisions and wrong assumptions.

[FieryCod]

HL currently supports deployment/management via wrapped AWS SAM template. The current approach where HL controls the stack seems sufficient for small apps, but the configuration is complex and not so Clojure'y. It's also hard for me to guarantee 100% feature parity with AWS SAM. Now, HL stack management and deployment are useless since different users prefer different tools.

Some users prefer AWS SAM (without any wrapping), some others Terraform, CDK or Pulumi. There are also different ways to package the code, and HL only utilizes zip which one more time is great for simple apps, but what if the user wants to call some native commands from AWS Lambda?

These concerns made me realize that I was trying to pursue a toolset that nobody wants to use in its exact form. HL will be much more minimal and trimmed from features which makes the maintenance and development hard.

What then Holy Lambda should be?

• Core as just a library that exposes simple and efficient custom runtime, supporting Clojure, Babashka, Clojurescript, and GraalVM compiled Clojure. HL drops the support for Java-based runtime. That means runtime will be faster (from 8s cold start on Java-based runtime to 1s Clojure on Clojure)
• Basic bb tasks that build the artifact and help with reflection/resource trimming for GraalVM. No bucket creation, no AWS SAM wrapping, no managing of the stack.

What the future brings:

• Java runtime will be obsolete, and its dependencies removed. Instead, one can just compile the Clojure code wrapped with fierycod.holy-lambda/entrypoint and build a deployable Docker image. This will be known as a :clojure runtime.

• HL bb tasks will no longer provide the following commands: bb stack:invoke, bb stack:pack, bb stack:deploy, bb stack:destroy, bb stack:logs, bb stack:describe, bb stack:api

• HL bb tasks will provide only limited set of functionalities

  • bb hl:sync (renamed from bb stack:sync)
  • bb hl:compile (renamed from bb stack:compile) - just compiles sources to .jar file. If you use :clojure you don't need HL shipped bb tasks
  • bb hl:native:conf (renamed from bb native:conf)
  • bb hl:native:executable (renamed from bb native:executable)
  • bb hl:clean (renamed from bb stack:purge) - removes builds

• User decides how the code is packaged, which means that HL will no longer deploy Babashka runtime for you.

  Clojure runtime

  • bb hl:compile - will create a .holy-lambda/build/latest-clojure.jar. For Clojure runtime the only sensible option is Docker.

  Native runtime

  • bb hl:native:executable - will create a .holy-lambda/build/latest-native.zip, with resources packed. You can of course unpack the .zip, and pack the bootstrap + binary with Docker if you would like to add some more dependencies :)

  Babashka runtime

  • Sources are provided as is, therefore you have to either deploy the runtime on your AWS account, reference it as a layer, include the source and set the Entrypoint variable which points to namespace in which native/entrypoint function is used. (eg. native/entrypoint in namespace com.company.example then Entrypoint variable should be com.company.example) (zip)
  • bb hl:init will download a layer as a .zip to .holy-lambda/layers/babashka-runtime.zip. Unpack the layer and put the content in docker image + add your code (docker)

[superstructor]

First, thanks for Holy Lambda @FieryCod. Its great!

I've found the existing bb tasks extremely helpful; esp bb stack:invoke for rapid testing of changes.

For the bb tasks that are being removed could that be provided as an additional project if it is no longer going to be part of the core ? I had a look at the implementation of holy-lambda-babashka-tasks and would not really like to re-create all of that in our own codebase when using HL.

Also, what is the difference between the existing Java runtime and a :clojure runtime ?

[FieryCod]

Hi @superstructor! Thank you for raising these questions.

BB deployment tasks

bb tasks code is complicated because I have tried hard to glue AWS sam with mentioned above runtimes so that users at any time may change the runtime and cross invoke. As said bb tasks wrap the AWS SAM and the only downsides of the changes I have in mind are:

1. You would have to use the official sam tool which has more functionalities than bb tasks and supports a variety of deployment strategies, which HL could not ever support.
2. Cross invoke between runtimes will not be supported. You would need two templates: one for native and one for java if you would like to test the code on Clojure on Clojure runtime.

I think that there are better ways to test the code than using plain bb stack:invoke or sam invoke e.g look here

There will be no continuation of the deprecated commands. All of the commands will be removed in the next release. But do not worry, since SAM will serve you well, so no worry. If you would need my help with migration to AWS SAM I'm always on the #holy-lambda channel keen to help :)

You can still use current bb tasks with new releases of holy-lambda. The only thing that will not work is targeting the :java runtime.

Rapid testing
I do believe that we can do better in that area. Not only for the small API apps but for some bigger applications that utilize the whole spectrum of AWS tools: SQS, Polly, S3, etc.

Small apps
The first step would be to fix the interceptors to match the pedestal model. This will allow me to write a simple interceptor that can proxy AWS messages to ring applications, so that simple API apps are supported. That way you can freely develop API the same as you do with Ring, and responses will be automatically converted to match the API Gateway model when running on AWS Lambda.

Complex apps
The architecture similar to this: https://docs.serverless-stack.com/live-lambda-development
Here is the discussion: #63

I will describe Clojure runtime in a separate message :)

[stevebuik]

Likewise, thanks for such a valuable toolset.

I think this general idea is good. I only use the tasks that create latest.zip and nothing else i.e. don't use any of the cloudformation/stack generation/deploy tasks.

You could still provide sample stacks in an example projects. This could be CDK, Terraform etc.

the reason I use this lib is 1/ cold starts and 2/ ease of CI graal automation

on that basis, for me, the :clojure runtime is less interesting, unless its cold starts are comparable.
I'd be interested to see some measurements of cold starts (with a few real-world libs) comparing native vs clojure.

the other direction of interest for me would be cljs (with npm deps) running in graal. is that possible to be to AOT'd so that it has similar benefits as jvm clojure?

[FieryCod]

You could still provide sample stacks in an example projects. This could be CDK, Terraform etc.

That's the plan. Make HL more composable and well documented, let people decide what they want to use. You remember how many questions you had about whether it's possible to use a different deployment strategy. It was a valuable lesson to me. I'm also a less SAM user right now, so I don't feel opinionated on using only AWS SAM right now.

Clojure runtime
I will answer in a separate message :D

Real-world benchmarks
For now, I'm doing some base benchmarks which only test the speed of the runtime. I will post the results when I finish. I would love to add more benchmarks, but it's not a top priority for me now. However, if any of the users would like to add some "Real example" code for benchmarks I would be more than grateful. :)

Benchmarks could be found here: https://github.com/FieryCod/holy-lambda/tree/benchmarks/benchmarks/hello

the other direction of interest for me would be cljs (with npm deps) running in graal. is that possible to be to AOT'd so that it has similar benefits as jvm clojure?

I'm not sure I follow what you are asking. HL will support Clojurescript runtime when I sort all the top priority issues, but if you are thinking about using :native runtime with Javascript/Clojurescript, then it's certainly possible. Just google GraalVM Polyglot. GraalVM compiled Clojure will be as fast as it's now when using with Polyglot AFAIK.

You should definitely read this: https://nextjournal.com/kommen/react-server-side-rendering-with-graalvm-for-clojure
I didn't try it myself, but I suspect that you would have to build a Docker image out of latest.zip that includes graaljs and the dependencies. Since AWS Lambda supports Docker Images I don't think that there is anything which may stop you from making this happen.

[FieryCod]

@superstructor @stevebuik
From the beginning, HL supported the official AWS Java runtime. Java runtime does its things for plain Java, but it's not well suitable for Clojure. There is much reflection going on under the hood, and classes are initialized in ways I don't really understand. The cold start of the Clojure function on Java runtime is quite high because it's around 8s and memory usage is huge (2 GB of memory at least). I have never tried to use custom runtime for this because I had a feeling that the results will be comparable with Java runtime.

After talking with Ghadi I have tried to just call Clojure functions on the custom runtime, and the results of local invoke are quite good 800ms cold start and 128MB usage. I have added an example of Clojure on Clojure to benchmarks, so I will post all the results when I finish.

Clojure on Clojure utilizes the same custom runtime the native is already using. The difference is that the Clojure runtime is running on the JVM, whereas the native runtime is running on SubstrateVM. Here are the changes: e0f37dc

Custom runtime implementation has not been changed. Custom runtime for Clojure is the same as it's for native :)
EDIT: I had to add a small change for Docker-based images so that one can pass the handler name to the main function:
2f2a895#diff-4c5cb53178e0b11ad73e2bb64f11e5ab7e0ab24693fb1c15a93ee0838caa5883R76

[FieryCod]

All the necessary changes to stabilize the project landed in release 0.6.0. Locking the discussion.