Appendix D. Lambda insider

This appendix covers

• Execution environment
• Lambda’s limitations
• Older runtimes

Chapter 6 focuses on AWS Lambda, but it’s a rather vast topic, so we had to omit some things. This appendix covers information not included in chapter 6, such as information about Lambda’s execution environment, inherent limitations, and older runtimes.

D.1. Execution environment

At the time we wrote this appendix, Lambda ran on Amazon Linux with kernel version 4.1.17-22.30.amzn1.x86-24. If you’re like us, you might be interested in peeking under the hood and exploring the environment that Lambda has to offer. Luckily, we can get a bit of understanding of what’s under the covers by running shell commands. To try this yourself, do the following:

1. Open the Lambda console, and click Create a Lambda Function.
2. In the Blueprint Selection screen, type node-exec. That should filter the available blueprint functions to just one function named node-exec.
3. Click the node-exec function.
4. Click Next on the Configure Triggers screen.
5. Give your new function a name (for example, run-command).
6. In the Role section, select an existing role or create a new one. Your function will not interact with other AWS resources, so it can take on a basic role.
7. Click the Next button and then click Create Function.

You can now run this function and pass in commands you want the function to execute:

1. Make sure you’re looking at the run-command function in the console, click Actions, and click Configure Test Event.
2. The event object needs to have a key called cmd and the command to execute. The following listing shows an example of an event object that will execute ls al. You can replace ls -al with any shell command you wish to execute.

Listing D.1. Event object to run the ls command

{
    "cmd" : "ls -al"
}

Table D.1 shows the output if you run a few common commands.

Table D.1. System and environmental information for your container

Command	Purpose	Abbreviated output
uname -a	Prints system information.	Linux ip-10-0-95-167 4.1.17-22.30.amzn1.x86_64 #1 SMP Fri Feb 5 23:44:22 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
pwd	Prints the current working directory.	/var/task
ls -al	Lists the contents of current directory.	drwxr-xr-x 2 slicer 497 4096 Apr 4 10:10 . drwxr-xr-x 20 root root 4096 Apr 4 09:04 .. -rw-rw-r-- 1 slicer 497 478 Apr 4 10:09 index.js
env	Prints shell and environmental variables.	AWS_SESSION_TOKEN=FQoDYXd... AWS_LAMBDA_LOG_GROUP_NAME=/aws/lambda/run2 LAMBDA_TASK_ROOT=/var/task LD_LIBRARY_PATH=/usr/local/lib64/node-v4.3.x/lib:/lib64:/usr/lib64:/var/runtime:/var/runtime/lib:/var/task:/var/task/lib AWS_LAMBDA_LOG_STREAM_NAME=2017/01/23/[$LATEST]a65f9e2f349d4e9a8c9e193b0e175e78 AWS_LAMBDA_FUNCTION_NAME=run_command PATH=/usr/local/lib64/node-v4.3.x/bin:/usr/local/bin:/usr/bin/:/bin AWS_DEFAULT_REGION=us-east-1 PWD=/var/task AWS_SECRET_ACCESS_KEY=G9zLllGtxmL4... LAMBDA_RUNTIME_DIR=/var/runtime LANG=en_US.UTF-8 NODE_PATH=/var/runtime:/var/task:/var/runtime/node_modules AWS_REGION=us-east-1 AWS_ACCESS_KEY_ID=ASIAIKGQE5YIXTNE54JQ SHLVL=1 AWS_LAMBDA_FUNCTION_MEMORY_SIZE=128 _=/usr/bin/env
cat /proc/cpuinfo	Prints the type of processor used by the system.	processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 63 model name : Intel(R) Xeon(R) CPU E5-2666 v3 @ 2.90GHz stepping : 2 microcode : 0x36 cpu MHz : 2900.074 cache size : 25600 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt bogomips : 5800.14 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 63 model name : Intel(R) Xeon(R) CPU E5-2666 v3 @ 2.90GHz stepping : 2 microcode : 0x36 cpu MHz : 2900.074 cache size : 25600 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt bogomips : 5800.14 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual
ls /var/runtime/node_modules	Lists included NodeJS modules. You do not need to provide these modules with your function.	awslambda aws-sdk dynamodb-doc imagemagick

D.2. Limitations

Lambda executes code and scales automatically. It can handle thousands of requests per second. As with any system, however, there are limitations to think about. Table D.2 summarizes these. You can find the original AWS documentation related to Lambda’s limits at https://docs.aws.amazon.com/lambda/latest/dg/limits.html.

Table D.2. Lambda limits

What is it?	Default limit	Explanation
Ephemeral disk capacity (/tmp space)	512 MB	The total disk capacity you can use for temporary files
Number of file descriptors	1024	Maximum number of files that can be opened by the function
Number of processes and threads (combined total)	1024	Maximum number of threads and processes that can be spawned by the function
Maximum execution duration per request	300 seconds	The maximum number of seconds the function can execute for before it’s killed by the runtime
Invoke request body payload size (RequestResponse)	6 MB	The maximum size of the request when the function is invoked using the AWS SDK, the API Gateway, or the console
Invoke request body payload size (Event)	128 K	The maximum size of the request when the function is invoked by an event in AWS
Invoke response body payload size (RequestResponse)	6 MB	The maximum size of the response when the function is invoked using the AWS SDK, API Gateway, or the console

D.3. Working with older runtimes

AWS initially released Lambda, which used Node.js 0.10.42. That version of Lambda didn’t support the callback function. Instead, methods (succeed, fail, and done) available via the context object allowed the developer to cleanly terminate the function and return data to the caller. If you happen to come across a version of a Lambda function that uses the old Node.js 0.10.42 runtime, here’s what you need to know to use it correctly.

To properly terminate a Lambda function, you need to invoke one of the following three methods (this is different from the Node.js 4.3 or 6.10 versions where you can use callback):

• context.succeed(Object result)
• context.fail(Error error)
• context.done(Error error, Object result)

You must always terminate the function using a succeed, fail, or done function. If you don’t do that, your function may continue to run even after you think it’s finished.

D.3.1. Succeed

The context.succeed(Object result) method is called to indicate that the function has successfully finished execution. The result parameter is optional (you can use context.succeed() or context.succeed(null)), but it must be compatible with JSON.stringify if you decide to include it.

In case of a RequestResponse invocation type, calling this method will return an HTTP status 200 (OK). The body of the response will be set to the stringified version of result.

D.3.2. Fail

The context.fail(Error error) method is called to indicate that the function failed. Calling this function raises a handled exception. The error parameter is optional (you can leave it out or use a null). In the case of RequestResponse, if this parameter is provided, Lambda will try to stringify it and include it as the response body. It will set the HTTP status code to 400 (Bad Request) and also log the first 256 KB of the error object to CloudWatch.

D.3.3. Done

Finally, there’s the context.done(Error error, Object result) method. This method can be used in lieu of the succeed and fail methods. The error and result parameters are optional. If a non-null value is provided for the error parameter, this function is treated the same way as context.fail(error). If the error parameter is null, then the function is treated as a context.succeed(result) method.