Serverless Web Apps - using Amazon API Gateway and AWS Lambda

Presented at the AWSNE meetup on Tuesday 1st March 2016.

http://www.meetup.com/Amazon-Web-Services-North-East/

Uses a modified version of https://github.com/awslabs/lambda-refarch-webapp as an example serverless web application.

Transcript

1. Please go to http://vote.1f55.uk
2. Serverless Web Apps Voting web application using Amazon API Gateway and AWS Lambda Mike Shutlar, Expert Flamebaiter
3. Summary of services used
4. AWS CloudFormation • To provision the AWS resources • Uses JSON templates • Allows to define infrastructure as code
5. Amazon S3 • Object storage • One bucket stores the Lambda code to deploy via CloudFormation • Another bucket stores the website HTML and assets • This bucket configured for static website hosting
6. Amazon DynamoDB • NoSQL database PaaS with built-in HA/durability • Two tables, one for votes and one for vote aggregation • DynamoDB Streams enable reading and processing updates to the tables
7. Amazon Cognito • Service that provides identity management and data synchronisation • Used here to provide an identity pool to allow browser-side code to run as an unauthenticated user that has IAM permissions to scan the DynamoDB vote aggregation table directly
8. Amazon API Gateway • Allows to define resources and methods to create publicly available REST APIs • These manage the requests and responses when invoking their respective Lambda functions • Two resources used here, one for voting via SMS/Twilio and one for voting via the website
9. AWS Lambda • Compute service that allows to run code without needing a server (code runs in AMZ Linux container) • Three Lambda functions used here: ◦ One to register votes received via Twilio ◦ One to register votes received via the website ◦ One that listens to a DynamoDB stream from the votes table, and aggregates the votes when there are changes
10. Putting it all together...
11. Benefits
12. Over traditional server architectures • Modularity and separation • Isolated deployments and failures • No ongoing server maintenance • Potentially unlimited instant scalability • Smaller attack surface • Cheap!
13. > 90% Cost reduction when compared to a traditional HA server architecture. (That’s before factoring in additional cost savings from reduced man-hours incurred performing maintenance etc...)
14. Downsides & Hurdles
15. Compared to traditional server architectures • Not every web application will be suited for it • Occasional latency spike due to Lambda container creation (~2-3 secs average for Node.js runtime) • Requires initial learning curve to enable design and development of appropriate application architectures
16. One last benefit...
17. All management of the application can be done in code.
18. Questions? Thanks! Mike Shutlar @mikeshutlar