Lambda is a 100% no operations, compute service which can run application code using AWS infrastructure. The service performs all the operational and administrative activities on your behalf, including capacity provisioning, monitoring fleet health, applying security patches to the underlying compute resources, deploying your code, running a web service front end, and monitoring and logging your code. Some could say this is so far no different from any other Platform as a Service (PaaS) offering, but there are some key differentiators comparing to traditional PaaS.
Just like other public cloud services, Lambda has “pay as you go (PAYG)” pricing model with a generous free tier, and it is one of the most appealing for cost savings. Lambda billing is based on used memory, number of requests and execution duration rounded up to the nearest 100 milliseconds. This is a huge leap for fine grained billing in order not to pay for spare compute resources comparing to the hourly based billing of EC2.
While most of the PaaS offerings are designed to be running 24/7, Lambda is completely event driven, it will only run when invoked. This is perfect for application services having quiet periods followed by peaks in traffic.
When it comes to scalability, Lambda can instantly scale up to a large number of parallel executions, for which the limit is controlled by the Number of concurrent requests. Downscaling is handled simply by automatically terminating the Lambda function execution when do code finishes running.
Lambda comes with native support for a number of programming languages: Java, NodeJS and Python. There are additional open source frameworks for more supported languages, rapid development and deployments, like Serverless (formerly knows as JAWS), Apex, Sparta to name a few.
General Lambda use cases
1. Operating serverless websites
This is one of the killer use cases to take advantage of the pricing model of Lambda, and S3 hosted static websites. Consider hosting the web frontend on S3, and accelerating content delivery with Cloudfront caching. The web frontend can send requests to Lambda functions via API Gateway HTTPS endpoints. Lambda can handle the application logic, and persist data to a fully managed database service (RDS for relational, or DynamoDB for non relational database). You can host your Lambda functions and databases within a VPC to isolate them from other networks. As for Lambda, API Gateway and S3, you pay only after the traffic incurred, the only fixed cost will be running the database service.
2. Log analysis on the fly
You can easily build a Lambda function to check log files from Cloudtrail or Cloudwatch. Lambda can search in the logs looking for specific events or log entries as they occur and send out notifications via SNS. You can also easily implement custom notification hooks to Slack, Zendesk, or other systems by calling their API endpoint within Lambda.
3. Automated backups and everyday tasks
Scheduled Lambda events are great for housekeeping within the AWS accounts. Creating backups, checking for idle resources, generating reports and other tasks which frequently occur can be implemented in no time using the boto3 Python libraries.
4. Processing uploaded S3 objects
By using S3 object event notifications, you can immediately start processing your files by Lambda, once they land in S3 buckets. Image thumbnail generation by Lambda is a great example for this use case, so the solution will be cost effective and you don’t need to worry about scaling up — Lambda will handle any load!
5. Filtering and transforming data on the fly
Because Lambda is highly scalable, it is great for transitioning data between S3, Redshift, Kinesis and database services, and filtering on the fly. You can easily place Lambda in between services to transform and load data as required.
Limitations
Lambda comes with a number of “limitations”, which is good to keep in mind when architecting a solution.
There are some “hard limitations” for the runtime environment: the disk space is limited to 512 MB, memory can vary from 128 to 1536 MB and the execution timeout for a function is maximised in 5 minutes. Package constraints like size of deployment package and number of file descriptors are also defined as hard limits.
Similarly, there are “limitations” for the requests served by Lambda: request and response body payload size is maximised in 6 MB while event request body can be 128 KB. At the moment, the only soft “limitation”, which you can request to be increased, is the number of concurrent executions, which is a safety feature to prevent any accidental recursive or infinite loops go wild in the code. This would throttle the number of parallel executions.
You may be wondering why I keep quoting the word “limitation” — because really these are not limitations, but well defined architectural principles for the Lambda service:
If your Lambda function would be running for hours, it should rather go to Beanstalk or EC2 than Lambda.
If the deployment package jar is larger than 50 MB, it should be broken down to multiple packages and functions.
If the requests payloads exceeds the limits, you should break them up into multiple request endpoints.
It all comes down to prevent deploying monolithic applications as Lambda functions, and serve stateless microservices as a collection of functions instead. Having this mindset, the “limitations” make complete sense.
Lambda is one of the versatile tools in the AWS ecosystem and can be used for many use cases. However, as controlling a powerful highly scalable service, things can go horribly wrong if functions not implemented well, so always make sure you have architected and tested thoroughly before publishing your functions live.