1. APPLYING PRINCIPLES
to SERVERLESSt
a
b
chaos engineering
of
A
E
S
of

2. history of Smallpox
est. 400K deaths per year in 18th Century Europe.
earliest evidence of disease in 3rd Century BC Egyptian Mummy

3. history of Smallpox
est. 400K deaths per year in 18th Century Europe.
earliest evidence of disease in 3rd Century BC Egyptian Mummy
1798
first vaccine developed
Edward Jenner

4. 1798
first vaccine developed
1980
history of Smallpox
Edward Jenner
WHO certified
global eradication
est. 400K deaths per year in 18th Century Europe.
earliest evidence of disease in 3rd Century BC Egyptian Mummy

6. Vaccination is the most effective method of
preventing infectious diseases

7. stimulates the immune system to recognize
and destroy the disease before contracting
the disease for real

8. Chaos Engineering
controlled experiments to help us learn about
our system’s behaviour and build confidence
in its ability to withstand turbulent conditions

9. Yan Cui
http://theburningmonk.com
@theburningmonk
Principal Engineer @

10. Yan Cui
http://theburningmonk.com
@theburningmonk
Principal Engineer @

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

14. available in Austria, Switzerland,
Germany, Japan, Canada and Italy
US coming soon ;-)

16. available on 30+ platforms

17. ~500,000 concurrent viewers

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

23. Why did you break
production?

24. Because I can!

25. Kolton Andrus, CEO of Gremlin
Russ Miles, CEO of ChaosIQ
Nora Jones, Chaos Engineer at Netflix

26. Kolton Andrus, CEO of Gremlin
Russ Miles, CEO of ChaosIQ
Nora Jones, Chaos Engineer at Netflix

28. it’s about building confidence,
NOT breaking things

30. http://principlesofchaos.org

31. STEP 1. define “Steady State”
aka. what does normal, working
condition looks like?

32. this is not a
steady state

33. STEP 2.
hypothesize steady state will
continue in both control group
& the experiment group
ie. you should have a reasonable degree of
confidence the system would handle the failure
before you proceed with the experiment

34. explore unknown unknowns
away from production

35. treat production with the
care it deserves

36. the goal is NOT,
to actually hurt production

37. If you know the system would break,
and you did it anyway…
then it’s NOT a chaos experiment.
It’s called being IRRESPONSIBLE.

39. STEP 3.
inject realistic failures
e.g. server crash, network error,
HD malfunction, etc.

40. https://github.com/Netflix/SimianArmy

41. https://github.com/Netflix/SimianArmy http://oreil.ly/2tZU1Sn

43. STEP 4.
disprove hypothesis
i.e. look for difference with steady state

44. if a WEAkNESS is uncovered,
IMPROVE it before the behaviour
manifests in the system at large

45. Chaos Engineering
controlled experiments to help us learn about
our system’s behaviour and build confidence
in its ability to withstand turbulent conditions

47. Chaos Engineering
controlled experiments to help us learn about
our system’s behaviour and build confidence
in its ability to withstand turbulent conditions

48. communication

49. ensure everyone knows what you’re doing

50. ensure everyone knows what you’re doing
NO surprises!

51. communication
Timing

52. run experiments during office hours

53. AVOID important dates

54. communication
Timing
contain Blast radius

55. smallest change that allows
you to detect a signal that
steady state is disrupted

56. rollback at the first sign of
TROUBLE!

57. communication
Timing
contain Blast radius

58. don’t try to run before you
know how to walk.

59. by Russ Miles @russmiles
source https://medium.com/russmiles/chaos-engineering-for-the-business-17b723f26361

60. chaos monkey kills an
EC2 instance
latency monkey induces
artificial delay in APIs
chaos gorilla kills an
AWS Availability Zone
chaos kong kills an
entire AWS region

63. there is no server…

64. there is no server…
that you can kill

67. there are more inherent chaos and
complexity in a Serverless architecture

68. smaller units of deployment
but A LOT more of them!

69. more difficult to harden
around boundaries
serverful
serverless

70. ?
SNS
Kinesis
CloudWatch
Events
CloudWatch
LogsIoT
DynamoDB
S3 SES

71. ?
SNS
Kinesis
CloudWatch
Events
CloudWatch
LogsIoT
DynamoDB
S3 SES
more intermediary services,
and greater variety too

72. ?
SNS
Kinesis
CloudWatch
Events
CloudWatch
LogsIoT
DynamoDB
S3 SES
more intermediary services,
and greater variety too
each with its own set of
failure modes

73. serverful
serverless
more configurations,
more opportunities for misconfiguration

74. more unknown failure modes in
infrastructure that we don’t control

75. often there’s little we can do when an
outage occurs in the platform

76. improperly tuned timeouts

77. missing error handling

78. missing fallback when downstream is unavailable

79. LATENCY INJECTION

80. STEP 1. define “Steady State”
aka. what does normal, working
condition looks like?

81. what metrics do you monitor?

82. 9X-percentile latency
error count
yield (% of requests completed)
harvest (completeness of results)

83. STEP 2.
hypothesize steady state will
continue in both control group
& the experiment group
ie. you should have a reasonable degree of
confidence the system would handle the failure
before you proceed with the experiment

84. API Gateway

85. consider the effect of cold-starts
& API Gateway overhead

86. use short timeout for API calls

87. the goal of a timeout strategy is to give HTTP
requests the best chance to succeed,
provided that doing so does not cause the
calling function itself to err

88. fixed timeout are tricky to get right…

89. fixed timeout are tricky to get right…
too short and you don’t
give requests the best
chance to succeed

90. fixed timeout are tricky to get right…
too long and you run the
risk of letting the request
timeout the calling function

91. and it gets worse when you make multiple
API calls in one function…

94. set the request timeout based on the
amount of invocation time left

99. log the timeout incident with
as much context as possible
e.g. timeout value, correlation IDs,
request object, …

100. report custom metrics

104. be mindful when you sacrifice precision for
availability, user experience is the king

105. STEP 3.
inject realistic failures
e.g. server crash, network error,
HD malfunction, etc.

106. where to inject latency?

107. hypothesis:
function has appropriate timeout on its HTTP
communications and can degrade gracefully
when these requests time out

109. should also be applied to 3rd parties
services we depend on, e.g. DynamoDB

111. what’s the blast radius?

112. http client
public-api-a
http client
public-api-b
internal-api

113. hypothesis:
all functions have appropriate timeout on
their HTTP communications to this internal
API, and can degrade gracefully when
requests are timed out

116. large blast radius, risky..

118. could be effective when used away from
production environment, to weed out
weaknesses quickly

119. not priming developers to
build more resilient systems

120. development

121. development
production

122. Priming (psychology):
Priming is a technique whereby exposure to one
stimulus influences a response to a subsequent
stimulus, without conscious guidance or intention.
It is a technique in psychology used to train a
person's memory both in positive and negative ways.

125. make dev environments better resemble the
turbulent conditions you should realistically
expect your system to survive in production

126. hypothesis:
the client app has appropriate timeout on
their HTTP communication with the server,
and can degrade gracefully when requests
are timed out

130. STEP 4.
disprove hypothesis
i.e. look for difference with steady state

131. how to inject latency?

132. static weaver (e.g. AspectJ, PostSharp),
or dynamic proxies

133. manually crafted wrapper library

139. configured in SSM Parameter Store

141. no injected latency

143. with injected latency

145. factory wrapper function
(think bluebird’s promisifyAll function)

151. ERROR INJECTION

152. failures are INEVITABLE

153. the only way to truly know your system’s
resilience against failures is to test it
through controlled experiments

157. vaccinate your serverless
architecture against failures

158. Yan Cui
http://theburningmonk.com
@theburningmonk

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