Chaos engineering is a discipline that focuses on improving system resilience through experiments that expose the inherent chaos and failure modes in our system, in a controlled fashion, before these failure modes manifest themselves like a wildfire in production and impact our users. Netflix is undoubtedly the leader in this field, but much of the publicised tools and articles focus on killing EC2 instances, and the efforts in the serverless community has been largely limited to moving those tools into AWS Lambda functions. But how can we apply the same principles of chaos to a serverless architecture built around AWS Lambda functions? These serverless architectures have more inherent chaos and complexity than their serverful counterparts, and, we have less control over their runtime behaviour. In short, there are far more unknown unknowns with these systems. Can we adapt existing practices to expose the inherent chaos in these systems? What are the limitations and new challenges that we need to consider?

1. applying principles of chaos
engineering to serverless

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 Tokyo

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

16. available on 30+ platforms

17. ~500,000 concurrent viewers

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

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

23. I’m gonna inject
you with a deadly
disease now

24. http://principlesofchaos.org

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

26. this is not a
steady state

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

28. explore unknown unknowns
away from production

29. treat production with the
care it deserves

30. the goal is NOT,
to actually hurt production

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

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

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

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

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

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

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

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

42. communication

43. ensure everyone knows what you’re doing

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

45. communication
Timing

46. run experiments during office hours

47. AVOID important dates

48. communication
Timing
contain Blast radius

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

50. rollback at the first sign of
TROUBLE!

51. communication
Timing
contain Blast radius

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

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

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

57. there is no server…

58. there is no server…
that you can kill

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

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

63. more difficult to harden
around boundaries
serverful
serverless

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

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

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

67. serverful
serverless
more configurations,
more opportunities for misconfiguration

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

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

70. improperly tuned timeouts

71. missing error handling

72. missing fallback when downstream is unavailable

73. LATENCY INJECTION

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

75. what metrics do you monitor?

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

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

78. API Gateway

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

80. use short timeout for API calls

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

82. fixed timeout are tricky to get right…

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

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

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

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

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

94. report custom metrics

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

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

100. where to inject latency?

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

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

105. what’s the blast radius?

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

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

110. large blast radius, risky..

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

113. not priming developers to
build more resilient systems

114. development

115. development
production

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

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

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

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

125. how to inject latency?

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

127. manually crafted wrapper library

133. configured in SSM Parameter Store

135. no injected latency

137. with injected latency

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

145. ERROR INJECTION

146. failures are INEVITABLE

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

151. vaccinate your serverless
architecture against failures

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

153. @theburningmonk
theburningmonk.com
github.com/theburningmonk

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

155. 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 code:
ytcui