I have been playing with serverless solutions lately. It started with a Django project that was dealing with customer AWS credentials both in background and foreground tasks. I wanted to keep those tasks compartmentalized for security and I wanted them to scale easily. Celery is the common solution for this, but setting it up in my environment was not straightforward. This was as good excuse as any to AWS Lambda. I gave Serverless Framework a try because it was the most versatile framework I could find with proper Python support.
It worked well for a long time. But over time I noticed the following repeating issues.
- It requires Node.js which complicated development and CI environments. This is the reason I originally created docker combo images of Python and Node.js.
- Packaging Python dependencies is slow and error prone. Every deployment operation downloaded all the dependencies again, compressed them again, and uploaded them again. On Windows, Mac, and some Linux variants (if you have binary dependencies) it requires Docker and even after multiple PRs it was still slow and randomly broke every few releases.
- There was no easy way to directly call Lambda functions after they were deployed. I had to deal with the AWS API, naming, arguments marshaling, and exception handling myself.
To solve these issues, I created Lovage. The pandemic gave me the time I needed to refine and release it.
No Node.js
Lovage is a stand-alone Python library. It has no external dependencies which should make it easy to use anywhere Python 3 can be used. It also does away with the Node.js choice of keeping intermediate files in the source folder. No huge node_modules folders, no code zip files in .serverless, and no dependency caches.
Lambda Layers
Instead of uploading all of the project’s dependencies every time as part of the source code zip, Lovage uploads it just once as a separate zip file and creates a Lambda Layer from it. Layers can be attached to any Lambda function and are meant to easily share code or data between different functions.
Since dependencies change much less frequently than the source code itself, Lovage uploads the dependencies much less frequently and thus saves compression and upload time. Dependencies are usually bigger than the source code so this makes a significant difference in deployment time.
But why stop there? Lovage gets rid of the need for Docker too. Docker is used to get an environment close enough to the execution environment of Lambda so that pip downloads the right dependencies, especially when binaries are involved. Why emulate when we can use the real thing?
Lovage creates a special Lambda function that uses pip to download your project’s dependencies, package them up, and upload them to S3 where they can be used as a layer. That function is then used as a custom resource in CloudFormation to automatically create the dependencies zip file and create a layer from it. Nothing happens locally and the upload is as fast possible given that it stays in one region of the AWS network.
Here is a stripped down CloudFormation template showing this method (full function code):
Resources:
RequirementsLayer:
Type: AWS::Lambda::LayerVersion
Properties:
Content:
S3Bucket:
Fn::Sub: ${RequirementsPackage.Bucket}
S3Key:
Fn::Sub: ${RequirementsPackage.Key}
RequirementsPackage:
Type: Custom::RequirementsLayerPackage
Properties:
Requirements:
- requests
- pytest
ServiceToken: !Sub ${RequirementsPackager.Arn}
RequirementsPackager:
Type: AWS::Lambda::Function
Properties:
Runtime: python3.7
Handler: index.handler
Code:
ZipFile: |
import os
import zipfile
import boto3
import cfnresponse
def handler(event, context):
if event["RequestType"] in ["Create", "Update"]:
requirements = event["ResourceProperties"]["Requirements"]
os.system(f"pip install -t /tmp/python --progress-bar off {requirements}"):
with zipfile.ZipFile("/tmp/python.zip", "w") as z:
for root, folders, files in os.walk("/tmp/python"):
for f in files:
local_path = os.path.join(root, f)
zip_path = os.path.relpath(local_path, "/tmp")
z.write(local_path, zip_path, zipfile.ZIP_DEFLATED)
boto3.client("s3").upload_file("/tmp/python.zip", "lovage-bucket", "reqs.zip")
cfnresponse.send(event, context, cfnresponse.SUCCESS, {"Bucket": "lovage-bucket, "Key": "reqs.zip"}, "reqs")
This is by far my favorite part of Lovage and why I really wanted to create this library in the first place. I think it’s much cleaner and faster than the current solutions. This is especially true considering almost every project I have uses boto3 and that alone is around 45MB uncompressed and 6MB compressed. Compressing and uploading it every single time makes fast iteration harder.
“RPC”
Most serverless solutions I’ve seen focus on HTTP APIs. Serverless Framework does have support for scheduling and events, but still no easy way to call the function yourself with some parameters. Lovage functions are defined in your code with a special decorator, just like Celery. You can then invoke them with any parameters and Lovage will take care of everything, including passing back any exceptions.
import lovage
app = lovage.Lovage()
@app.task
def hello(x):
return f"hello {x} world!"
if __name__ == "__main__":
print(hello.invoke("lovage"))
hello.invoke_async("async")
The implementation is all very standard. Arguments are marshaled with pickle, encoded as base85, and stuffed in JSON. Same goes for return values and exceptions.
Summary
Lovage deploys Python functions to AWS Lambda that can be easily invoked just like any other function. It does away with Docker and Node.js. It saves you development time by offloading dependency installation to Lambda and stores dependencies in Lambda layers to reduce repetition.
I hope you find this library useful! If you want more details on the layer and custom resource to implement in other frameworks, let me know.
Today I will tell you about the massive success that is 
kichik's blog 