AWS Lambda is Amazon’s very own reliable event-driven and serverless compute service.

AWS Lambda is quite good at what it is meant for, i.e. building serverless micro-applications. Having said that, we should be cognizant of the fact that this is what Lambda is supposed to do. To adhere to the Lambda philosophy, AWS poses certain limitations on how lambda is supposed to be used.

While working with AWS Lambda, we should be aware of these constraints and limits. For example, while working with huge machine learning and artificial intelligence libraries like Tensorflow, one constraint is the deployment package limit in Lambda.
We should also be aware that if such situations arise, there are ways of overcoming these limitations. Below mentioned are some of the widely known limitations that exist in AWS

Frameworks such as serverless and Zappa create a compressed zip to upload, but If we are not using any such external libraries, we will end up with a compressed zip file which we would have to upload to lambda. Now we need to bear in mind that the limit for a compressed zip/jar is 50 MB.

In such cases, an option would be to let lambda pull the package directly from S3. For this, we need to create an S3 bucket and upload the zip to the bucket. We need to specify the S3 bucket and the zip file’s object key to update the lambda code and this will work perfectly fine for zips/jars up to 250 MB.

The deployment limits the size of code/dependencies that you can zip into a deployment package in lambda is 250 MB, which means that the deployment of any package that exceeds this limit will still be rejected.

These options are provided by the ‘serverless-python-requirements’ plugin which, as the name suggests, can be used when deploying Python lambdas.
In the serverless.yml file, we can add these options to get everything down to size.
– Slim – Removes unneeded files such as *.pyc, *.so, dist-info from the package.
– Zip – Zip compresses the libraries into a .zip file and uploads that instead of the actual libraries. It also adds an unzip_requirements.py in the bundle. We would need to add the following four lines in the code:
try:

import unzip_requirements

except for ImportError:

pass

These lines will unzip the requirements on lambda.
– noDeploy – The libraries added under the noDeploy option in the serverless.yml file will be omitted from the deployment.

The /tmp directory on lambda can be used to store up to 512MB of data. A workaround incorporating this is to zip the libraries and include them in the deployment package while unzipping them into the /tmp directory which has a directory storage limit of 512 MB, slightly larger than the usual 250 MB limit.

The ideal solution is the one that adheres to the Lambda philosophy of short-lived micro functions. If it is possible to break the large function with all the libraries into multiple smaller functions which make sense when being viewed in isolation, we should do it. We can either have a common handler that can trigger these functions in succession, or we can utilize the methods using which we can trigger an external lambda function from a running lambda.

As is with everything, lambda has its strengths and limitations. The limitations are a part of what lambda stands for and its inherent nature. If serverless is what we endure, we need to learn to embrace lambda’s limitations. For exceptional situations, there are always workarounds as mentioned.