Lambda is the next stage in the evolution of the AWS platform. It allows you to build reactive, event-driven systems that are easy to deploy, update and scale. Amazon manages all the undifferentiated heavy-lifting for you so you can focus on delivering value to your customers with even greater speed and cost efficiency. Join Yan in this talk as we take a deep dive through AWS Lambda and the Serverless framework. We'll see how to start building reactive systems using AWS Lambda, Kinesis and API Gateway, without having to manage any servers. And, you only pay for your services when they are used. We'll discuss lessons learned, best practices and current limitations with AWS Lambda. We'll also get to know the Serverless framework, which helps automate both deployment and versioning so that you can better focus on the things that matter to your customers.

1. + =
THE FUTURE OF PAAS IS
SERVERLESS

2. hi, my name is Yan Cui
@theburningmonk

5. “as a Software Engineer,
what is my job?”

6. “to write code, of course!”
- Me, circa 2006

7. “to provide value to users &
stakeholders”
- Me, 2016

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

10. THE
BALANCE
COMPETING
FORCES

11. performance
security
scalability
simplicity
cost
team
time to market

12. “Programmers know
the benefits of
everything and the
tradeoffs of nothing.”
- Rich Hickey
https://www.infoq.com/presentations/Simple-Made-Easy

13. context is the king

16. security
complexity
OUTSIDE the code
deployment
load balancing
caching
monitoring
config management
https://www.infoq.com/presentations/complexity-simplicity-esb
centralised logging
elastic scaling
setup server

21. Leaky Abstraction

22. AWS re:invent 2014https://www.youtube.com/watch?v=9eHoyUVo-yg

23. AWS re:invent 2014https://www.youtube.com/watch?v=9eHoyUVo-yg
FAAS
(Function-As-A-Service)

25. THERE IS NO SERVER

26. cost saving

27. charged by
invocations

28. not paying for
idle servers

30. elastic scaling

32. hi guys,
come back at 10 to find
out who won!

33. everyone
came back at
exactly 10pm!

34. everyone
came back at
exactly 10pm!
Lambda scaled
instantly

35. minimise
undifferentiated
heavy-lifting

36. “what about containers?”

38. important, but
invisible subsystems

39. economy of scale

40. NoOps!!

41. reactive

47. simple, fast
deployment

48. first Lambda function went live
(team size : 4)

49. (team size : 7)
155 prod deployments!

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

51. easy to get
started

53. now, we stand at 170 Lambda
functions in prod, with 200+ in dev

54. fuelling
the Yubl
platform
evolution

55. My Beautiful Monolith

56. “What would a good
architecture for us look like?”

57. small, incremental deployments
fast deployments
no downtime
no lock-step deployments
features deployed independently
features loosely-coupled through messages
minimise cost for unused resources
minimise ops effort

58. oh, and do all these whilst continue
to deliver value, thanks :-)
love, your users

59. completely rebuilt search

60. Legacy Monolith Amazon Kinesis Amazon Lambda
Amazon CloudSearch

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

62. analytics pipeline

63. Legacy Monolith Amazon Kinesis Amazon Lambda
Google BigQuery

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

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

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

67. Rebuilt
with Lambda

74. Rebuilt
with Lambda

80. and many more…

81. “JavaScript doesn’t scale
well with complexity”
- People on the Internet

82. but

83. “limit complexity, and
JavaScript isn’t so bad”
- Me

84. USE A
DEPLOYMENT
FRAMEWORK

85. http://serverless.com

86. https://github.com/claudiajs/claudia

87. https://github.com/Miserlou/Zappa

88. http://gosparta.io/

89. http://bit.ly/2e7aNDv

90. TESTING

92. amzn.to/29Lxuzu

93. Level of Testing
1.Unit
do our objects do the right thing?
are they easy to work with?

95. Level of Testing
1.Unit
2.Integration
does our code work against code we
can’t change?

96. handler

97. handler
test by invoking
the handler

98. Level of Testing
1.Unit
2.Integration
3.Acceptance
does the whole system work?

99. Level of Testing
unit
integration
acceptance

100. Level of Testing
unit
integration
acceptance
can do all 3 with Lambda

101. “…We find that tests that mock external
libraries often need to be complex to
get the code into the right state for the
functionality we need to exercise.
The mess in such tests is telling us that
the design isn’t right but, instead of
fixing the problem by improving the
code, we have to carry the extra
complexity in both code and test…”
Don’t Mock Types You Can’t Change

102. “…The second risk is that we have to be
sure that the behaviour we stub or mock
matches what the external library will
actually do…
Even if we get it right once, we have to
make sure that the tests remain valid
when we upgrade the libraries…”
Don’t Mock Types You Can’t Change

103. Don’t Mock Types You Can’t Change
Services

104. “…Wherever possible, an acceptance
test should exercise the system end-to-
end without directly calling its internal
code.
An end-to-end test interacts with the
system only from the outside: through
its interface…”
Testing End-to-End

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

106. Legacy Monolith Amazon Kinesis Amazon Lambda
Amazon CloudSearchAmazon API Gateway Amazon Lambda
Test Input

107. Legacy Monolith Amazon Kinesis Amazon Lambda
Amazon CloudSearchAmazon API Gateway Amazon Lambda
Test Input
Validate

108. “…We prefer to have the end-to-end
tests exercise both the system and the
process by which it’s built and
deployed…
This sounds like a lot of effort (it is), but
has to be done anyway repeatedly
during the software’s lifetime…”
Testing End-to-End

109. Jenkins build config deploys and tests
unit + integration tests
deploy
acceptance tests

110. build.sh allows repeatable builds on both local & CI

111. LOGGING

113. 2016-07-12T12:24:37.571Z 994f18f9-482b-11e6-8668-53e4eab441ae
GOT is off air, what do I do now?

114. 2016-07-12T12:24:37.571Z 994f18f9-482b-11e6-8668-53e4eab441ae
GOT is off air, what do I do now?
UTC Timestamp API Gateway Request Id
your log message

115. organised by Function + Version

116. LOG OVERLOAD

117. centralise your logs

118. CloudWatch Logs AWS Lambda
LogStash ElasticSearch

119. CloudWatch Logs AWS Lambda
LogStash ElasticSearch
AWS Elasticsearch

120. CloudWatch Logs AWS Lambda
LogStash ElasticSearch
AWS Elasticsearch
Elastic Cloud

121. CloudWatch Logs AWS Lambda
LogStash ElasticSearch
AWS Elasticsearch
Elastic Cloud
?

122. correlation IDs

123. MONITORING

124. nowhere to install
monitoring agents

125. no time for
background tasks

126. • Invocation Count
• Error Count
• Latency (avg, min, max, sum)
• Throttling
• Granular to the minute
• Support custom metrics

127. • Same basic metrics
• Better dashboard
• Support custom metrics
https://www.datadoghq.com/blog/monitoring-lambda-functions-datadog/

129. Do It Yourself

130. PRO TIP
set up dashboards

131. PRO TIP
don’t forget to set
up alarms

132. PRO TIP
add application-level
metrics

133. KEEP
WARM

134. functions are unloaded if
idle for a while

135. noticeable cold start time
(package size matters)

136. CloudWatch Event AWS Lambda

137. CloudWatch Event AWS Lambda
ping
ping
ping
ping

138. CloudWatch Event AWS Lambda
ping
ping
ping
ping

139. CloudWatch Event AWS Lambda
ping
ping
ping
ping
HEALTH CHECKS?

140. KNOW YOUR LIMITS

141. max 50 MB deployment package size

142. max 50 MB deployment package size
max 75 GB total deployment package size*
* limit is per AWS region

143. Janitor Monkey

144. Janitor Lambda

145. max 5 mins execution time

147. max 6 MB request payload size*
max 6 MB response payload size
* for a request-response event type

148. default max 100 concurrent executions*
* soft-limit, can be raised via support ticket

149. CAPEX
OPEX

150. fail fast
fail cheaply

152. IBM OpenWhisk
Amazon Lambda Azure Web Functions
Google Cloud Functions
competition
faster innovation
lower prices

155. @theburningmonk
@theburningmonk
theburningmonk.com
github.com/theburningmonk

156. @theburningmonk
@theburningmonk
theburningmonk.com
github.com/theburningmonk
slides at http://bit.ly/2ecqEql