loading...

Discussion on: Troubleshooting binaries in AWS Lambda

Collapse
metaskills profile image
Ken Collins

Thanks for the write up. Did you consider using the AWS SAM/LambCI "build" variant containers to avoid installing developer tools? Everyone has this and it follows the "lambci/lambda:build-" naming convention. SAM uses these build variants too. I make heavy use of them not only for layers building (github.com/customink/ruby-vips-lambda) but for local development/test too.

Also, have you seen Michael Hart's yumda project (github.com/lambci/yumda) on LambCI? In some cases it can be useful. I tend to put layer building into 3 buckets.

  1. Dont use a layer. Build the package for the target. Examples in Node are Sharp.JS. In ruby, here is a MySQL2 gem for Lambda. I think this is the best option for common things.
  2. Highly optimized libs, headers, shared object, etc for a specific package using Lambda Layers. Packages are different. Sometime they need to compile or link to things differently. The Ruby libvips link is a good example of this.
  3. Fat Lambda layer using something like Yumda.

Hope that helps!

Collapse
a0viedo profile image
Alejandro Oviedo Author

Thanks for reading! I did knew the build images from lambci but wanted to illustrate that for some cases you won't get all the necessary tools and that you could still craft your way into a build image that suits your needs.

It's the first time I read about yumda but sounds exactly what I was after originally. I had a similar experience with what you mention about not using layers for code, it was kind of a pain and limits your tree-shaking possibilities in real world projects. It's a super interesting conversation on when it's worth to use a layer and I think binaries are one of those use-cases.