Application architecture is increasingly migrating to an event driven model - which are more efficient and have lower operational overhead. In this talk we will cover how to build a fully event driven architecture using AWS Lambda, chaining together multiple functions to build a complex application, which can be easily scaled to millions of users.

1. © 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Olivier Klein 奧樂凱
Emerging Technologies SA, Asia-Pacific
11 April 2017
Serverless Solutions
Build Scalable, Fault-Tolerant and Transaction-Safe Microservices on AWS

2. The Monolithic Architecture

3. The Monolithic Architecture - Antipattern
Difficult to scale
Single point of failure
Not fault-tolerant
Difficult to work across
teams, often slow to
iterate on new
functionalities

4. The Microservices Architecture

5. Microservices advocate creating a system
from a collection of small, isolated services,
each of which owns their data,
scalable and resilient to failure

6. Dr. Werner Vogels
CTO - Amazon

7. No server is easier to manage…

8. …than no server.
No server is easier to manage…

9. AWS Lambda
No server is easier to manage…
…than no server.

10. AWS Lambda
Run your code without thinking about
servers. Pay only for compute time
you consume.
Triggered through API calls or state
changes in your AWS environment
Scales automatically to match the
incoming event rate
Charged per 100ms execution time
AWS Lambda

11. The Microservices Architecture

12. Serverless Microservices

13. Architect to be Serverless
Fully Managed
• No provisioning
• Zero Administration
• High-Availability
Developer Productivity
• Focus on the code
• Innovate rapidly
• Reduce time to market
Scalability
• Automatically
• Scale up and down

14. Many Serverless Options on AWS
Storage DatabaseNetwork
Compute Content DeliveryMessaging and QueuesSecurity
Gateways
User Management Monitoring & Logging
Internet of Things
Machine Learning
Streaming Analytics

15. How to build application backends?
Back-end logic DatabaseMobile

16. How to build serverless microservices?
AWS
Lambda
Amazon API
Gateway
Amazon
DynamoDB
Microservice

17. Webhooks – Integrate with other platforms
Facebook
Page AWS Lambda
Slack
Channel
Amazon
API
Gateway
Amazon
DynamoDB
Incoming
Webhook
Oli just posted
on your page!
Oli | 2016-10-
01 | Hello

18. How to get the web app to the browser?
?

19. Storage and Delivery of the App
Amazon S3
Amazon
CloudFront
Amazon S3
• Highly available object storage
• Designed for 99.999999999% durability
• Offers HTTP / HTTPS endpoint to objects
Amazon CloudFront
• Content Delivery Network with 73 edge
locations across the world
• Caches content on edge locations for low
latency

20. Amazon S3
Amazon
CloudFrontBrowser

21. Serverless Game Demo
AWS
Lambda
Amazon API
Gateway
Amazon S3Amazon
CloudFront
Browser
Amazon
DynamoDB

22. DynamoDB
Streams
Cognito
Sync Trigger
S3 Event
Notification
AWS Lambda: Event-driven compute

23. You said transaction-safe!
How does that work?

24. Serverless Microservices
AWS
Lambda
Amazon API
Gateway
Highly available
Scalable
Fault tolerant
Cost effective
Secure
BUT: Stateless!
Microservice
?

25. Challenge: Centralized Database
user-svc account-svccart-svc
DB
Applications often have a
monolithic data store
• Difficult to make schema
changes
• Technology lock-in
• Vertical scaling
• Single point of failure

26. Centralized Database – Anti-pattern
Applications often have a
monolithic data store
• Difficult to make schema
changes
• Technology lock-in
• Vertical scaling
• Single point of failure
user-svc account-svccart-svc
DB

27. Decentralized Data Stores
account-svccart-svc
DynamoDB RDS
user-svc
ElastiCache RDS
Polyglot Persistence
Each service chooses its
data store technology
Low impact schema changes
Independent scalability
Data is gated through the
service API

28. CAP Theorem
It is impossible for a distributed computer system to
simultaneously provide all 3 of the following guarantees:
Consistency
Availability
Partition Tolerance
à In the presence of network partition we need to choose
between consistency and availability

29. Challenge: Transactional Integrity
Polyglot persistence generally translates
into eventual consistency
Asynchronous calls allow non-
blocking, but returns need to be handled
properly
How about transactional integrity?
• Event-sourcing – Capture changes as
sequence of events
• Staged commit
ERROR
STATE?
ROLLBACK?

30. Best Practice: Use Correlation IDs
09-02-2015 15:03:24 ui-svc INFO [uuid-123] ……
09-02-2015 15:03:25 catalog-svc INFO [uuid-123] ……
09-02-2015 15:03:26 checkout-svc ERROR [uuid-123] ……
09-02-2015 15:03:27 payment-svc INFO [uuid-123] ……
09-02-2015 15:03:27 shipping-svc INFO [uuid-123] ……
ui-svc
catalog-
svc
checkout-
svc
shipping-
svc
payment-
svc
request correlation id:
“uuid-123”
correlation id:
“uuid-123”

31. Best Practice: Microservice owns Rollback
Every microservice should expose
it’s own “rollback” method
This method could just rollback
changes, or trigger subsequent
actions (e.g. send notification)
If you implement staged commit,
also expose a commit function
Microservice
Function 1
Rollback
Commit
(optional)

32. Event-Driven: DynamoDB Streams
If async, consider event-driven
approach with DynamoDB Streams
Don’t need to manage function
execution failure, DDB Streams
automatically retries until successful
“Attach” yourself to the data of
interest
Kinesis, SQS, SNS also possible
Microservice

33. Challenge: Report Errors / Rollback
What if functions fail? (business logic
failure, not code failure)
Create a “Transaction Manager”
microservice that notifies all relevant
microservices to rollback or take action
DynamoDB is the trigger for the clean-up
function (could be SQS, Kinesis etc.)
Use Correlation ID to identify relations
mm-svc
Transaction
Manager
Function
DDB Streams
API Call
Error Table

34. Challenge: Report Errors / Rollback
ERROR
DynamoDB
Error Table
Transaction
Manager
Function
Kinesis
Error Stream
SQS
Error Queue
Rollback
(correlation-id)
Rollback
(correlation-id)
Rollback
(correlation-id)
Rollback
(correlation-id)

35. Challenge: Code Error
Lambda Execution Error because of
faulty / erroneous code
Leverage Cloudwatch Logs to
process error message and call
Transaction Manager
Set Cloudwatch Logs Metric Filter
to look for Error/Exception and call
Lambda Handler upon Alarm state
ui-svc
Cloudwatch
Logs
Cloudwatch
Alarm
Transaction
Manager
Function

36. Beware: Stream Model with AWS Lambda
DynamoDB Streams and Kinesis streams directly work
with AWS Lambda, however AWS Lambda needs to
acknowledge processing the message correctly
If Lambda fails to process the message, the stream
horizon will not be moved forward, creating a “jam”
Solution: Monitor AWS Lambda Error Cloudwatch
Metric and react when error rate of same “Correlation ID”
keeps increasing

37. MDM – Keep Data Consistent
Databases
AWS Lambda
“Cleanup”
Function
Cloudwatch
Scheduled Event
Perform Master Data Management
(MDM) to keep data consistent
Create AWS Lambda function to
check consistencies across
microservices and “cleanup”
Create Cloudwatch Event
to schedule the function
(e.g. hourly basis)

38. Final Thoughts
Use Amazon API Gateway to build a front-door to all your
microservices (AWS Lambda, Docker, EC2 etc.)
Use microservices with polyglot persistence to avoid
bottlenecks, schema issues, quick iterations and allow
independent scalability (and caching)
Create many version and stages – no additional charges
for APIs, allows for backwards compatibility
Use serverless interfaces when possible – HTML5 and
JS frameworks like React or Angular are useful

39. Thank you!
Olivier Klein 奧樂凱
Emerging Technologies SA, Asia-Pacific