The document outlines a talk by Yan Cui on building a social network using AWS serverless architecture, highlighting the transition from a legacy monolith to a microservices approach. It emphasizes the benefits of serverless solutions, including significant cost savings, faster deployment times, and improved user experience through efficient resource management and independent feature deployment. Key topics cover design patterns, CI/CD practices, and the importance of scalability in event-driven architectures.

1. MANCHESTER

2. How to build a social
network with serverless
AWS CREATIVE STUDIO | 2018

3. Yan Cui
http://theburningmonk.com
@theburningmonk
Principal Engineer @
Independent Consultant
Instructor @
Instructor @
Advisor @

4. “Netflix for sports”
offices in London, Leeds, Katowice and Amsterdam

8. available in Austria, Switzerland, Germany,
Japan, Italy, Spain, Canada and USA
available on 30+ platforms

9. ~1,000,000 concurrent viewers

10. “Netflix for sports”
offices in London, Leeds, Katowice and Amsterdam
We’re hiring! Visit
engineering.dazn.com to
learn more.
follow @dazneng for updates
about the engineering team.
WE’RE HIRING!

13. apr, 2016

14. nov, 2016

15. WHY?

17. hey guys, vote on this post
and I’ll announce a winner at
10PM tonight

18. 10PM
traffic

19. 10PM
traffic
70-100x

20. low utilisation to leave room for spikes
EC2 scaling is slow, so scale earlier

21. lots of $$$ for unused resources

22. up to 30 mins for deployment
deployment required downtime

23. features took months to develop

24. - Dan North
“lead time to someone saying
thank you is the only reputation
metric that matters.”

26. WHY?
to deliver better UX

27. WHY?
to deliver better UX
to deliver value faster

28. WHY?
to deliver better UX
to deliver value faster
to be more cost efficient

29. WHY?
to deliver better UX
to deliver value faster
to be more cost efficient
HOW?

30. what would good look like for us?

31. small
fast
zero downtime
no lock-step
deployments should be…

32. features should be…
deployable independently
loosely-coupled

33. we want to…
minimise cost for unused resources

34. we want to…
minimise cost for unused resources
minimise ops effort

35. we want to…
minimise cost for unused resources
minimise ops effort
reduce tech mess

36. we want to…
minimise cost for unused resources
minimise ops effort
reduce tech mess
deliver visible improvements faster

37. WHY?
to deliver better UX
to deliver value faster
to be more cost efficient
HOW?
microservices

38. WHY?
to deliver better UX
to deliver value faster
to be more cost efficient
HOW?
microservices
event-driven

39. WHY?
to deliver better UX
to deliver value faster
to be more cost efficient
HOW?
microservices
event-driven
serverless

40. WHY?
to deliver better UX
to deliver value faster
to be more cost efficient
HOW?
microservices
event-driven
serverless
WHAT?
this talk!

41. WHY?
to deliver better UX
to deliver value faster
to be more cost efficient
HOW?
microservices
event-driven
serverless
WHAT?
this talk!

42. 170 Lambda functions in prod

43. 95% cost saving vs. EC2

44. 15x no. of prod releases per month

45. 15x no. of prod releases per month
(features were sometimes implemented on the same day)

46. time
is a good fit

47. 1st function in prod!
time
is a good fit

48. ?
time
is a good fit
1st function in prod!

49. CI/CD?

50. CI/CD?
testing?

51. CI/CD?
testing?
logging, monitoring, alerting?

52. time
is a good fit
1st function in prod!
CI/CD, testing, logging,
monitoring, alerting

53. 170 functions
?
time
is a good fit
1st function in prod!
CI/CD, testing, logging,
monitoring, alerting

54. tracing?

55. tracing?
config management?

56. tracing?
config management?
security?

57. 170 functions
time
is a good fit
1st function in prod!
CI/CD, testing, logging,
monitoring, alerting
tracing, config
management, security

58. API Gateway and Kinesis
Authentication & authorisation (IAM, Cognito)
Testing
Running & Debugging functions locally
Log aggregation
Monitoring & Alerting
X-Ray
Correlation IDs
CI/CD
Performance and Cost optimisation
Error Handling
Configuration management
VPC
Security
Leading practices (API Gateway, Kinesis, Lambda)
Canary deployments
http://bit.ly/production-ready-serverless
get 40% off
with: ytcui

59. evolving the PLATFORM

60. Legacy Monolith Amazon Kinesis
Step 1.
ALL state changes!

61. events are an enabler for
COMPOSABILITY

62. AWS LAMBDA
is the...

63. Kinesis

64. Kinesis
API Gateway AWS Lambda API GatewayAWS Lambda
service-A service-B

65. Kinesis
API Gateway AWS Lambda API GatewayAWS Lambda
service-A service-B

66. Kinesis
API Gateway AWS Lambda API GatewayAWS Lambda
service-A service-B
AWS Lambda
AWS Lambda
AWS Lambda

67. Kinesis
API Gateway AWS Lambda API GatewayAWS Lambda
service-A service-B
AWS Lambda
AWS Lambda
AWS Lambda DynamoDBIOT

68. Kinesis
API Gateway AWS Lambda API GatewayAWS Lambda
service-A service-B
AWS Lambda
AWS Lambda
AWS Lambda DynamoDBIOT

69. Kinesis
API Gateway AWS Lambda API GatewayAWS Lambda
service-A service-B
AWS Lambda
AWS Lambda
AWS Lambda DynamoDBIOT
AWS Lambda AWS Lambda

70. build loosely-coupled system
through events

71. service A service B
service C service D
bounded context
bounded context

72. service A service B
service C service D
bounded context
bounded context

73. service A service B
service C service D

75. there are no silver bullets

76. service A service B
service C service D

77. service A service B
service C service D

78. service A service B
service C service D
update!

79. service A service B
service C service Dbackward-compatible?
update!

81. bounded context
DON’T use events to
orchestrate workflows
within the same
bounded context

82. bounded context
adds unnecessary
complexity to logging,
tracing, and end-to-end
reporting

83. bounded context
the workflow doesn’t exist
as a standalone concept,
but as the sum of a series of
loosely connected parts

84. Step Functions
use Step Functions instead

85. Step Functions
don’t forget to emit events
from the workflow

86. Step Functions
so others can react to state
changes that happened as
part of the workflow

87. “how do I organize my functions
into code repositories?”

88. monorepo?

89. github
repo

90. https://lumigo.io/blog/mono-repo-vs-one-per-service/

91. monorepo !== monostack

92. one repo per service?

100. github
repo
github
repo
github
repo
github
repo
user-api
timeline-api
relationship-api
search-api

101. CI/CD pipeline per service

102. functions are deployed
together, as a stack

103. Strangler Pattern
incrementally migrate the legacy system by
gradually replacing pieces of functionalities
to the new system

105. rebuilt search

106. Legacy Monolith Amazon Kinesis Amazon Lambda
Amazon CloudSearch

107. Legacy Monolith Amazon Kinesis Amazon Lambda
Amazon CloudSearchAmazon API Gateway Amazon Lambda

108. proxy requests from monolith
to new service

109. new analytics pipeline

110. expensive ($3000/month)
don’t understand our domain
JS based query language

111. Legacy Monolith Amazon Kinesis Amazon Lambda
Google BigQuery

112. Legacy Monolith Amazon Kinesis Amazon Lambda
Google BigQuery
1 developer, 2 days
design production
(his 1st serverless project)

113. Legacy Monolith Amazon Kinesis Amazon Lambda
Google BigQuery
“nothing ever got done
this fast at Skype!”
- Chris Twamley

114. - Dan North
“lead time to someone saying
thank you is the only reputation
metric that matters.”

115. $3000/month $0.03/month

117. Kinesis
sink

118. Kinesis Kinesis Firehose
batch Kinesis events

119. Kinesis Kinesis Firehose S3
data lake

120. Kinesis Kinesis Firehose S3
Glue
analyze data schema,
catalog data into tables

121. Kinesis Kinesis Firehose S3
Athena
Glue
query engine

122. Kinesis Kinesis Firehose S3
AthenaQuickSight
Glue
visualization, dashboards

123. Kinesis Kinesis Firehose S3
AthenaQuickSight
Glue
no code is required!

124. Kinesis Kinesis Firehose S3
AthenaQuickSight
Glue
no code is required!
pay-per-use!

125. user action business intelligence

126. user action business intelligence

129. Problem
didn’t work…

130. Problem
didn’t work…
over-engineered…

132. try figure out what’s
going on here…

133. Problem
didn’t work…
over-engineered…
didn’t scale…

135. Rebuilt
with Lambda

141. built-in retry
and DLQ

142. built-in retry
and DLQ
avoid repeating expensive
work of fetching mils of
relationships

146. github
repo
timeline-api
service: timeline-api
provider:
name: aws
runtime: nodejs6.10
stage: dev
region: us-east-1
functions:
distribute-yubl:
…
undistribute-yubl:
…

148. Problem
didn’t work…

149. “it returns the first 30 users in the
database, by creation time…”

151. Rebuilt
with Lambda

152. BigQuery

153. BigQuery

154. grapheneDB
BigQuery

155. grapheneDB
BigQuery

156. grapheneDB
BigQuery

157. grapheneDB
BigQuery
mostly built in one sleepless night…

158. Building a
scalable
notification
system

159. expensive ($3000/month)
don’t understand our domain
JS based query language

160. all the analytics data is
already in BigQuery
powerful query engine

161. all the analytics data is
already in BigQuery
powerful query engine

162. Design Goals
ad-hoc notifications

163. Design Goals
ad-hoc notifications
scheduled notifications

164. Design Goals
ad-hoc notifications
scheduled notifications
A/B testing

166. Design Goals
ad-hoc notifications
scheduled notifications
A/B testing
scalable

167. Design Goals
ad-hoc notifications
scheduled notifications
A/B testing
scalable
cost-effective

168. scheduled notifications

171. how to send notifications
what to send

172. other processes can leverage
this capability of sending
notifications

173. why not SNS?

174. ad-hoc notifications

175. Oversight vs. Frictionless

176. Oversight vs. Frictionless
don’t make life difficult for
the marketing team

177. Oversight vs. Frictionless
don’t make life difficult for
the marketing team
don’t let marketing
team spam users

178. Oversight vs. Frictionless
don’t make life difficult for
the marketing team
don’t let marketing
team spam users
driving usage/engagement
maintaining user experience

179. Marketing work with BI on query
request approval from CPO/CTO
approver checks impact and tests
message format
send notifications

191. more Scalable
(and scales faster!)

192. Cheaper
(don’t pay for idle servers)

193. Resilience
(built-in redundancy and multi-AZ)

194. Secure

195. request
blue-green deployment
req/s
auto-scaling
us-east-1a
us-east-1b
us-east-1c
multi-AZ

196. idea production
greater Velocity from idea to product

197. WHY?
to deliver better UX
to deliver value faster
to be more cost efficient

198. @theburningmonk
theburningmonk.com
github.com/theburningmonk