[jmlucjav]

Issues I saw (it was months ago, maybe now it's better):

- was not clear what was the limit on the total size, I think it was supposed to be 50mb, but it was not exact.

- edit the lambda function code, and wait 10 min till it is uploaded by the eclipse plugin

- finally not being able to attach a debugger

On the plus side, once you had all up and running, I agree it worked nicely. I complain about the developer experience only.

[namero999]

I just finished today to extract a module of my monolith to AWS Lambda in Java. I loved the experience, but first I had to configure a CI in AWS so that the build and deployment cycle was fast.

Since my function needs phantomjs, I embedded the binaries into the deployment package and by just doing that I topped up 36 MB of the 50 allowed. Transferring it from my local regular internet was a pain. Now it's nice, I push code to my dev branch, it gets picked up by the CI, tested, built and deployed. I get a notification in the IDE when the whole roundtrip is done, and with the CI in AWS it takes seconds instead of minutes. Without binaries you can still fit jackson, a few AWS clients, groovy runtime, guava and httpclient in a few megs, which is manageable.

I agree about the debugger, but authoring a function is trivial and unit tests can be written and run without considering Lambda. I miss tailing logs, CloudWatch is nice but it's far from realtime.

[djhworld]

I believe the limitation is 50mb compressed/250mb uncompressed. I've never deployed a Java Lambda that's bigger than 20mb though so I've not hit that limitation.

I'll admit that on slow internet connections, uploading a JAR to deploy can be a bit slow though. We have a Jenkins CI build pipeline that automates this process, it builds the JAR (running unit tests etc), then uploads it to S3 and uses AWS Cloudformation to make the Lambda point to the new JAR in S3.