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.
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
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
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
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
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
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
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.
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
45.
46.
47. CRUD operations with DynamoDB
‘echo’ and ‘pong’ for testing
Error handling for incorrect inputs
Execute the operation with the event payload