@dannyfreeman Rich has stated that they are working on an update to Ions where Lambdas are not used as API-GW connective tissue i.e. no more VPC cold starts. Also, at ClojuTre one of the talks was about Graal and, while it speeds up start-time, it has approx 50% perf compared with jvm Clojure in Hotspot. For that reason, I’m not sure that Graal will be the long term solution to our performance concerns
I was unaware of the performance of graal @steveb8n. That’s unfortunate. For similar reasons, clojurescript in lambdas isn’t a good solution for some users either. Cold starts are improved but in the long term they don’t perform as well compared to the JVM.
I don’t think there’s been any mention of it in this room, but we released a brand new direct Clojure API to AWS this week (does not go through the Java SDK) for all AWS services
I think it is a high-quality piece of work and if you need to access AWS you should check it out
since it’s generated, it already contains all the new services that were released at reinvent last week, for example
Oh... I feel my approach of autogenerating interfaces from the SDK definition JSONs in https://github.com/polymeris/cljs-aws validated if cognitect does the same, otoh makes me realize I should have taken the concept further!
Any plans of adding cljs support?
feel free to file a github issue
has been explored, I’m not sure of the details
@dannyfreeman also relevant is that 50% of cold-start time is caused by VPC ENI init, so any process running in a VPC will suffer it. I’ve got some cljs lambdas outside of a VPC and they cold-start in 3 secs but they really need the VPC goodness too
3 seconds seems like a little much for a cljs lambda. You mean clj?
CLJS/node lambdas created using shadow. it has the aws js api deps so maybe that’s why 3 secs. either way, 3 secs is not too bad for my users. 10-20 for jvm lambdas in VPC is unacceptable so I’m looking forward to the new Ions feature which sounds like it will address this