After Years of Developing Lambda Scripts from creating Serverless Applications to Pipelining your Tasks, Here are the Best Practices that we follow.
Using AWS Lambda Environment Variables:
AWS Environment Variables like your system environment variables, make it available to your Script during RUN-time, So we can use the AWS Lambda Environment Variables for defining variables like s3-bucket names, RDS or even your application keys. This also gives us flexibility to copy the script to extend it in other use cases and functions.
Initializing the functions inside Lambda Handler:
Often, while developing serverless Applications, we tend to pre-initialize everything in beginning and then use if-else conditions to choose the outcome based on input. To reduce your Application Run-time, pre-initialize only necessary packages in beginning and other package, before invoking your functions.
Less Run-time == Lower AWS Bill
Keeping your AWS Lambda Function smaller, might sound a bit tedious work to maintain, but on the positive note, it helps you understand and analyze your lambda run-times and bottlenecks. Sometimes with AWS Lambda Limits in place, breaking down your bigger function to smaller pieces and invoking them accordingly, will keep your lambda function failure due to TimeOut or Disk space errors(limit on /tmp).
Lambda Metrics and Cloudwatch Alarms:
Being a Pessimist prepare you to handle the Worst Scenarios. Configure as many Alarms and Metrics possible, so when in dire-situations where your script is not functioning as it should, you can debug your errors quickly.
Limited Retries to Mitigate DDOS:
Often when developing Lambda Functions, people either not use retries at all or leave them to run eternally[although Lambda timeout kicks in and stops execution]. But since lambda functions can be directly invoked in few cases like API Gateway or Amazon Lex. Be sure to optimize your retries according to prevent DDOS and Hefty AWS Bill due to the attacks.
AWS Lambda Function Versioning and Aliases:
Versioning is immutable, so version your lambda function frequently, so you can rollback to any previous Versions quickly and switch between different aliases like prod, dev etc.,
Lambda has an concurrency limit of 1000 per region (can be extended through support). Sometimes, when both your application and Lambda is using Same RDS and due to lack of planning, we might reach the Database Connection Limits, So Always be sure to set a limit on concurrency appropriately, to not pile up your tasks queue or create database errors.
Although not everything, this should give you a fair head-start in developing and maintaining your lambda code.
Django-CRM :Customer relationship management based on Django
Django-blog-it : django blog with complete customization and ready to use with one click installer Edit
Django-webpacker : A django compressor tool
Django-MFA : Multi Factor Authentication
Docker-box : Web Interface to manage full blown docker containers and imagesMore...