Debunking serverless myths

1. Debunking Serverless Myths Yan Cui @theburningmonk

2. Yan Cui http://theburningmonk.com @theburningmonk AWS user for 10 years

3. http://bit.ly/yubl-serverless

4. Yan Cui http://theburningmonk.com @theburningmonk Developer Advocate @

5. Yan Cui http://theburningmonk.com @theburningmonk Independent Consultant

6. What do you mean by ‘serverless’?

7. “Serverless”

8. Gojko Adzic It is serverless the same way WiFi is wireless. http://bit.ly/2yQgwwb

9. Serverless means… don’t pay for it if no-one uses it don’t need to worry about scaling don’t need to provision and manage servers

10. “Function-as-a-Service” AWS Lambda Azure Functions Google Cloud Functions Auth0 Webtask Spotinst Functions Kubeless IBM Cloud Functions

11. AWS Lambda

12. AWS Lambda API Gateway IOT SNS Kinesis CloudWatch

13. IaaS Function Application Runtime Container OS Virtualization Hardware CaaS Function Application Runtime Container OS Virtualization Hardware PaaS Function Application Runtime Container OS Virtualization Hardware FaaS Function Application Runtime Container OS Virtualization Hardware User User (scalable unit) Provider

14. IaaS Function Application Runtime Container OS Virtualization Hardware CaaS Function Application Runtime Container OS Virtualization Hardware PaaS Function Application Runtime Container OS Virtualization Hardware FaaS Function Application Runtime Container OS Virtualization Hardware User User (scalable unit) Provider

15. Serverless FaaS other services… Database Storage BI

16. Simon Wardley Serverless will fundamentally change how we build business around technology and how you code.

17. Why serverless?

18. more Scalable (and scales faster!)

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

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

21. Secure

22. idea production choose language + framework master language + framework figure out deployment configure AMI configure ELB configure autoscaling capacity planning over-provision for launch are we doing microservices? configure CI/CD

24. idea production greater Velocity from idea to product

25. minimise undifferentiated heavy-lifting

26. less ops responsibility on your shoulders

27. What about containers?

28. important, but invisible subsystem

29. https://read.acloud.guru/acg-faas-and-furious-b9574b6675c5

30. serverless is NOT the goal!

31. build products customers love to use

32. test ideas against the market quickly

33. iterate on s

34. deliver frequently, deliver quickly

35. own less technology, focus on creating Business Values

36. own less technology, focus on creating Business Values (serverless is just a good ﬁt for this mindset)

37. serverless technologies are still maturing

38. DEBUNKING SERVERLESS MYTHS

39. DEBUNKING SERVERLESS MYTHS COLD STARTS COLD STARTS overplays or underplays the role of cold starts on serverless performance MYTH #1

40. DEBUNKING SERVERLESS MYTHS COLD STARTS COLD STARTS overplays or underplays the role of cold starts on serverless performance MYTH #1 COSTSCOSTS misunderstands thereal cost savings fromadopting serverless MYTH #2

41. DEBUNKING SERVERLESS MYTHS COLD STARTS COLD STARTS overplays or underplays the role of cold starts on serverless performance MYTH #1 COSTSCOSTS misunderstands thereal cost savings fromadopting serverless MYTH #2 CONTROL not realise that control of infra requires expensive skillsets to manage MYTH #3 CONTROL

42. DEBUNKING SERVERLESS MYTHS COLD STARTS COLD STARTS overplays or underplays the role of cold starts on serverless performance MYTH #1 COSTSCOSTS misunderstands thereal cost savings fromadopting serverless MYTH #2 CONTROL not realise that control of infra requires expensive skillsets to manage MYTH #3 CONTROL LOCK-INnot realise that lock-in risk rewards productivity, and true lock-in is dataMYTH #4 LOCK-IN

43. COLD STARTSCOLD STARTS overplays or underplays the role of cold starts on serverless performance MYTH #1 LOCK-IN not realise that lock-in risk rewards productivity, and true lock-in is data MYTH #4 LOCK-INCONTROL not realise that control of infra requires expensive skillsets to manage MYTH #3 CONTROLCOSTSCOSTS misunderstands the real cost savings from adopting serverless MYTH #2

44. INITIALISE CONTAINER INITIALISE RUNTIME INITIALISE HANDLER YOUR CODE EXECUTES

45. INITIALISE CONTAINER INITIALISE RUNTIME INITIALISE HANDLER YOUR CODE EXECUTES COLD START

46. “cold starts only happen to the ﬁrst request”

47. function invocationconcurrent execution i.e. a container

48. function invocationconcurrent execution i.e. a container class instance method call

49. Lambda scales the number of concurrent executions based on trafﬁc

50. existing “containers” are reused where possible

51. time invocation

52. time invocation invocation

53. time invocation invocation

54. time invocation invocation invocation invocation

55. time invocation invocation invocation invocation invocation invocation

56. time invocation invocation invocation invocation invocation invocation

57. time invocation invocation invocation invocation invocation invocation invocation

58. time invocation invocation invocation invocation invocation invocation invocation invocation

61. FREQUENCY DURATION

62. FREQUENCY DURATION dictated by user trafﬁc, out of your control

63. FREQUENCY DURATION optimize this!

64. “Lambda is not a suitable solution for me because of cold starts”

65. “what is your latency requirement?”

66. cold starts that don’t add to user-facing latency is generally not worth worrying about

67. Node.js functions, no VPC, 1GB, averages ~500ms cold start with production workload

68. Node.js functions, no VPC, 1GB, averages ~500ms cold start with production workload (good enough for most web applications)

69. sporadic spikes latency existed before Lambda

70. GC pauses…

71. overloaded servers…

72. slow downstream, databases, etc.

73. networking issues…

74. cold starts is generally not an issue if you have a steady trafﬁc pattern

75. time req/s

76. time req/s El Classico

77. time req/s lunch dinner

78. minimise the duration of cold starts so they fall within acceptable latency range

79. use higher memory setting if function performs CPU intensive work

80. use Node.js, Python or Golang

81. trim dependencies

82. keep functions single-purposed

83. avoid VPCs (for now) unless you need to access VPC-protected resources

84. COSTSCOSTS misunderstands the real cost savings from adopting serverless MYTH #2 LOCK-IN not realise that lock-in risk rewards productivity, and true lock-in is data MYTH #4 LOCK-INCONTROL not realise that control of infra requires expensive skillsets to manage MYTH #3 CONTROL

85. “good luck when Amazon decides to raise the price of Lambda!”

86. mind the market force…

87. AWS announced 67 price reductions in the last 5 years, and 0 price hikes

88. Model Training Low-latency Prediction Serving via Batching

89. https://einaregilsson.com/serverless-15-percent-slower-and-eight-times-more-expensive/

90. the platforms need to do better at educating users on how to choose between different services

91. https://aws.amazon.com/solutions/case-studies/financial-engines/

92. https://www.doc.ic.ac.uk/~rbc/papers/fse-serverless-17.pdf “This paper presents two case industrial studies of early adopters, showing how migrating an application to the Lambda deployment architecture reduced hosting costs – by between 66% and 95%…”

93. what we can easily measure

94. what most of your budget is spent on

95. what businesses care about what we can easily measure what most of your budget is spent on

96. leverage: do more with less

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

99. Serverless might cost you just as much, or even more, but you get so much more done

100. 6 developers, 6 months 95% saving against EC2 15x no. of production releases per month

101. CONTROL not realise that control of infra requires expensive skillsets to manage MYTH #3 CONTROL LOCK-IN not realise that lock-in risk rewards productivity, and true lock-in is data MYTH #4 LOCK-IN

102. Control Responsibility

103. Controlling your own infrastructure comes with Responsibilities

104. to take on these responsibilities you need to have the relevant skillsets in the organization Controlling your own infrastructure comes with Responsibilities

105. to take on these responsibilities you need to have the relevant skillsets in the organization Controlling your own infrastructure comes with Responsibilities ENGINEERS

106. to take on these responsibilities you need to have the relevant skillsets in the organization Controlling your own infrastructure comes with Responsibilities ENGINEERS ADMIN

107. to take on these responsibilities you need to have the relevant skillsets in the organization Controlling your own infrastructure comes with Responsibilities ENGINEERS ADMIN RECRUITMENT

108. to take on these responsibilities you need to have the relevant skillsets in the organization Controlling your own infrastructure comes with Responsibilities ENGINEERS ADMIN RECRUITMENT MARKET

109. what are you paying for?

110. guard against the temptation to look for control for control sake

111. AWS Lambda, Azure Functions, Google Cloud Functions Your custom, container-based, general purpose compute platform

112. LOCK-IN not realise that lock-in risk rewards productivity, and true lock-in is data MYTH #4 LOCK-IN

113. Lock-in risk Reward

114. it’s not a lock-in, it’s a form of coupling that has a switching cost

115. “vendor lock-in” switching cost

116. “vendor lock-in” switching cost “let’s avoid lock-in” prevention cost

117. The true danger with lock-in, especially with serverless, is the potential for data lock-in. Data has gravity. It accumulates. Data is economically disincentivized to leave, by way of platform pricing. This is the single biggest threat to vendor choice.

118. Newton’s 41st law: data has gravity

119. Newton’s 42nd law: data migration is gonna suck

120. https://martinfowler.com/articles/oss-lockin.html

121. “VENDOR LOCK-IN IS THE ROOT OF ALL EVIL”

122. to take on these responsibilities you need to have the relevant skills sets in the organization Controlling your own infrastructure comes with Responsibilities ENGINEERS ADMIN RECRUITMENT MARKET

123. if you already have the expertise, can their time be better used to generate more business value instead?

124. risk is just one side of the coin

125. extracting maximum value from your cloud provider minimising undifferentiated heavy-lifting faster time-to-market reward

126. own less technology, focus on creating Business Values

127. is vendor lock-in a risk? YES

128. is the return worth the risk? ABSOLUTELY!

129. there are no silver bullets

130. understand the trade-offs

131. control comes with its own baggages

132. but sometimes the beneﬁts outweigh the baggages

133. https://theburningmonk.com/hire-me AdviseTraining Delivery “Fundamentally, Yan has improved our team by increasing our ability to derive value from AWS and Lambda in particular.” Nick Blair Tech Lead

134. @theburningmonk theburningmonk.com github.com/theburningmonk