Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Beware the potholes on the road to serverless

853 views

Published on

Looking in from the outside, serverless seems so simple! And yet, many companies are struggling on their journey to serverless. In this talk, I highlight a number of mistakes companies are making when they adopt serverless.

Published in: Technology

Beware the potholes on the road to serverless

  1. 1. MIND THE POTHOLES MIND THE POTHOLES
  2. 2. @theburningmonk theburningmonk.com Jan 24th, 2007
  3. 3. we’re getting a new server in 3 months time
  4. 4. yay! about time! hooray!! finally!
  5. 5. but we have to decide what dependencies to install on it now..
  6. 6.
  7. 7. @theburningmonk theburningmonk.com on premise VMs in the cloud
  8. 8. @theburningmonk theburningmonk.com on premise VMs in the cloud abstraction level
  9. 9. @theburningmonk theburningmonk.com on premise VMs in the cloud abstraction levelproductivity
  10. 10. @theburningmonk theburningmonk.com on premise VMs in the cloud abstraction levelproductivity
  11. 11. @theburningmonk theburningmonk.com less is more
  12. 12. @theburningmonk theburningmonk.com
  13. 13. @theburningmonk theburningmonk.com
  14. 14. @theburningmonk theburningmonk.com right?
  15. 15. @theburningmonk theburningmonk.com
  16. 16. @theburningmonk theburningmonk.com “why are we failing at this?”
  17. 17. @theburningmonk theburningmonk.com hidden dangers
  18. 18. @theburningmonk theburningmonk.com monolith microservices serverless
  19. 19. @theburningmonk theburningmonk.com monolith microservices serverless observability distributed systems bounded context
  20. 20. @theburningmonk theburningmonk.com monolith microservices serverless observability distributed systems bounded context
  21. 21. @theburningmonk theburningmonk.com monolith microservices serverless observability distributed systems bounded context event driven
  22. 22. @theburningmonk theburningmonk.com monolith serverless missing learnings from microservices
  23. 23. @theburningmonk theburningmonk.com monolith serverless missing learnings from microservices poor decisions
  24. 24. Yan Cui http://theburningmonk.com @theburningmonk AWS user for 10 years
  25. 25. http://bit.ly/yubl-serverless
  26. 26. Yan Cui http://theburningmonk.com @theburningmonk Developer Advocate @
  27. 27. enter the code “belfast60” for 60 days free access to Lumigo
  28. 28. Yan Cui http://theburningmonk.com @theburningmonk Independent Consultant advisetraining delivery
  29. 29. https://theburningmonk.com/courses
  30. 30. #1 not letting go of legacy thinking
  31. 31. @theburningmonk theburningmonk.com “we’re doing serverless, but why aren’t thing going faster?”
  32. 32. @theburningmonk theburningmonk.com Socio Technical
  33. 33. @theburningmonk theburningmonk.com there are no silver bullets
  34. 34. @theburningmonk theburningmonk.com
  35. 35. @theburningmonk theburningmonk.com centralised team Team A Team B Team C Team D …
  36. 36. @theburningmonk theburningmonk.com “but the developers don’t understand AWS and how our infrastructure is set up”
  37. 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. 38. @theburningmonk theburningmonk.com what got you here won’t get you there
  39. 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. 40. @theburningmonk theburningmonk.com GET /user POST /user DELETE /user Single-Purposed Functions
  41. 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. 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 find related functions by prefix
  43. 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. 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. 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. 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. 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. 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)
  49. 49. @theburningmonk theburningmonk.com
  50. 50. @theburningmonk theburningmonk.com more dependecies equals slower cold start
  51. 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. 52. @theburningmonk theburningmonk.com keep functions simple, and single-purposed
  53. 53. #2 one account that rules them all
  54. 54. @theburningmonk theburningmonk.com mind the shared limits
  55. 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 filters no. of SSM parameters … Resource Limits
  56. 56. @theburningmonk theburningmonk.com DynamoDB read & write API Gateway requests/second Lambda concurrent executions SSM parameter ops/second … Throughput Limits
  57. 57. @theburningmonk theburningmonk.com
  58. 58. @theburningmonk theburningmonk.com compartmentalise security breaches
  59. 59. @theburningmonk theburningmonk.com One account per Team per Environment
  60. 60. @theburningmonk theburningmonk.com
  61. 61. @theburningmonk theburningmonk.com https://github.com/OlafConijn/AwsOrganizationFormation
  62. 62. @theburningmonk theburningmonk.com https://github.com/OlafConijn/AwsOrganizationFormation
  63. 63. @theburningmonk theburningmonk.com https://github.com/OlafConijn/AwsOrganizationFormation Accounts Org Units SCPs Pwd Policies Multi-Region Pseudo-Funs Init & Validate CI/CD
  64. 64. #3 do first, research later
  65. 65. @theburningmonk theburningmonk.com https://einaregilsson.com/serverless-15-percent-slower-and-eight-times-more-expensive/
  66. 66. @theburningmonk theburningmonk.com
  67. 67. @theburningmonk theburningmonk.com
  68. 68. @theburningmonk theburningmonk.com
  69. 69. @theburningmonk theburningmonk.com the platforms need to do better at educating users on how to choose between different services
  70. 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. 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. 72. https://medium.com/theburningmonk-com/all-my-posts-on-serverless-aws-lambda-43c17a147f91
  73. 73. https://www.jeremydaly.com/newsletter/
  74. 74. #4 not using a deployment toolkit
  75. 75. @theburningmonk theburningmonk.com
  76. 76. @theburningmonk theburningmonk.com https://lumigo.io/blog/comparison-of-lambda-deployment-frameworks
  77. 77. @theburningmonk theburningmonk.com don’t write your own deployment framework
  78. 78. #5 one repo per function
  79. 79. @theburningmonk theburningmonk.com github repo github repo github repo github repo github repo github repo github repo github repo github repo
  80. 80. @theburningmonk theburningmonk.com github repo github repo github repo github repo github repo github repo github repo github repo github repo
  81. 81. @theburningmonk theburningmonk.com monorepo?
  82. 82. @theburningmonk theburningmonk.com github repo
  83. 83. @theburningmonk theburningmonk.com one repo per service?
  84. 84. @theburningmonk theburningmonk.com github repo github repo github repo github repo user-api timeline-api relationship-api search-api
  85. 85. @theburningmonk theburningmonk.com https://lumigo.io/blog/mono-repo-vs-one-per-service/
  86. 86. @theburningmonk theburningmonk.com
  87. 87. @theburningmonk theburningmonk.com
  88. 88. @theburningmonk theburningmonk.com
  89. 89. @theburningmonk theburningmonk.com
  90. 90. @theburningmonk theburningmonk.com
  91. 91. @theburningmonk theburningmonk.com
  92. 92. @theburningmonk theburningmonk.com
  93. 93. @theburningmonk theburningmonk.com github repo github repo github repo github repo user-api timeline-api relationship-api search-api
  94. 94. @theburningmonk theburningmonk.com one CI/CD pipeline per service
  95. 95. @theburningmonk theburningmonk.com functions are deployed together, as a stack
  96. 96. unencrypted secrets in env vars #6
  97. 97. @theburningmonk theburningmonk.com secrets should NEVER be in plain text in env variables
  98. 98. @theburningmonk theburningmonk.com SSM Parameter Store Secret 1 Secret 2 IAM Environment: SECRET_1: … SECRET_2: … Environment: SECRET_1: … SECRET_2: …
  99. 99. @theburningmonk theburningmonk.com SSM Parameter Store Secret 1 Secret 2 IAM Environment: SECRET_1: … SECRET_2: … Environment: SECRET_1: … SECRET_2: … yay!
  100. 100. @theburningmonk theburningmonk.com
  101. 101. @theburningmonk theburningmonk.com
  102. 102. @theburningmonk theburningmonk.com SSM Parameter Store Secret 1 Secret 2 IAM fetch at cold start, cache, invalidate every x mins
  103. 103. @theburningmonk theburningmonk.com https://github.com/middyjs/middy
  104. 104. @theburningmonk theburningmonk.com
  105. 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. 106. not following least privilege principle #7
  107. 107. too much/too little concurrency #8
  108. 108. @theburningmonk theburningmonk.com “Lambda generates too much load for the downstream system”
  109. 109. @theburningmonk theburningmonk.com one invocation per message SNS Lambda
  110. 110. @theburningmonk theburningmonk.com Downstream System SNS Lambda
  111. 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. 112. @theburningmonk theburningmonk.com if you want… maximum throughput SNS precise control over throughput Kinesis
  113. 113. @theburningmonk theburningmonk.com if you want… maximum throughput SNS precise control over throughput Kinesis how quickly it scales out
  114. 114. @theburningmonk theburningmonk.com if you want… maximum throughput SNS precise control over throughput Kinesis how quickly it scales out SQS DynamoDB Streams
  115. 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. 116. @theburningmonk theburningmonk.com #1 not letting go of legacy thinking #2 one account that rules them all #3 do first, 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. 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. 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. 119. @theburningmonk theburningmonk.com Production-Ready Serverless
  120. 120. @theburningmonk theburningmonk.com bit.ly/prod-ready-sls-dublin-2020 20% off with sls-belfast-0124
  121. 121. @theburningmonk theburningmonk.com github.com/theburningmonk

×