4 ms·

Awesome. Our "Distributed Monolith" problems are now solved. We have so many Lambdas that share common Java JAR libs. Lambda Layers appears to solve our reuse

• teej 8y ago
  Lambda Layers fixes so many problems! * We had to hack around Lambda zip size limits. Now we can deploy fat dependencies to Layers and ditch the hacks. * We can drastically speed up build and packaging time locally by keeping fat dependencies in Layers. * We use a shared in-house library to wrap all code that lives in a Lambda. Updating the version of this required us to deploy every single Lambda that used it. Now it can live in one place. * We can eliminate repeated deployment pain for Python code with C dependencies by deploying the manylinux wheel to Layers. Now devs can go back to just packaging up pure Python and not worry about cross-platform problems. And probably loads more I'm not thinking of.
  • spullara 8y ago
    Lambda zip size limits are still strongly in force. All your layers and your lambda code still much be < 50MB zipped / 250MB unzipped total.
    • freedomben 8y ago
      Are you sure? I've been seeing conflicting information regarding that, but can't find the authoritative answer from Amazon
      • teej 8y ago
        spullara is right, I am wrong - > The overall, uncompressed size of function and layers is subject to the usual unzipped deployment package size limit. https://aws.amazon.com/blogs/aws/new-for-aws-lambda-use-any-programming-language-and-share-common-components/ https://aws.amazon.com/blogs/aws/new-for-aws-lambda-use-any-...
  • matharmin 8y ago
    Only uncompressed size (250MB) really matters. You could always work around the compressed limits (50MB) by uploading to S3 first, instead of deploying the ZIP directly.