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? Join us in this talk as Yan Cui shares his thought experiments, and actual experiments, in his pursuit to understand how we can apply the principles of chaos to a serverless architecture.

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

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

3. Offices in London and Katowice

4. Offices in London and Katowice
WE’RE HIRING!
https://bit.ly/2HfLzGE

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

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

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

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

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

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

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

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

17. http://principlesofchaos.org

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

19. this is not a
steady state

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

21. explore unknown unknowns
away from production

22. treat production with the
care it deserves

23. the goal is NOT,
to actually hurt production

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

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

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

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

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

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

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

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

35. communication

36. ensure everyone knows what you’re doing

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

38. communication
Timing

39. run experiments during office hours

40. avoid important dates

41. communication
Timing
contain Blast radius

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

43. rollback at the first sign of
TROUBLE!

44. communication
Timing
contain Blast radius

45. Don’t try to run before you
know how to walk.

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

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

50. there is no server…

51. there is no server…
that you can kill

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

55. smaller units of deployment
and A LOT more of them!

56. more difficult to harden
around boundaries
serverful
serverless

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

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

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

60. serverful
serverless
more configurations,
more opportunities for misconfiguration

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

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

63. improperly tuned timeouts

64. missing error handling

65. missing fallback when downstream is unavailable

66. LATENCY INJECTION

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

68. what metrics do you monitor?

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

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

71. API Gateway

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

73. use short timeout for API calls

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

75. fixed timeout are tricky to get right…

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

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

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

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

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

87. report custom metrics

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

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

93. where to inject latency?

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

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

98. what’s the blast radius?

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

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

103. large blast radius, risky..

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

106. not priming developers to
build more resilient systems

107. development

108. development
production

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

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

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

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

119. how to inject latency?

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

121. https://theburningmonk.com/2015/04/design-for-latency-issues/

122. manually crafted wrapper library

128. configured in SSM Parameter Store

130. no injected latency

132. with injected latency

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

140. ERROR INJECTION

141. failures are INEVITABLE

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

146. vaccinate your serverless
architecture against failures

147. Offices in London and Katowice
WE’RE HIRING!
https://bit.ly/2HfLzGE

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

149. @theburningmonk
theburningmonk.com
github.com/theburningmonk