Você está na página 1de 30

Deep Dive on AWS Lambda

Capabilities, benefits, and best practices


Presenter Q&A Moderators
Vyom Nagrani Stefano Buliani, Solution Architect, AWS Serverless
Manager Product Management, AWS Lambda Vishal Singh, Sr. Product Manager, AWS Lambda
Orr Weinstein, Sr. Product Manager, AWS Lambda

January 18th, 2017

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Agenda for today’s Webinar

 Working with AWS Lambda


 Development and testing on AWS Lambda
 Deployment and ALM for AWS Lambda
 Security and scaling on AWS Lambda
 Debugging and operations for AWS Lambda
 Questions & answers
Working with AWS Lambda
Working with AWS Lambda

EVENT SOURCE FUNCTION SERVICES (ANYTHING)

Changes in
data state
Node
Requests to Python
endpoints Java
C#
Changes in
resource state
Benefits of AWS Lambda

Productivity-focused compute platform to build powerful, dynamic, modular


applications in the cloud

1 2 3
No infrastructure Cost-effective and Bring your
to manage efficient own code

Focus on business logic Pay only for what you use Run code in standard
languages
Event sources that trigger AWS Lambda
DATA STORES ENDPOINTS

Amazon Amazon Amazon Amazon Amazon Amazon AWS


S3 DynamoDB Kinesis Cognito Alexa API Gateway IoT

CONFIGURATION REPOSITORIES EVENT/MESSAGE SERVICES

AWS AWS AWS Amazon Amazon Amazon


CloudFormation CloudTrail CodeCommit CloudWatch SES SNS Cron events

… and the list will continue to grow!


Key scenarios and use cases for AWS Lambda

Data processing App backend development Control systems


Stateless processing of Execute server side Customize responses and
discrete or streaming backend logic for web, response workflows to state
updates to your data-store mobile, device, or voice user and data changes within
or message bus interactions AWS
Development and testing on
AWS Lambda
Getting started on AWS Lambda

Bring your own code Simple resource model


• Node.js 4.3, Java 8, • Select power rating from
Python 2.7, C# 128 MB to 1.5 GB
• CPU and network
allocated proportionately

Flexible use Stateless


• Synchronous or • Persist data using
asynchronous external storage
• Integrated with other • No affinity or access to
AWS services underlying infrastructure
Anatomy of a Lambda function

Handler() function Event object Context object

• The method in your • Pre-defined object • Use methods and


code where AWS format for AWS properties like
Lambda begins integrations & events getRemainingTimeIn
execution • Java & C# support Millis(), identity,
simple data types, awsRequestId,
POJOs/POCOs, and invokedFunctionArn,
Stream input/output clientContext,
logStreamName
FunctionConfiguration metadata

VpcConfig DeadLetterConfig Environment

• Enables private • Failed events sent to • Add custom


communication with your SQS queue / key/value pairs as
other resources SNS topic part of configuration
within your VPC • Redrive messages • Reuse code across
• Provide EC2 security that Lambda could different setups or
group and subnets, not process passwords
auto-creates ENIs • Currently available • Encrypted with
• Internet access can for asynchronous specified KMS key
be added though invocations only on server, decrypted
NAT Gateway at container init
AWS Lambda limits
Resource Limits Default Limit
Ephemeral disk capacity ("/tmp" space) 512 MB

Number of file descriptors 1024

Number of processes and threads (combined total) 1024

Maximum execution duration per request 300 seconds

Invoke request body payload size (RequestResponse) 6 MB

Invoke request body payload size (Event) 128 K

Invoke response body payload size (RequestResponse) 6 MB

Dead-letter payload size (Event) 128 K

Deployment Limits Default Limit


Lambda function deployment package size (.zip/.jar file) 50 MB
Size of code/dependencies that you can zip into a deployment package (uncompressed zip/jar size) 250 MB
Total size of all the deployment packages that can be uploaded per region 75 GB

Total size of environment variables set 4 KB

Throttling Limits (can request service limit increase) Default Limit


Concurrent executions 100
The container model

Container reuse Cold starts

• Declarations in your Lambda function • Time to set up a new container and do


code outside handler() necessary bootstrapping when a
• Disk content in /tmp Lambda function is invoked for the first
• Background processes or callbacks time or after it has been updated

• Make use of container reuse • Ways to reduce cold start latency


opportunistically, e.g. • More memory = faster
performance, lower start up time
• Load additional libraries
• Smaller function ZIP loads faster
• Cache static data
• Node.js and Python start execution
• Database connections faster than Java and C#
The execution environment

Underlying OS Available libraries

• Public Amazon Linux AMI version • ImageMagick (nodejs wrapper and


(amzn-ami-hvm-2016.03.3.x86_64-gp2) native binary)
• Linux kernel version (4.4.23- • OpenJDK 1.8, .NET Core 1.0.1
31.54.amzn1.x86_64) • AWS SDK for JavaScript version 2.6.9
• AWS SDK for Python (Boto 3) version
• Compile native binaries against this 1.4.1, Botocore version 1.4.61
environment – can be used to bring
your own runtime! • Embed your own SDK/libraries if you
• Changes over time, always check the depend on a specific version
latest versions supported here
Deployment and ALM for AWS
Lambda
Building a deployment package

Node.js & Python Java C# (.NET Core)

• .zip file consisting of • Either .zip file with all • Either .zip file with all
your code and any code/dependencies, code/dependencies,
dependencies or standalone .jar or a standalone .dll
• Use npm/pip to • Use Maven / Eclipse • Use Nuget /
install libraries IDE plugins VisualStudio plugins
• All dependencies • Compiled class & • All assemblies (.dll)
must be at root level resource files at root at root level
level, required jars in
/lib directory
Managing continuous delivery

Source Build Test Deploy

AWS CodeCommit AWS CodeBuild AWS CodePipeline

GitHub Jenkins Codeship

… OR …

Amazon S3 AWS Lambda (DIY)


Deployment tools and frameworks available

CloudFormation Chalice Third-party tools

• AWS Serverless • Python serverless • Serverless


Application Model - micro-framework Framework
extension optimized • Quickly create and (https://serverless.com/)
for Serverless deploy applications • Apex Serverless
• New Serverless • Set up AWS Lambda Architecture
resources – APIs, and Amazon API (http://apex.run/)
Functions, Tables Gateway endpoint • DEEP Framework by
• Open specification • https://github.com/aw Mitoc Group
(Apache 2.0) slabs/chalice (https://github.com/Mitoc
Group/deep-framework)
Function versioning and aliases

• Versions = immutable copies of code +


configuration
• Aliases = mutable pointers to versions

• Development against $LATEST version


• Each version/alias gets its own ARN

• Enables rollbacks, staged promotions,


“locked” behavior for client
Security and scaling on AWS
Lambda
The push model and resource policies

Function (resource) policy

• Permissions you grant to your Lambda


function determine which service or
event source can invoke your function

• Resource policies make it easy to


grant cross-account permissions to
invoke your Lambda function
The pull model and IAM roles

IAM (execution) role

• Permissions you grant to this role


determine what your AWS Lambda
function can do

• If event source is Amazon DynamoDB


or Amazon Kinesis, then add read
permissions in IAM role
Concurrent executions and throttling

Determining concurrency Throttle behavior

• For stream-based event sources: • For stream-based event sources:


Number of shards per stream is the Automatically retried until data expires
unit of concurrency
• For Asynchronous invocations:
• For all other event sources: Request Automatically retried for up to six
rate and duration drives concurrency hours, with delays between retries
(concurrency = requests per second *
function duration) • For Synchronous invocations: Invoking
application receives a 429 error and is
responsible for retries
Other scaling considerations

For Lambda For upstream/downstream services

• Remember, a throttle is NOT an error! • Build retries/backoff in client


applications and upstream setup
• If you expect sudden large spikes in
demand, consider Asynchronous • Make sure your downstream setup
invocations to Lambda “keeps up” with Lambda scaling

• Proactively engage AWS Support to • Limit concurrency when connecting to


increase your throttling limits relational databases
Debugging and operations for
AWS Lambda
Errors and retries

Types of errors Retry policy

• 4xx Client Error: Can be fixed by • For stream-based event sources:


developer, e.g. InvalidParameterValue Automatically retried until data expires
(400), ResourceNotFound (404),
RequestTooLarge (413), etc. • For Asynchronous invocations:
Automatically retried 2 extra times,
• 5xx Server Error: Most can be fixed by then published to dead-letter queue
admin, e.g. EC2 ENI management
errors (502) • For Synchronous invocations: Invoking
application receives an error code and
is responsible for retries
Tracing and tracking
COMING
SOON!
Integration with AWS X-Ray Integration with AWS CloudTrail

• Collects data about requests that your • Captures calls made to AWS Lambda
application serves API; delivers log files to Amazon S3

• Visibility into the AWS Lambda service • Tracks the request made to AWS
(dwell time, number of retries, latency Lambda, the source IP address from
and errors) which the request was made, who
made the request, when it was made
• Detailed breakdown of your function’s
performance, including calls made to • All control plane APIs can be tracked
downstream services and endpoints (no versioning/aliasing and invoke API)
Troubleshooting and monitoring

Logs Metrics

• Every invocation generates START, END, • Default (Free) Metrics: Invocations,


and REPORT entries in CloudWatch Logs Duration, Throttles, Errors – available as
CloudWatch Metrics
• User logs included
• Node.js – console.log(), console.error(), • Additional Metrics: Create custom
console.warn(), console.info()
metrics for tracking health/status
• Java – log4j.*, LambdaLogger.log(),
system.out(), system.err() • Function code vs log-filters
• Python – print, logging.* • Ops-centric vs. business-centric
• C# – LambdaLogger.Log(),
ILambdaContext.Logger.Log(),
console.write(), console.writeline()
Conclusion and next steps

Key takeaway
AWS Lambda is one of the core components of the
platform AWS provides to develop serverless applications

Next steps
1. Stay up to date with AWS Lambda on the Compute blog
and check out our detail page for more scenarios.
2. Send us your questions, comments, and feedback on
the AWS Lambda Forums.
Thank you!