Beware the potholes on the road to serverless

1. MIND THE POTHOLES MIND THE POTHOLES

2. @theburningmonk theburningmonk.com Jan 24th, 2007

3. we’re getting a new server in 3 months time

4. yay! about time! hooray!! ﬁnally!

5. but we have to decide what dependencies to install on it now..

6. …

7. @theburningmonk theburningmonk.com on premise VMs in the cloud

8. @theburningmonk theburningmonk.com on premise VMs in the cloud abstraction level

9. @theburningmonk theburningmonk.com on premise VMs in the cloud abstraction levelproductivity

10. @theburningmonk theburningmonk.com on premise VMs in the cloud abstraction levelproductivity

11. @theburningmonk theburningmonk.com less is more

12. @theburningmonk theburningmonk.com

14. @theburningmonk theburningmonk.com right?

16. @theburningmonk theburningmonk.com “why are we failing at this?”

17. @theburningmonk theburningmonk.com hidden dangers

18. @theburningmonk theburningmonk.com monolith microservices serverless

19. @theburningmonk theburningmonk.com monolith microservices serverless observability distributed systems bounded context

20. @theburningmonk theburningmonk.com monolith microservices serverless observability distributed systems bounded context

21. @theburningmonk theburningmonk.com monolith microservices serverless observability distributed systems bounded context event driven

22. @theburningmonk theburningmonk.com monolith serverless missing learnings from microservices

23. @theburningmonk theburningmonk.com monolith serverless missing learnings from microservices poor decisions

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

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

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

27. enter the code “belfast60” for 60 days free access to Lumigo

28. Yan Cui http://theburningmonk.com @theburningmonk Independent Consultant advisetraining delivery

29. https://theburningmonk.com/courses

30. #1 not letting go of legacy thinking

31. @theburningmonk theburningmonk.com “we’re doing serverless, but why aren’t thing going faster?”

32. @theburningmonk theburningmonk.com Socio Technical

33. @theburningmonk theburningmonk.com there are no silver bullets

35. @theburningmonk theburningmonk.com centralised team Team A Team B Team C Team D …

36. @theburningmonk theburningmonk.com “but the developers don’t understand AWS and how our infrastructure is set up”

37. @theburningmonk theburningmonk.com “but the developers don’t understand AWS and how our infrastructure is set up” let’s solve this problem instead!

38. @theburningmonk theburningmonk.com what got you here won’t get you there

39. @theburningmonk theburningmonk.com if (path == “/user” && method == “GET”) { return getUser(…); } else if (path == “/user” && method == “DELETE”) { return deleteUser(…); } else if (path == “/user” && method == “POST”) { return createUser(…); } else if …. Monolithic Functions

40. @theburningmonk theburningmonk.com GET /user POST /user DELETE /user Single-Purposed Functions

41. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user

42. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user ﬁnd related functions by preﬁx

43. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user discoverability (without having to dig into the code)

44. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user what does it do?

45. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user dynamodb:GetItem dynamodb:PutItem dynamodb:DeleteItem

46. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user dynamodb:GetItem dynamodb:PutItem dynamodb:DeleteItem no least privilege…

47. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user require(x) require(y) require(z)

48. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user require(x) require(y) require(z)

50. @theburningmonk theburningmonk.com more dependecies equals slower cold start

51. @theburningmonk theburningmonk.com author: yan.cui feature: user-api user-api-dev Monolithic Single-Purposed author: yan.cui feature: user-api user-api-dev-get-user author: yan.cui feature: user-api user-api-dev-create-user author: yan.cui feature: user-api user-api-dev-delete-user require(x) require(y) require(z) worse cold start performance

52. @theburningmonk theburningmonk.com keep functions simple, and single-purposed

53. #2 one account that rules them all

54. @theburningmonk theburningmonk.com mind the shared limits

55. @theburningmonk theburningmonk.com no. of DynamoDB tables no. of API Gateway regional APIs no. of API Gateway edge-optimized APIs no. of Kinesis shards no. of IAM roles no. of S3 buckets no. of CloudFormation stacks no. of SNS subscription ﬁlters no. of SSM parameters … Resource Limits

56. @theburningmonk theburningmonk.com DynamoDB read & write API Gateway requests/second Lambda concurrent executions SSM parameter ops/second … Throughput Limits

58. @theburningmonk theburningmonk.com compartmentalise security breaches

59. @theburningmonk theburningmonk.com One account per Team per Environment

61. @theburningmonk theburningmonk.com https://github.com/OlafConijn/AwsOrganizationFormation

62. @theburningmonk theburningmonk.com https://github.com/OlafConijn/AwsOrganizationFormation

63. @theburningmonk theburningmonk.com https://github.com/OlafConijn/AwsOrganizationFormation Accounts Org Units SCPs Pwd Policies Multi-Region Pseudo-Funs Init & Validate CI/CD

64. #3 do first, research later

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

69. @theburningmonk theburningmonk.com the platforms need to do better at educating users on how to choose between different services

70. @theburningmonk theburningmonk.com SNS vs SQS vs Kinesis vs MKS? the platforms need to do better at educating users on how to choose between different services

71. ordering replay events Kinesis SQS SNS by shard none (standard) global (FIFO) none up to 7 days none none mode retry batched batched (up to 10) singular retried until success (customizable) retry + DLQ retry + DLQ concurrency 1 per shard auto-scaled fan-out!!! subscribers many one-to-one many EventBridge many none none singular retry + DLQ fan-out!!!

72. https://medium.com/theburningmonk-com/all-my-posts-on-serverless-aws-lambda-43c17a147f91

73. https://www.jeremydaly.com/newsletter/

74. #4 not using a deployment toolkit

76. @theburningmonk theburningmonk.com https://lumigo.io/blog/comparison-of-lambda-deployment-frameworks

77. @theburningmonk theburningmonk.com don’t write your own deployment framework

78. #5 one repo per function

79. @theburningmonk theburningmonk.com github repo github repo github repo github repo github repo github repo github repo github repo github repo

80. @theburningmonk theburningmonk.com github repo github repo github repo github repo github repo github repo github repo github repo github repo

81. @theburningmonk theburningmonk.com monorepo?

82. @theburningmonk theburningmonk.com github repo

83. @theburningmonk theburningmonk.com one repo per service?

84. @theburningmonk theburningmonk.com github repo github repo github repo github repo user-api timeline-api relationship-api search-api

85. @theburningmonk theburningmonk.com https://lumigo.io/blog/mono-repo-vs-one-per-service/

93. @theburningmonk theburningmonk.com github repo github repo github repo github repo user-api timeline-api relationship-api search-api

94. @theburningmonk theburningmonk.com one CI/CD pipeline per service

95. @theburningmonk theburningmonk.com functions are deployed together, as a stack

96. unencrypted secrets in env vars #6

97. @theburningmonk theburningmonk.com secrets should NEVER be in plain text in env variables

98. @theburningmonk theburningmonk.com SSM Parameter Store Secret 1 Secret 2 IAM Environment: SECRET_1: … SECRET_2: … Environment: SECRET_1: … SECRET_2: …

99. @theburningmonk theburningmonk.com SSM Parameter Store Secret 1 Secret 2 IAM Environment: SECRET_1: … SECRET_2: … Environment: SECRET_1: … SECRET_2: … yay!

102. @theburningmonk theburningmonk.com SSM Parameter Store Secret 1 Secret 2 IAM fetch at cold start, cache, invalidate every x mins

103. @theburningmonk theburningmonk.com https://github.com/middyjs/middy

105. @theburningmonk theburningmonk.com SSM Parameter Store Secret 1 Secret 2 IAM switch to Higher Throughput if you need more than 40 ops/s

106. not following least privilege principle #7

107. too much/too little concurrency #8

108. @theburningmonk theburningmonk.com “Lambda generates too much load for the downstream system”

109. @theburningmonk theburningmonk.com one invocation per message SNS Lambda

110. @theburningmonk theburningmonk.com Downstream System SNS Lambda

111. @theburningmonk theburningmonk.com ordering replay events Kinesis SQS SNS by shard none (standard) global (FIFO) none up to 7 days none none mode retry batched batched (up to 10) singular retried until success (customizable) retry + DLQ retry + DLQ concurrency 1 per shard auto-scaled fan-out!!! subscribers many one-to-one many EventBridge many none none singular retry + DLQ fan-out!!!

112. @theburningmonk theburningmonk.com if you want… maximum throughput SNS precise control over throughput Kinesis

113. @theburningmonk theburningmonk.com if you want… maximum throughput SNS precise control over throughput Kinesis how quickly it scales out

114. @theburningmonk theburningmonk.com if you want… maximum throughput SNS precise control over throughput Kinesis how quickly it scales out SQS DynamoDB Streams

115. @theburningmonk theburningmonk.com ordering replay events Kinesis SQS SNS by shard none (standard) global (FIFO) none up to 7 days none none mode retry batched batched (up to 10) singular retried until success (customizable) retry + DLQ retry + DLQ concurrency 1 per shard auto-scaled fan-out!!! subscribers many one-to-one many EventBridge many none none singular retry + DLQ fan-out!!!

116. @theburningmonk theburningmonk.com #1 not letting go of legacy thinking #2 one account that rules them all #3 do ﬁrst, research later #4 not using a deployment framework #5 one repo per function #6 unencrypted secrets in env vars #7 not following least privilege principle #8 too much/too little concurrency

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

118. @theburningmonk theburningmonk.com https://theburningmonk.com/workshops Amsterdam, March 19-20 Helsinki, May 4-5 Stockholm, May 14-15 Dublin, June 16-17 London, September 24-25 Berlin, October 8-9

119. @theburningmonk theburningmonk.com Production-Ready Serverless

120. @theburningmonk theburningmonk.com bit.ly/prod-ready-sls-dublin-2020 20% off with sls-belfast-0124

121. @theburningmonk theburningmonk.com github.com/theburningmonk