This document provides an overview of serverless computing using AWS services like API Gateway, Lambda and DynamoDB. It begins with an introduction to serverless computing and how it differs from traditional VM-based and container-based architectures by focusing on functions as the unit of scale. It then provides overviews of DynamoDB as a fully managed NoSQL database service and Lambda for running code without managing servers. It discusses how API Gateway can be used to create serverless APIs that integrate with Lambda. The document concludes with best practices tips for using Lambda and serverless deployment with AWS SAM.

1. Presenter Name
Solutions Architect - AWS
Developer Roadshow
Serverless Web Apps using API Gateway,
Lambda and DynamoDB

2. Agenda
• What is Serverless?
• Introduction to Amazon DynamoDB
• Introduction to Lambda and API Gateway
• Tips and Best Practices

3. What is Serverless computing?
• VMs
• Machine as the unit of scale
• Abstracts the hardware
• Containers
• Application as the unit of scale
• Abstracts the OS
• Serverless
• Functions as the unit of scale
• Abstracts the language runtime
Amazon ECS
Amazon EC2
AWS Lambda

4. How do I choose?
• VMs
• “I want to configure machines,
storage, networking, and my OS”
• Containers
• “I want to run servers, configure
applications, and control scaling”
• Serverless
• “Run my code when it’s needed”
ECS
EC2
Lambda

5. What is Serverless?
Provisioning
and Utilization
Operations
and Management
Scaling Availability and
Fault Tolerance
Removes the need for….

6. Amazon DynamoDB

7. Amazon DynamoDB
• Brief history of data processing
• Relational (SQL) vs. non-relational (NoSQL)
• Fully managed features of DynamoDB

8. Data volume since 2010
• 90% of stored data generated in
last 2 years
• 1 terabyte of data in 2010 equals
6.5 petabytes today
• Linear correlation between data
pressure and technical innovation
• No reason these trends will not
continue over time

9. Relational (SQL) vs.
non-relational (NoSQL)

10. Relational vs. non-relational databases
Traditional SQL NoSQL
DB
Primary Secondary
Scale up
DB
DB
DBDB
DB DB
Scale out

11. SQL vs. NoSQL schema design
NoSQL design optimizes for
compute instead of storage
Product Database

12. Amazon DynamoDB
Run your business, not your database

13. Fully managed
Fast, consistent performance
Highly scalable
Flexible
Event-driven programming
Fine-grained access control
DynamoDB benefits

14. Fully managed service = automated operations
DB hosted on premises DB hosted on Amazon EC2

15. Fully managed service = automated operations
DB hosted on premises DynamoDB

16. Consistently low latency at scale
PREDICTABLE
PERFORMANCE!

17. WRITES
Replicated continuously to 3
Availability Zones
Persisted to disk (custom SSD)
READS
Strongly or eventually consistent
No latency trade-off
Designed to
support 99.99%
of availability
Built for high
durability
High availability and durability

18. That sounds really good. How
do I get started?
Let’s create a table…

19. Products
Product_Id

21. DynamoDB table structure
Table
Items
Attributes
Partition
key
Sort
key
Mandatory
Key-value access pattern
Determines data distribution Optional
Model 1:N relationships
Enables rich query capabilities
All items for key
==, <, >, >=, <=
“begins with”
“between”
“contains”
“in”
sorted results
counts
top/bottom N values

22. • Stream of updates to a
table
• Asynchronous
• Exactly once
• Strictly ordered
• Per item
DynamoDB Streams
• Highly durable
• Scale with table
• 24-hour lifetime
• Subsecond latency

23. View Type Destination
Old image—before update Name = John, Destination = Mars
New image—after update Name = John, Destination = Pluto
Old and new images Name = John, Destination = Mars
Name = John, Destination = Pluto
Keys only Name = John
View types
UpdateItem (Name = John, Destination = Pluto)

24. Triggers
Lambda Function
Notify Change
Derivative Tables
Amazon
CloudSearch
Amazon ElastiCache

25. AWS Lambda

26. Components of Lambda
• A Lambda function (that you write)
• An event source
• The AWS Lambda service
• The function networking environment

27. Lambda Function
• Your code
(Java, NodeJS, Python, C#)
• The IAM role that code
assumes during execution
• The amount of memory
allocated to your code
(affects CPU and network
as well)
A valid, complete
Lambda function

28. Event Sources
• When should your function
execute?
• Many AWS services can be
an event source today:
• Amazon S3
• Amazon Kinesis
• Amazon SNS
• Amazon DynamoDB
• Amazon CloudWatch
• AWS Config Rules
• Amazon Echo
• Etc.
• …and Amazon API
Gateway (more later)

29. AWS Lambda
• Runs your function code without you managing or
scaling servers.
• Provides an API to trigger the execution of your function.
• Ensures function is executed when triggered, in parallel,
regardless of scale.
• Provides additional capabilities for your function
(logging, monitoring).

30. 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

31. AWS Lambda Programming Model
Bring your own code
• Node.js, Java, Python, C#
• 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
• Reports actual usage
Programming model
• AWS SDK built in (Python
and Node.js)
• Lambda is the “webserver”
• Use processes, threads,
/tmp, sockets normally
Stateless
• Persist data using Amazon
DynamoDB, S3, or Amazon
ElastiCache
• No affinity to infrastructure
(can’t “log in to the box”)

32. Using AWS Lambda
Authoring functions
• Author directly using the
console WYSIWYG editor
• Package code as a .zip and
upload to Lambda or S3
• Plugins for Eclipse and
Visual Studio
• Command line tools
Monitoring and logging
• Built-in metrics for requests,
errors, latency, and throttles
• Built-in logs in Amazon
CloudWatch Logs
Flexible authorization
• Securely grant access to
resources, including VPCs
• Fine-grained control over
who can call your functions
Flexible use
• Call or send events
• Integrated with other AWS
services
• Build whole serverless
ecosystems

33. AWS Lambda Pricing
• Buy compute time in
100 ms increments
• Low request charge
• No hourly, daily, or
monthly minimums
• No per-device fees
Never pay for idle!
Free Tier
1 million requests and 400,000 GBs of
compute every month, every customer

34. Amazon API Gateway

35. Introduction to Amazon API Gateway
Create a unified
API frontend for
multiple micro-
services
Authenticate and
authorize
requests to a
backend
DDoS protection
and throttling for
your backend
Throttle, meter,
and monetize API
usage by 3rd
party developers

36. API Gateway - Capabilities
• Host multiple versions and stages of your APIs
• Create and distribute API keys to developers
• Leverage signature version 4 to authorize access to APIs
• Throttle and monitor requests to protect your backend
• Utilize Lambda as a backend

37. Benefits of API Gateway
• Managed cache to store API responses
• Reduced latency and distributed denial of service (DDoS) protection
through Amazon CloudFront
• SDK generation for iOS, Android, and JavaScript
• Swagger support
• Request and response data transformation

38. Amazon API Gateway: Serverless APIs
Internet
Mobile
apps
Websites
Partner
Services
AWS Lambda
functions
API
Gateway
response
cache
Endpoints on
Amazon EC2
Any publicly
accessible
endpoint
Amazon
CloudWatch
Amazon
CloudFront
API
Gateway

39. Tips and best practices

40. Lambda Environment Variables
• Key-value pairs that you can dynamically pass to
your function
• Available via standard environment variable APIs
such as process.env for Node.js or os.environ for
Python
• Can optionally be encrypted via KMS
• Allows you to specify in IAM what roles have access to
the keys to decrypt the information
• Useful for creating environments per stage (such as
dev, testing, production)

41. AWS Lambda VPC: Best practices
VPC is optional – don’t turn in on unless you need it.
Functions configured for VPC access lose internet access…
• Unless you have managed NAT or a NAT instance in the VPC
The ENIs used by Lambda’s VPC feature count against your quota.
Ensure you have enough to match your peak concurrency levels
(we’ll consolidate where we can).
DO NOT delete or rename these ENIs!
Ensure your subnets have enough IPs for those ENIs.
Specify at least one subnet in each Availability Zone
Otherwise, Lambda will obey, but can’t be as fault-tolerant.

42. Serverless Deployment

43. AWS Serverless Application Model (SAM)
CloudFormation extension optimized for
serverless
New serverless resource types: functions, APIs,
and tables
Supports anything CloudFormation supports
Open specification (Apache 2.0)
https://github.com/awslabs/serverless-application-model

44. SAM template
From: https://github.com/awslabs/aws-serverless-samfarm/blob/master/api/saml.yaml
<-THIS
BECOMES THIS->

45. AWS commands – Package & Deploy
Package
•Creates a deployment package (.zip file)
•Uploads deployment package to an Amazon S3 bucket
•Adds a CodeUri property with S3 URI
Deploy
•Calls CloudFormation ‘CreateChangeSet’ API
•Calls CloudFormation ‘ExecuteChangeSet’ API

46. Common Serverless use cases
Web
Applications
• Static
websites
• Complex web
apps
• Packages for
Flask and
Express
Data
Processing
• Real time
• MapReduce
• Batch
Chatbots
• Powering
chatbot logic
Backends
• Apps &
services
• Mobile
• IoT
</></>
Amazon
Alexa
• Powering
voice-enabled
apps
• Alexa Skills
Kit
Autonomous
IT
• Policy engines
• Extending
AWS services
• Infrastructure
management

47. Internal only – do not distribute
What’s the same
- Standard languages and protocols
- Standard deployment and testing practices
What's unique
- Event/request driven
- Modular
- Stateless
- Call it 12 factor/Microservices/Reactive..
What that means
- Monoliths need to be broken up
- Consider how functions communicate/ clear
service boundaries
- Need to deal with composition/aggregation
- Need to understand things like building for failure,
eventual consistency
EVENTS
Requests to endpoints
Changes in resource state
Changes in data state
FUNCTIONS
DOWNSTREAM
“Distributed, stateless, ephemeral – what could possibly go wrong?”
Key mindshift – how apps are built

48. Links:
Serverless: aws.amazon.com/serverless
DynamoDB: aws.amazon.com/dynamodb
Lambda: aws.amazon.com/lambda
API Gateway: aws.amazon.com/api-gateway
me: email@amazon.com

49. Internal only – do not distribute
IoT Button: http://bit.ly/2rQocXH
Labs: http://bit.ly/2rYXxwH
IoT Button Homework