This post was written by Rich Bosomworth.
The term serverless refers to a model of cloud compute that runs code in response to events. AWS Lambda is currently the more popular choice of serverless technology against competing offerings such as IBM OpenWhisk or Azure Functions.
This post is aimed at those familiar with AWS who may already have a basic Lambda implementation in place. We list options for event triggers and discuss configuration considerations when working with Lambda functions.
Comprehensive documentation is available here for those interested in a full introduction to the service.
Extended Event Triggers
The selection of event sources for triggering Lambda functions has expanded from its initial image re-size S3 use case and currently includes the following:
- Table updates in Amazon DynamoDB.
- Modifications to objects in AWS S3 buckets.
- Notifications sent from Amazon SNS.
- Messages arriving in an Amazon Kinesis stream.
- AWS API call logs created by AWS CloudTrail.
- Client data synchronisation events in Amazon Cognito.
- Custom events from mobile applications, web applications, or other web services using AWS SDKs or AWS Mobile SDKs (such as the AWS Mobile SDK for Android).
An extended array of event triggers are selectable directly from function setup through the AWS Lambda service configuration section of the AWS Console as shown in Fig:1.
Fig:1 – Lambda function triggers within the AWS Console
Function Latency (Lambda Lag)
With serverless technology the enabling compute resource is abstracted away. For AWS Lambda this comes in the form of Docker containers. When a Lambda function is invoked an isolated Docker container is launched to run it. Once launched (from cold) the function is deemed ‘warm’ and (the container) can be/is used to run subsequent invocations (of the same function).
With regard to pricing, charges are based on the number of function requests and the time taken to execute the code. The first one million requests per month are free but above this limit a stay warm trigger would incur costs. Further pricing information is available here and AWS provides an online cost calculator.
As function latencies can range from from hundreds to thousands of milliseconds the impact of warm/cold invocation is a consideration. Inclusion of API Gateway and DynamoDB components further compound the issue, but for Lambda itself solutions for latency mitigation at function invocation centre around memory allocation (and resulting CPU) coupled with methods to ‘stay warm’.
Allocated memory for a Lambda function also relates to CPU, with a larger memory allocation resulting in greater CPU performance. This in turn leads not only to quicker function execution, but a concurrently extended execution window. Although additional CPU can contribute it is not a full solution, and to help combat spin up lag from cold to warm you either need a high invocation rate to limit cold starts, or to implement a periodic fake start method to ensure function (container) preload on the back end host (stay warm). This could, ironically, be another Lambda function (i.e on a periodic timer).
The code type used to create a function is another consideration. Both node.js and/or python are identified as being quicker at initial invocation than those using Java. JVM caveats aside, this is also in part due to the Lambda deployment limit of 50mb per (zipped) function. Although 50mb seems accommodating, a Java function will invariably be weightier than its node.js or python counterpart due to packaged dependencies and a 50mb zip/jar file is not uncommon (Lambda also doesn’t support the concept of WAR files). Although inversely, optimised Java functions are reported as having potential to provide faster runtimes for subsequent invocations.
Function Versioning
AWS allocates all resources a unique ARN reference (an Amazon Resource Name). This is such throughout every level of service from an IAM user to an EC2 instance and when a Lambda function is created it too is allocated an ARN:
arn:aws:lambda:us-east-1:983537537744:function:myFunction:$LATEST
Referencing a Lambda function ARN directly is a bad idea. Unless you are the world’s most gifted and visionary developer the chances of change/update are most likely 100%, and I’m guessing you would prefer not having to rewrite your application code at every function revision. Far better to create a function alias and reference the fixed ARN for that instead, updating the function it refers to when things change or when you want to test a new version.
arn:aws:lambda:us-east-1:983537537744:function:myFunction:myFunctionAlias
Local Testing
With regard to testing, AWS Lamba isn’t renowned for its ease of in situ error or log reporting. What are the options for local debugging? Is it even possible?
Replicating AWS primitives locally is always fun; sometimes it’s possible and sometimes not; sometimes a workaround is needed (for example running Amazon Linux EC2s in a local Docker container) and sometimes the effort involved is just too much. Fortunately the hoops required to replicate something close enough to an online AWS Lambda environment for function debugging aren’t that numerous and there are a broad selection of assistive implementations created by the community to facilitate. For example this grunt plugin to assist in developing functions for AWS Lambda.
Is AWS Lambda the future of Serverless?
Not to understate its impact but yes, AWS Lambda is certainly going to feature. Admittedly there are rough edges, and although it currently lacks maturity in areas of error logging and visibility of security let’s not forget how new a product AWS Lambda is and how quickly it is evolving.
There are many examples already showcasing the benefits of adoption. One such being the David Guetta on-line recording project built by the Leeds digital agency Parallax. As discussed in this presentation, using regular cloud infrastructure would have incurred monthly expenditure of around $36,000, whereas using AWS Lambda this was under $200. The potential for such cost savings is certainly alluring.
Unlike Docker containers there is no portability whatsoever with AWS Lambda, which leads to the issue of vendor lock in. This is fine if you are truly committed to AWS for the long haul, but I do think an awareness of the commitment involved is wise.
If you would like advice or assistance with aspects of AWS Lambda, Serverless, or any other area of AWS, SkeltonThatcher offers a range of related consultancy services. Feel free to get in touch for an initial discussion via our contact page.
Skelton Thatcher 