The document discusses serverless architectures using AWS Lambda and Amazon API Gateway. It provides background on moving from monolithic to microservices architectures. It then covers AWS Lambda functions, event sources, and networking environments. Amazon API Gateway is presented as a way to build multi-tier serverless applications. Common serverless architecture patterns and best practices for AWS Lambda, API Gateway, and general serverless development are outlined. The document concludes with a demonstration of a simple CRUD backend using Lambda and DynamoDB with API Gateway.

1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Vyom Nagrani
Manager Product Management, AWS Lambda
30th March, 2016
Getting Started with
Serverless Architectures

2. Agenda
 Background
 AWS Lambda
 Amazon API Gateway
 Serverless Architecture Patterns
 Serverless Best Practices

3. Background
How serverless architecture patterns with AWS Lambda are the next
evolution of application design

4. The Monolithic Application

5. The Monolithic Application
• Lots of Collateral Damage
• All-for-one and one-to-fail
• Slipped timelines
• Operational issues
• Deploy Less Frequently
• Less disruption
• More time to plan
Reduce
Risk

6. Break it apart.

7. The Monolithic Architecture

8. The Service Oriented Architecture
Presentation Tier
Logic Tier
Data Tier

9. The Microservices Architecture

10. Tools to help this pattern are VAST
 Web Servers
 Code Libraries
 Web Service/Application Frameworks
 Configuration Management Tools
 API Management Platforms
 Deployment Patterns
 CI/CD Patterns
 Containers
 … and so on

11. AWS has helped too!
 Amazon EC2
 EC2 Auto-Scaling
 AWS Elastic Load Balancer
 EC2 Auto-Recovery
 AWS Trusted Advisor
 AWS Elastic Beanstalk
 AWS OpsWorks
 AWS EC2 Container Service
 Etc. Etc. Etc.

12. But …
many of these tools and innovations are still
coupled to a shared dependency…

13. 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!!)

14. Architect to be Serverless
 Fully Managed
 No provisioning
 Zero administration
 High availability
 Developer Productivity
 Focus on the code that matters
 Innovate rapidly
 Reduce time to market
 Continuous Scaling
 Automatically
 Scale up and scale down

15. Serverless, event-driven compute service
Lambda = microservice without servers
Enter AWS Lambda

16. Components of Lambda
 A Lambda Function (that you write)
 An Event Source
 The AWS Lambda Service
 The Function Networking Environment

17. The Lambda Function
 Your Code (Java, NodeJS, Python)
 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

18. An Event Source
Many AWS services can be an event source today:
 S3
 Kinesis
 SNS
 DynamoDB
 CloudWatch
 Config Rules
 Amazon Al
 … and many more
 …and, of course, Amazon API Gateway (more later)

19. The AWS Lambda Service
 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).

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

21. “Hold on…”

22. Lots of existing ways to abstract away servers
 SaaS
 PaaS
 MBaaS
 *aaS
 Application Engines/Platforms

23. What’s unique about Lambda?
 Abstraction at the code/function level (arbitrary, flexible,
familiar)
 The security model (IAM, VPC)
 The community
 Integration with the AWS Service ecosystem!
 Scale
 Triggers
 The pricing model

24. Continuous
Scaling
No Servers to
Manage
Subsecond
Metering
Benefits of AWS Lambda for building
serverless backends
1 2 3

25. Many Serverless Options on AWS
Compute Storage
Database
Network
Gateways
Internet of Things
Messaging and Queues
Machine LearningStreaming Analytics
Content Delivery
Security
User Management
Monitoring & Logging

26. Example Serverless
Architecture

27. PlayOn! Sports – Video stream processing
Laptop
Encoders
HLS
S3
Playback
VOD Stream
mobile client
CloudFront
Streaming
Live stream
mobile client
CloudFront S3 Ingest
480p
Transcode
HQ Copy
360p
Transcode
Audio-only
Transcode
Thumbnail
QOS
Analytics
Cascading Lambda Functions
http://www.slideshare.net/AmazonWebServices/arc308-the-serverless-company-using-aws-lambda

28. But…
… in order to utilize Lambda, do I really need to architect
event-driven applications?
… is there a way I can use this construct to built multi-
tier SOA applications?

29. Enter Amazon API Gateway
Create Configure Publish
Maintain Monitor Secure

30. Serverless Architecture Patterns

31. Microservices

32. Mobile Backend

33. Web Applications

34. Real-time Analytics Engine

35. Serverless Best Practices

36. AWS Lambda Best Practices
 Limit your function size – especially for Java (starting the JVM
takes time)
 Node – remember execution is asynchronous.
 Don’t assume function container reuse – but take advantage of it
when it does occur.
 Don’t forget about disk (500MB /tmp directory provided to each
function)
 Use the included logger (include details from service-provided
context)
 Create custom metrics (operations-centric, and business-centric)

37. Amazon API Gateway Best Practices
 Use Mock integrations
 Combine with Cognito for managed end user-based access control.
 Use stage variables (inject API config values into Lambda functions
for logging, behavior)
 Use request/response mapping templates everywhere within
reason, not passthrough.
 Take ownership of HTTP response codes
 Use Swagger import/export for cross-account sharing

38. Additional Best Practices
 Use strategic, consumable naming conventions (Lambda function
names, IAM roles, API names, API stage names, etc.)
 Use naming conventions and versioning to create automation.
 Externalize authorization to IAM roles whenever possible
 Least privilege and separate IAM roles
 Externalize configuration – DynamoDB is great for this.
 Contact AWS Support before known large scaling events
 Be aware of service throttling, engage AWS support if so.

39. A Call to Action

40. Let’s build something Serverless …
AWS Lambda
Function
web browser
Amazon S3
Amazon API
Gateway
Dynamic Content
Serverless Website
Amazon
DynamoDB
https://aws.amazon.com/blogs/compute/the-squirrelbin-architecture-a-
serverless-microservice-using-aws-lambda/

41. <shameless-pitch>
In case you didn’t guess …
We’re hiring!
Email lambda-jobs@amazon.com
</shameless-pitch>

42. Thank you!
https://www.linkedin.com/in/vyomnagrani
@vyomnagrani

43. Demo

44. Walkthrough of a simple CRUD backend with a
RESTful API endpoint using AWS Lambda
Amazon API
Gateway
AWS Lambda Amazon
DynamoDB
API call from
client app
Request/Response CRUD Operations

47. CRUD operations with DynamoDB
‘echo’ and ‘pong’ for testing
Error handling for incorrect inputs
Execute the operation with the event payload