2. AWS compute offerings
VM Task Function
Service EC2 ECS Lambda
H/W OS Runtime
Unit of scale
Level of
abstraction
3. AWS compute offerings
I want to
configure
machines,
storage,
networking,
and my OS
I want to run
servers,
configure
applications,
and control
scaling
Run my
code when
it’s needed
Service EC2 ECS Lambda
How do I
choose?
4. Agenda
• Why AWS Lambda
• How it works
• Use cases
• Sample architecture
• Demo
• Best practices
6. Servers
How will the application
handle server hardware failure?
How can I control
access from my servers?
When should I decide to
scale out my servers?
When should I decide to
scale up my servers?
What size servers are
right for my budget?
How much remaining
capacity do my servers have?
(AAHHHHHHHHH!!)
7. Operations and management Scaling
Provisioning and utilization Availability and fault tolerance
Owning servers means dealing with ...
8. Serverless compute: AWS Lambda
COMPUTE
SERVICE
EVENT-
DRIVEN
Run arbitrary
code without
managing
servers
Code only runs
when it needs to
run
9. AWS Lambda: Run code in response to events
Lambda functions: Stateless, trigger-based code execution
Triggered by events:
• Direct sync and async API calls
• AWS service integrations
• Third-party triggers
• Many more …
Makes it easy to:
• Perform data-driven auditing, analysis, and notification
• Build back-end services that perform at scale
10. Cost-effective and
efficient
No infrastructure
to manage
Pay only for what you use
Bring your
own code
Productivity-focused compute platform to build powerful, dynamic, modular
applications in the cloud
Run code in standard
languages
Focus on business logic
Benefits of AWS Lambda
1 2 3
12. Using AWS Lambda
Bring your own code
• Node.js, Java, Python
• Bring your own libraries
(even native ones)
Simple resource model
• Select power rating from
128 MB to 1.5 GB
• CPU and network
allocated proportionately
Flexible use
• Synchronous or
asynchronous
• Integrated with other
AWS services
Flexible authorization
• Securely grant access to
resources and VPCs
• Fine-grained control for
invoking your functions
13. Using AWS Lambda
Authoring functions
• WYSIWYG editor or
upload packaged .zip
• Third-party plugins
(Eclipse, Visual Studio)
Monitoring and logging
• Metrics for requests,
errors, and throttles
• Built-in logs to Amazon
CloudWatch Logs
Programming model
• Use processes, threads,
/tmp, sockets normally
• AWS SDK built in
(Python and Node.js)
Stateless
• Persist data using
external storage
• No affinity or access to
underlying infrastructure
14. Application components for serverless apps
EVENT SOURCE FUNCTION SERVICES (ANYTHING)
Changes in
data state
Requests to
endpoints
Changes in
resource state
Node
Python
Java
… more coming soon
23. What to expect from the session
15-20 minutes of processing now in seconds
2x order of magnitude for cost savings
https://www.youtube.com/watch?v=TXmkj2a0fRE
Nordstrom Recommendations
26. Serverless → distributed by nature
Component graph
becomes call graph
Distributed systems
thinking is required from
the start
Event-based architecture
32. AWS Lambda best practices
Limit your function/code size
Node – remember execution is asynchronous
500 MB /tmp directory provided to each function
Don’t assume function will reuse underlying infrastructure
But take advantage of it when it does occur
You own the logs
Include details from service-provided context
Create custom metrics
Operations-centric vs. business-centric
33. Best practice: Use versions and aliases
Versions = immutable copies of code + properties
Aliases = mutable pointers to versions
Rollbacks
Staged
promotions
“Lock” behavior
for client
34. The function networking environment
Default - a default network environment within VPC is provided for you
Access to the Internet always permitted to your function
No access to VPC-deployed assets
Customer VPC - Your function executes within the context of your own VPC
Privately communicate with other resources within your VPC
Familiar configuration and behavior with:
Subnets
Elastic network interfaces (ENIs)
EC2 security groups
VPC route tables
NAT gateway
35. Additional best practices
Externalize authorization to IAM roles whenever possible
Least privilege and separate IAM roles
Externalize configuration
DynamoDB is great for this
Make sure your downstream setup “keeps up” with Lambda scaling
Limit concurrency when talking to relational databases
Be aware of service throttling
Engage AWS Support to increase your limits
Contact AWS Support before known large scaling events
36. Takeaways
• Many applications can go serverless
• Data processing, back ends, triggers, web hooks
• Lambda functions are opinionated
• State, invocation modes, and deployments
• The ecosystem continues to grow
• Tooling, languages, and application capabilities
37. Next steps
1. Go to console.aws.amazon.com/lambda and create your first
Lambda function. (The first 1M requests are on us!)
2. Stay up to date with AWS Lambda on the Compute blog and check
out aws.amazon.com/lambda for scenarios and customer stories.
3. Send us your questions, comments, and feedback on the AWS
Lambda Forums.
Bonus points: Enter the AWS Serverless Chatbot Competition
https://aws.amazon.com/blogs/aws/enter-the-aws-serverless-chatbot-
competition/