Workshop slides for Databases on AWS - Scaling Applications & Modern Data Architectures.

1. Blair Layton, Business Development Manager,
AWS, APAC
September 14, 2017
AWS Workshop Series
Databases on AWS
Scaling Applications & Modern Data Architectures

3. Introduction to AWS

4. AWS Regions 16 Regions – 44 Availability Zones – 77 Edge Locations
* As of 13 September 2017

5. Deploy faster wherever you like 16 Regions – 44 Availability Zones – 77 Edge Locations
* As of 13 September 2017

6. 6
Region
Availability Zone A Availability Zone B
Concepts: Regions, Availability Zones and Networking

7. Account Support
Support
Managed
Services
Professional
Services
Partner
Ecosystem
Training &
Certification
Solution
Architects
Account
Management
Security &
Pricing Reports
Technical Acct.
Management
Marketplace
Business
Applications
DevOps Tools
Business
Intelligence
Security
Networking
Database &
Storage
SaaS
Subscriptions
Operating
Systems
Mobile
Build, Test,
Monitor Apps
Push
Notifications
Build, Deploy,
Manage APIs
Device Testing
Identity
Enterprise
Applications
Document
Sharing
Email &
Calendaring
Hosted
Desktops
Application
Streaming
Backup
Game
Development
3D Game
Engine
Multi-player
Backends
Mgmt. Tools
Monitoring
Auditing
Service Catalog
Server
Management
Configuration
Tracking
Optimization
Resource
Templates
Automation
Analytics
Query Large
Data Sets
Elasticsearch
Business
Analytics
Hadoop/Spark
Real-time Data
Streaming
Orchestration
Workflows
Managed
Search
Managed ETL
Artificial
Intelligence
Voice & Text
Chatbots
Machine
Learning
Text-to-Speech
Image Analysis
Deep Learning
IoT
Rules Engine
Local Compute
and Sync
Device
Shadows
Device
Gateway
Registry
Hybrid
Devices & Edge
Systems
Data
Integration
Integrated
Networking
Resource
Management
VMware on
AWS
Identity
Federation
Migration
Application
Discovery
Application
Migration
Database
Migration
Server
Migration
Data Migration
Infrastructure Regions
Availability
Zones
Points of
Presence
Compute Containers
Event-driven
Computing
Virtual
Machines
Simple Servers Auto Scaling Batch
Web
Applications
Storage Object Storage Archive Block Storage
Managed File
Storage
Exabyte-scale
Data Transport
Database MariaDB
Data
Warehousing
NoSQLAurora MySQL Oracle SQL ServerPostgreSQL
Application
Services
Transcoding Step Functions Messaging
Security
Certificate
Management
Web App.
Firewall
Identity &
Access
Key Storage &
Management
DDoS
Protection
Application
Analysis
Active
Directory
Dev Tools
Private Git
Repositories
Continuous
Delivery
Build, Test, and
Debug
Deployment
Networking
Isolated
Resources
Dedicated
Connections
Load Balancing Scalable DNSGlobal CDN
The AWS
Platform

8. * As of 1 September 2017
2010
61
516
1,017
159
2012 2014 2016
AWS has been continually expanding its services to support virtually any cloud workload, and it
now has more than 90 services that range from compute, storage, networking, database,
analytics, application services, deployment, management, developer, mobile, Internet of Things
(IoT), Artificial Intelligence (AI), security, hybrid and enterprise applications. AWS has launched a
total of 795 new features and/or services year to date* - for a total of 3,708 new features and/or
services since inception in 2006.
AWS Pace of Innovation

9. Strengthen your security posture
Leverage security
enhancements from 1M+
customer experiences
Benefit from AWS
industry leading
security teams 24/7,
365 days a year
Security infrastructure
built to satisfy military, global
banks, and other high-
sensitivity organizations
Over 50 global
compliance
certifications and
accreditations
“We work closely with AWS to
develop a security model, which we
believe enables us to operate more
securely in the public cloud than we
can in our own data centers.”
Rob Alexander - CIO, Capital One

10. Access a deep set of cloud security tools
Virtual Private Cloud
Isolated cloud resources
Web Application Firewall
Filter Malicious Web Traffic
Shield
DDoS protection
Certificate Manager
Provision, manage, and
deploy SSL/TSL certificates
Networking
Key Management Service
Manage creation and control
of encryption keys
CloudHSM
Hardware-based key storage
Server-Side Encryption
Flexible data encryption
options
Encryption
IAM
Manage user access and
encryption keys
SAML Federation
SAML 2.0 support to allow
on-prem identity integration
Directory Service
Host and manage Microsoft
Active Directory
Organizations
Manage settings for multiple
accounts
Identity & Management
Service Catalog
Create and use standardized
products
Config
Track resource inventory and
changes
CloudTrail
Track user activity and API
usage
CloudWatch
Monitor resources and
applications
Inspector
Analyze application security
Artifact
Self-service for AWS’
compliance reports
Compliance

11. More assurance programs than anyone
Certifications /
Attestations
C5 [Germany], Cyber Essentials Plus [UK], DoD SRG, FedRAMP, FIPS, IRAP [Australia],
ISO 27001, ISO 27017, ISO 27018, ISO 9001, MLPS Level 3 [China],
MTCS Tier 3 [Singapore], PCI DSS Level 1, SEC Rule 17a-4(f), SOC 1, SOC 2, SOC 3
Laws,
Regulations,
and Privacy
DNB [Netherlands], DPA – 1998 [U.K.], EAR, EU Data Protection Directive,
EU Model Clauses, FERPA, Gramm-Leach-Bliley Act (GLBA), HIPAA, HITECH, IRS 1075,
ITAR, My Number Act [Japan], PDPA – 2010 [Malaysia], PDPA – 2012 [Singapore],
PIPEDA [Canada], Privacy Act [Australia], Privacy Act [New Zealand],
Spanish DPA Authorization, VPAT / Section 508
Alignments and
Frameworks
CIS, CJIS, CLIA, CMS Edge, CMSR, CSA, EU-US Privacy Shield, FISC [Japan], FISMA,
G-Cloud [U.K.], GxP (FDA CFR 21 Part 11), ICREA, IT Grundschutz [Germany], MITA 3.0,
MPAA, NIST, PHR, UK Cloud Security Principles, Uptime Institute Tiers

12. Global Enterprise Customers
General Electric Capital One BMW
Johnson &
Johnson Merck Nordstrom
“There is no public cloud infrastructure provider
that has more robust enterprise capabilities.”
Marc Benioff, Chairman & CEO, Salesforce

13. AWS Positioned as a Leader in the Gartner Magic Quadrant for Cloud
Infrastructure as a Service, Worldwide*
AWS is positioned
highest in execution
and furthest in vision
within the Leaders
Quadrant
*Gartner, Magic Quadrant for Cloud Infrastructure as a Service, Worldwide, Leong, Lydia, Petri, Gregor, Gill, Bob, Dorosh, Mike, August 32016
This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from AWS : http://www.gartner.com/doc/reprints?id=1-2G2O5FC&ct=150519&st=sb
Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as
statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

14. AWS Positioned as a Leader in the Gartner Magic Quadrant for
Operational Database Management Systems*
*Gartner, Magic Quadrant for Public Cloud Storage Services, Worldwide, Bala, Raj, Chandrasekran, 26 July 2016
This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from AWS : http://www.gartner.com/doc/reprints?id=1-2IH2LGI&ct=150626&st=sb
Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as
statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

15. DBaaS report
“AWS not only has the
largest adoption of DBaaS, it also offers
the widest range of offerings to support
analytical, operational, and transactional
workloads.”
“AWS’s key strengths lay in its dynamic
scale, automated administration, flexibility
of database offerings, strong security,
and high-availability capabilities, which
make it a preferred choice for customers”
The Forrester Wave™ is copyrighted by Forrester Research, Inc. Forrester and Forrester Wave™ are trademarks of Forrester Research, Inc. The Forrester Wave™ is a graphical representation of
Forrester's call on a market and is plotted using a detailed spreadsheet with exposed scores, weightings, and comments. Forrester does not endorse any vendor, product, or service depicted in the
Forrester Wave. Information is based on best available resources. Opinions reflect judgment at the time and are subject to change.

16. The AWS Cloud
Eliminate costly technical debt and reallocate resources so
you can deliver high-value, revenue-generating projects faster.
Innovate faster and solidify your competitive advantage by
merging startup agility with enterprise experience and resources.
Reduce risk by focusing resources dedicated to security, compliance
and availability to the most important areas of your business.
"AWS is our trusted partner that is going to run our company for the next 140 years.”
Jim Fowler – CIO, General Electric

17. What is a
Large Scale Event?

18. What is a Large Scale Event
An event where you need more capacity than normally
allocated for a period of time
Typically from minutes to days, but could be a couple of
weeks
Often associated with a sudden surge of users
Hard to architect and provision for at a reasonable cost
Consumers get angry when it all goes wrong!

24. What is a Large Scale Event?
For you, it could be as simple as needing twice as much
capacity for a short promotion
Everyone’s Large Scale Event is different, but the
underlying concepts are the same

25. What Problems do you Face?
Unknown infrastructure requirements
• Cost?
Short duration of the event
• Massive investment in infrastructure that is otherwise idle or
underutilized
• Often tight deadlines to get the system live
Legacy system integration
Understanding system bahaviour, required metrics
Getting the right architecture
Finding the right talent

27. You Don’t Want This!

28. One question is
constant!

29. How do we scale,
especially the
database?

30. So let’s start from day
one, user one ( you )

31. Day One, User One
A single EC2 Instance
• With full stack on this host
• Web app
• Database
• Management
• Etc.
A single Elastic IP
Route53 for DNS
EC2
Instance
Elastic IP
Amazon
Route 53
User

32. “We’re gonna need a bigger box”
Simplest approach
Can now leverage PIOPs
High I/O instances
High memory instances
High CPU instances
High storage instances
Easy to change instance sizes
Will hit an endpoint eventually
x1.32xlarge
m4.large
t2.micro

33. Day One, User One:
We could potentially get to a
few hundred to a few
thousand depending on
application complexity and
traffic
No failover
No redundancy
Too many eggs in one
basket
EC2
Instance
Elastic IP
Amazon
Route 53
User

34. Day Two, User >1
First let’s separate out our
single host into more than one.
Web
Database
• Make use of a database
service?
Web
Instance
Database
Instance
Elastic IP
Amazon
Route 53
User

35. Start with the right
databases for the job

36. So decide wisely.
Look for the key
points of scale.

37. User >100
First let’s separate out our
single host into more than one.
Web
Database
• Use RDS to make your life
easier
Web
Instance
Elastic IP
RDS DB
Instance
Amazon
Route 53
User

38. User > 1000
Next let’s address our lack of
failover and redundancy issues
Elastic Load Balancing
Another web instance
• In another Availability Zone
Enable Amazon RDS multi-AZ
Web
Instance
RDS DB Instance
Active (Multi-AZ)
Availability Zone Availability Zone
Web
Instance
RDS DB Instance
Standby (Multi-AZ)
Elastic Load
Balancing
Amazon
Route 53
User

39. User >10 ks–100 ks
RDS DB Instance
Active (Multi-AZ)
Availability Zone Availability Zone
RDS DB Instance
Standby (Multi-AZ)
Elastic Load
Balancing
RDS DB Instance
Read Replica
RDS DB Instance
Read Replica
RDS DB Instance
Read Replica
RDS DB Instance
Read Replica
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Amazon
Route 53
User

40. This will take us pretty far
honestly, but we care about
performance and efficiency,
so let’s clean this up a bit

41. Shift Some Load Around
Let’s lighten the load on our
web and database instances
Move static content from the web
instance to Amazon S3 and
CloudFront
Move dynamic content from the
Elastic Load Balancing to
CloudFront
Move session/state and DB
caching to ElastiCache or
DynamoDB
Web
Instance
RDS DB Instance
Active (Multi-AZ)
Availability Zone
Elastic Load
Balancing
Amazon S3
Amazon
CloudFront
Amazon
Route 53
User
ElastiCache
Amazon
DynamoDB

42. User >500k+
Availability Zone
Amazon
Route 53
User
Amazon S3
Amazon
Cloudfront
Availability Zone
Elastic Load
Balancing
DynamoDB
RDS DB Instance
Read Replica
Web
Instance
Web
Instance
Web
Instance
ElastiCache RDS DB Instance
Read Replica
Web
Instance
Web
Instance
Web
Instance
ElastiCacheRDS DB Instance
Standby (Multi-AZ)
RDS DB Instance
Active (Multi-AZ)

43. Time to make some
radical improvements at
the web & app layers

44. SOAing
Move services into their own tiers
or modules. Treat each of these
as 100% separate pieces of your
infrastructure and scale them
independently.
Amazon.com and AWS do this
extensively! It offers flexibility and
greater understanding of each
component.

45. Loose Coupling Sets You Free!
The looser they're coupled, the bigger they scale
• Use independent components
• Design everything as a black box
• Decouple interactions
• Favor services with built in redundancy and scalability than
building your own
Controller A Controller B
Controller A Controller B
Q Q
Tight Coupling
Use Amazon SQS as Buffers
Loose Coupling

46. Users > 1 Million
RDS DB Instance
Active (Multi-AZ)
Availability Zone
Elastic Load
Balancer
RDS DB Instance
Read Replica
RDS DB Instance
Read Replica
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Amazon
Route 53
User
Amazon S3
Amazon
Cloudfront
Amazon
DynamoDB
Amazon SQS
ElastiCache
Worker
Instance
Worker
Instance
Amazon
CloudWatch
Internal App
Instance
Internal App
Instance
Amazon SES

47. The next big steps

48. From 5 to 10 Million Users
You may start to run into issues with your database around
contention on the write master.
How can you solve it?
Federation (splitting into multiple DBs based on function)
Sharding (splitting one data set up across multiple hosts)
Moving some functionality to other types of DBs (NoSQL)

49. Database Federation
• Split up databases by function or
purpose
• Harder to do cross-function
queries
• Essentially delays the need for
something like sharding or
NoSQL until much further down
the line
• Won’t help with single huge
functions or tables
ForumsDB
UsersDB
ProductsDB

50. Sharded Horizontal Scaling
• More complex at the
application layer
• ORM support can help
• No practical limit on
scalability
• Operational complexity and
sophistication
• Shard by function or key
space
• RDBMS or NoSQL
User ShardID
002345 A
002346 B
002347 C
002348 B
002349 A
A
B
C

51. Shifting Functionality to NoSQL
Similar in a sense to federation
Again, think about the earlier points for when you need NoSQL
vs SQL
Leverage hosted services like Amazon DynamoDB
Consider these use cases:
• Leaderboards and scoring
• Rapid ingest of clickstream or log data
• Temporary data needs (cart data)
• “Hot” tables
• Metadata or lookup tables
Amazon
DynamoDB

52. From 5 to 10 Million Users
You may start to run into issues with speed and performance of
your applications
Make sure you have monitoring, metrics, & logging in place
• If you can’t build it internally, outsource it! (third-party SaaS)
Pay attention to what customers are saying works well vs.
what doesn’t, and use this as direction
Try to work on squeezing as much performance out of each
service or component

53. Customer Examples

54. Gumi Asia: Singaporean
Gaming Company

55. Sizing for Peak Loads
Promotions cause huge spikes in user activity
Auto-scaling works for the web and middle tier
RDS instances have to be sized for peak loads
Adopted our recommendations in a staged approach

56. Amazon
Route 53
CloudFront
Availability Zone #1
Amazon S3
Availability Zone #2
Amazon EC2Amazon EC2
Auto Scaling
Geo Routing
US East
Amazon
CloudWatch
RDS DB Instance
Active (Multi-AZ)
RDS DB Instance
Standby (Multi-AZ)
User

57. Amazon
Route 53
CloudFront
Availability Zone #1
Amazon S3
Availability Zone #2
Amazon EC2Amazon EC2
Auto Scaling
Geo Routing
US East
User
Amazon
CloudWatch
RDS DB Instance
Active (Multi-AZ)
RDS DB Instance
Standby (Multi-AZ)
RDS DB
instance read
replica

58. Amazon
Route 53
CloudFront
Availability Zone #1
Amazon S3
DynamoDB
Availability Zone #2
Amazon EC2Amazon EC2
Auto Scaling
Geo Routing
US East
User
Amazon
CloudWatch
RDS DB Instance
Active (Multi-AZ)
RDS DB Instance
Standby (Multi-AZ)
RDS DB
instance read
replica

59. Amazon
Route 53
CloudFront
Availability Zone #1
Amazon S3
DynamoDB
Availability Zone #2
Amazon EC2
ElastiCache
Memcached
Amazon EC2
Auto Scaling
Geo Routing
US East
User
Amazon
CloudWatch
RDS DB Instance
Active (Multi-AZ)
RDS DB Instance
Standby (Multi-AZ)
RDS DB
instance read
replica

60. Amazon
Route 53
CloudFront
Availability Zone #1
Amazon S3
DynamoDB
Availability Zone #2
Amazon EC2
ElastiCache
(Redis Master)
ElastiCache
Memcached
Amazon EC2
Redis Slave
Auto Scaling
Geo Routing
US East
User
Amazon
CloudWatch
RDS DB Instance
Active (Multi-AZ)
RDS DB Instance
Standby (Multi-AZ)
RDS DB
instance read
replica
Amazon Redshift

61. Lessons Learned
Listen to AWS Business Development and Solution
Architects ;)
Gaming promotions much easier to handle
Unpredicted loads also easier to handle
Senior operations person moving to a new game
Customers get a much better gaming experience!

62. Singaporean Telco

63. Customer Success Stories
Telecommunications Company
iPhone 5s/5c, 6/6+, 7 and Samsung Note 3-8 and S4-8
Needed a system to handle a huge number of concurrent
requests
Failed previously at the iPhone5 launch
Management directive to succeed at all costs!

64. Telco
Availability Zone
Elastic Load
Balancer
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Amazon
Route 53
User
Amazon S3
Amazon
Cloudfront
Amazon
DynamoDB
ElastiCache
Amazon
CloudWatch
ElastiCache

65. Great Success!
Tested with 150,000 concurrent users
All phones gone within 2 minutes
No phones misallocated or unallocated
Management said the system was too fast!
Actual launch went smoothly

66. Lessons
AWS can provide infrastructure for applications to scale to
very high concurrent users
Managed services allow for quick deployment and changes
to infrastructure
Impossible for the customer to execute internally
Massive cost savings, even with huge over provisioning
New, improved system now developed for iPhone 8

67. “With our systems on AWS, we
can scale our resources more
than 130-fold in 30 minutes,
enabling us to support more
than 2,500 orders per second”
KT Chiu
Founder and Chief Executive Officer
TixCraft

68. A Modern Data Architecture for
Microservices

69. What to Expect from the Session
• Microservices at Amazon
• Overview and Challenges
• Key Elements and Benefits
• Two Pizza Teams
• Data Architecture Challenges
• Transactions and Rollbacks
• Streams
• Master Data Management
• Choosing a Data Store
• Aggregation

70. Microservices at Amazon

71. Microservices at Amazon
Service-Oriented Architecture
(SOA)
Single-purpose
Connect only through APIs
Connect over HTTPS
“Microservices”

72. Monolithic vs. SOA vs. Microservices
Microservices:
Many very small components
Business logic lives inside of
single service domain
Simple wire protocols(HTTP
with XML/JSON)
API driven with SDKs/Clients
SOA:
Fewer more sophisticated
components
Business logic can live across
domains
Enterprise Service Bus like
layers between services
Middleware

73. Monolithic vs. SOA vs. Microservices
SOA
Coarse-grained
Microservices
Fine-grained
Monolithic
Single Unit

74. Microservice Challenges
Distributed computing is hard
Transactions
• Multiple Databases across multiple services
Eventual Consistency
Lots of moving parts
Service discovery
Increase coordination
Increase message routing

75. Key Elements of Microservices…
Some core concepts are common to all services
• Service registration, discovery, wiring, administration
• State management
• Service metadata
• Service versioning
• Caching
Low Friction Deployment
Automated Management and Monitoring

76. Key Elements of Microservices…
Eliminates any long-term commitment to a technology stack
Polyglot ecosystem
Polyglot persistence
• Decompose Databases
• Database per microservice pattern
Allows easy use of Canary and Blue-Green deployments

77. Key Elements of Microservices…
Each microservice is:
• Elastic: scales up or down independently of other services
• Resilient: services provide fault isolation boundaries
• Composable: uniform APIs for each service
• Minimal: highly cohesive set of entities
• Complete: loosely coupled with other services
Controller A Controller B
Controller A Controller B
Q Q
Tight Coupling
Loose Coupling

78. Microservices Benefits
Fast to develop
Rapid deployment
Parallel development & deployment
Closely integrated with DevOps
• Now ”DevSecOps”
Improved scalability, availability & fault tolerance
More closely aligned to business domain

79. Two-pizza teams
Full ownership
Full accountability
Aligned incentives
“DevOps”
Principles of the Two Pizza Team

80. How do Two Pizza Teams work?
We call them “Service teams”
Own the “primitives” they build:
• Product planning (roadmap)
• Development work
• Operational/Client support work
“You build it, you run it”
Part of a larger concentrated org (Amazon.com, AWS,
Prime, etc)

81. Data Architecture Challenges

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

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

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

85. 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
• Rollback on failure
ERROR
STATE?
ROLLBACK?

86. 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”

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

88. 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
Microservice

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

90. 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)

91. Challenge: Code Error
Lambda Execution Error because of
faulty 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

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

93. 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)

94. Choosing a Datastore

95. Storage & DB options in AWS
Amazon
RDS
Amazon
DynamoDB
Amazon
Elasticsearch
Service
Amazon
S3
Amazon
Kinesis
Amazon
ElastiCache
In-Memory NoSQL SQL SearchObject Streaming
Amazon
Redshift
Amazon
Glacier

96. Service

97. Challenge: What Service to Use?
Many problems can be solved with NoSQL, RDBMS or
even in-memory cache technologies
Non-functional requirements can help identify appropriate
services
Solution: Classify your organizations non-functional
requirements and map them to service capabilities

98. Determine Your Non-Functional Requirements
Requirement
Latency > 1s 200 ms -1s 20 ms – 200 ms < 20 ms
Durability 99.99 99.999 99.9999 > 99.9999
Storage Scale < 256 GB 256 GB – 1 TB 1 TB – 16 TB > 16 TB
Availability 99 99.9 99.95 > 99.95
Data Class Public Important Secret Top Secret
Recoverability 12 – 24 hours 1 – 12 hours 5 mins – 1 hour < 5 mins
Skills None Average Good Expert
This is only an example. Your company’s classifications will be different
There will be other requirements such as regulatory compliance too.

99. Map Non-Functional Requirements to Services
Service Latency Durability Storage Availability Recoverability from AZ Failure
(RPO, RTO)
RDS
< 100 ms > 99.8 (EBS) 6 TB (SQL
Server 16 TB)
99.95 0s and 90s (MAZ)
Aurora < 100 ms > 99.9 64 TB > 99.95 0s and < 30s (MAZ)
Aurora + ElastiCache < 1 ms > 99.9 64 TB > 99.95 0s and < 30s (MAZ)
DynamoDB < 10 ms > 99.9 No Limit > 99.99 0s and 0s
DynamoDB / DAX < 1 ms > 99.9 No Limit > 99.99 0s and 0s
ElastiCache Redis < 1 ms N/A 3.5 TiB 99.95 0s and < 30s (MAZ)
Elasticsearch < 200 ms > 99.9 150 TB 99.95 0s and < 30s (Zone Aware)
S3 < 500 ms 99.999999999 No Limit 99.99 0s and 0s
The information below is not exact and does not represent SLAs

100. Finalizing Your Data Store Choices
After mapping your non-functional requirements to services you
should have a short list to choose from
Functional requirements such as geospatial data and query support
will refine the list further
You may institute standards to make data store selection simpler and
also make it easier for people to move between teams, e.g Redis over
Memcached and PostgreSQL over MySQL. These can still be
overridden, but require justification to senior management

101. Challenge: Reporting and Analytics
Data is now spread across a number of isolated polyglot
data stores
Consolidation and aggregation required
Solution: Pull data from required microservices, push
data to data aggregation service, use pub/sub, or use a
composite service (anti-pattern).

102. Aggregation
usr svc
Pull model
Data Aggregation
Application
account svc cart svc
Pull

103. Aggregation
usr svc
Pull model Push model
Data Aggregation
Application
account svc cart svc
usr svc
account svc
cart svc
Data
Aggregation
Application
Push
Pull

104. Aggregation
usr svc
Pull model Push model
Data Aggregation
Application
usr svc
Data
Aggregation
Application
Pub/Sub
account svc cart svc
account svc
cart svc
Pub Sub
usr svc
account svc
cart svc
Data
Aggregation
Application
Push
Pull

105. Aggregation
usr svc
Pull model Push model
Data Aggregation
Application
usr svc
Data
Aggregation
Application
Pub/Sub Composite
Composite Data Service
usr account cart
account svc cart svc
account svc
cart svc
Pub Sub
usr svc
account svc
cart svc
Data
Aggregation
Application
Push
Pull

106. A Few Thoughts
Use Non-Functional Requirements to help identify the
right data store(s) for each microservice
Use polyglot persistence to avoid bottlenecks, schema
issues and allow independent scalability (and cache)
Embrace eventual consistency and design fault-tolerant
business processes which can recover
Think ahead and plan your analytics requirements as
part of the overall architecture

107. Learn from our Customers

108. Beware of Costs
Many microservices with redundant, isolated data stores
can blow out costs
One customer in India with 300 microservices is now
looking at costs reduction
Primary, standby, read replicas and cache per microservice
with databases using PIOPs storage
Great performance, scale and resilience, but expensive

109. Invest in Governance and Architecture
Giving each team independence is empowering
However, architects still need to understand the core
components of the distributed system and enforce
standards
An Indonesian customer is changing to microservices now,
but doesn’t have governance, architecture or standards in
place
Debugging distributed system is already proving complex
Standard logging, error handing and oversight will help