Add layer support

[mrhornsby]

Hi @tmokmss,

Thanks for creating this construct, it's much appreciated.

Have you considered supporting packaging the LLRT runtime as a layer? It seems like the performance penalty is pretty minimal according to this article and I think it would be nice option to have where someone has lots of LLRT based functions.

I'm going to take a shot at making this work, if I'm successful then please let me know if you'd like me to make a PR.

Regards

Mark

[mrhornsby]

I have a version here where testing works locally but I've got an error in my build action that I'm investigating.

Mark

[mrhornsby]

I have this fully working now. Please let me know if you'd accept a PR.

Thanks

Mark

[tmokmss]

Hi @mrhornsby, thank you for the request! I'd like to confirm, what is the motivation to use Lambda layer for this purpose? Is it to reduce code storage (75GB soft limit)?

[mrhornsby]

Hi @tmokmss, the code storage limit isn't really a concern, it's more the need to upload the assets with each build. Most of my lambdas are no more than 100-200kb but adding in the LLRT runtime increases this 10-20x fold. My intention is to keep the lambda bundle nice and small which is particularly helpful when iterating on a particular function or in a continuous integration environment where we deploy / re-deploy all the lambdas regularly while the runtime layer won't change often. Mark

[tmokmss]

@mrhornsby Thanks for the clarification! I basically agree with the idea, but let me think about it some more 🙏
Given that the LLRT binary is only a few MB, is it really that much of a problem? I'm still not sure whether it's worth the additional complexity of the Lambda layer. Could you provide some concrete metrics on the improvements to your use case?

[mrhornsby]

It really comes down to your network speed. The average UK upload speed is about 18 Mbps so this equates to a saving of 1-2 seconds per lambda (depending on which SDK type it uses). I'll publish a forked package for now and gather some more real world data.

[mrhornsby]

Hi @tmokmss, I've been using my fork for the last few days and real world testing matches up to my calculations above. I built an example stack with 10 lambdas (I have work with projects with as many as 70 lambdas) and deployment without the layer took between 66 and 75 seconds. The same stack with the layer took between 41 and 46 seconds. This was all tested with a network upload speed of 18 Mbps. Let me know if you've had any more thoughts about possibly merging this in. Thanks.

[tmokmss]

@mrhornsby Cool! And there is no degradation on the cold start time?

[mrhornsby]

In my limited testing I'm not seeing any appreciable difference although I've not done the same level of testing as they did in the article. Given that the feature can be enabled lambda by lambda the user should be able to decide if the improved deployment time is beneficial in their use case?

[tmokmss]

Sounds great! Yes, I'll review your PR 🙏

[mrhornsby]

Thanks @tmokmss, I've opened the PR, I'll close this issue as we can continue any discussion there 🙏

[tmokmss]

Let's close this after the PR is merged 👍