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.

Serverless in production, an experience report (Going Serverless)

264 views

Published on

In this talk Yan Cui shares his experience of migrating an existing monolithic architecture for a social network to AWS Lambda, and how it empowered a small team to deliver features quickly and how they address operational concerns such as CI/CD, logging, monitoring and config management.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Serverless in production, an experience report (Going Serverless)

  1. 1. in production an experience reportan experience report what you should know before you go to production ServerlessServerless
  2. 2. Yan Cui http://theburningmonk.com @theburningmonk AWS user since 2009
  3. 3. Yan Cui http://theburningmonk.com @theburningmonk
  4. 4. Domas Lasauskas
  5. 5. Domas Lasauskas AWS user since 2012
  6. 6. apr, 2016
  7. 7. hey guys, vote on this post and I’ll announce a winner at 10PM tonight
  8. 8. 10PM traffic
  9. 9. 10PM traffic 70-100x
  10. 10. low utilisation to leave room for spikes EC2 scaling is slow, so scale earlier
  11. 11. lots of $$$ for unused resources
  12. 12. up to 30 mins for deployment deployment required downtime
  13. 13. - Dan North “lead time to someone saying thank you is the only reputation metric that matters.”
  14. 14. “what would good look like for us?”
  15. 15. be small be fast have zero downtime have no lock-step DEPLOYMENTS SHOULD...
  16. 16. FEATURES SHOULD... be deployable independently be loosely-coupled
  17. 17. WE WANT TO... minimise cost for unused resources minimise ops effort reduce tech mess deliver visible improvements faster
  18. 18. nov, 2016
  19. 19. 170 Lambda functions in prod 1.2 GB deployment packages in prod 95% cost saving vs EC2 15x no. of prod releases per month
  20. 20. time is a good fit
  21. 21. 1st function in prod! time is a good fit
  22. 22. ? time is a good fit 1st function in prod!
  23. 23. ALERTING CI / CD TESTING LOGGING MONITORING
  24. 24. Practices ToolsPrinciples what is good? how to make it good? with what?
  25. 25. Principles outlast Tools
  26. 26. 170 functions ? ? time is a good fit 1st function in prod!
  27. 27. SECURITY DISTRIBUTED TRACING CONFIG MANAGEMENT
  28. 28. evolving the PLATFORM
  29. 29. rebuilt search
  30. 30. Legacy Monolith Amazon Kinesis Amazon Lambda Amazon CloudSearch
  31. 31. Legacy Monolith Amazon Kinesis Amazon Lambda Amazon CloudSearchAmazon API Gateway Amazon Lambda
  32. 32. new analytics pipeline
  33. 33. Legacy Monolith Amazon Kinesis Amazon Lambda Google BigQuery
  34. 34. Legacy Monolith Amazon Kinesis Amazon Lambda Google BigQuery 1 developer, 2 days design production (his 1st serverless project)
  35. 35. Legacy Monolith Amazon Kinesis Amazon Lambda Google BigQuery “nothing ever got done this fast at Skype!” - Chris Twamley
  36. 36. - Dan North “lead time to someone saying thank you is the only reputation metric that matters.”
  37. 37. Rebuilt with Lambda
  38. 38. Rebuilt with Lambda
  39. 39. BigQuery
  40. 40. BigQuery
  41. 41. grapheneDB BigQuery
  42. 42. grapheneDB BigQuery
  43. 43. grapheneDB BigQuery
  44. 44. getting PRODUCTION READY
  45. 45. choose a tried-and-tested deployment framework, don’t invent your own
  46. 46. http://serverless.com
  47. 47. https://github.com/awslabs/serverless-application-model
  48. 48. http://apex.run
  49. 49. https://apex.github.io/up
  50. 50. https://github.com/claudiajs/claudia
  51. 51. https://github.com/Miserlou/Zappa
  52. 52. http://gosparta.io/
  53. 53. TESTING
  54. 54. amzn.to/29Lxuzu
  55. 55. Level of Testing 1.Unit do our objects do the right thing? are they easy to work with?
  56. 56. Level of Testing 1.Unit 2.Integration does our code work against code we can’t change?
  57. 57. handler
  58. 58. handler test by invoking the handler
  59. 59. Level of Testing 1.Unit 2.Integration 3.Acceptance does the whole system work?
  60. 60. Level of Testing unit integration acceptance feedback confidence
  61. 61. “…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
  62. 62. “…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
  63. 63. Don’t Mock Types You Can’t Change Services
  64. 64. Paul Johnston The serverless approach to testing is different and may actually be easier. http://bit.ly/2t5viwK
  65. 65. LambdaAPI Gateway DynamoDB
  66. 66. LambdaAPI Gateway DynamoDB Unit Tests
  67. 67. LambdaAPI Gateway DynamoDB Unit Tests Mock/Stub
  68. 68. is our request correct? is the request mapping set up correctly?is the API resources configured correctly? are we assuming the correct schema? LambdaAPI Gateway DynamoDB is Lambda proxy configured correctly? is IAM policy set up correctly? is the table created? what unit tests will not tell you…
  69. 69. most Lambda functions are simple have single purpose, the risk of shipping broken software has largely shifted to how they integrate with external services observation
  70. 70. optimize towards shipping working software, even if it means slowing down your feedback loop…
  71. 71. …if a service can’t provide you with a relatively easy way to test the interface in reality, then you should consider using another one. Paul Johnston
  72. 72. “…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
  73. 73. Legacy Monolith Amazon Kinesis Amazon Lambda Amazon CloudSearchAmazon API Gateway Amazon Lambda
  74. 74. Legacy Monolith Amazon Kinesis Amazon Lambda Amazon CloudSearchAmazon API Gateway Amazon Lambda Test Input
  75. 75. Legacy Monolith Amazon Kinesis Amazon Lambda Amazon CloudSearchAmazon API Gateway Amazon Lambda Test Input Validate
  76. 76. integration tests exercise system’s Integration with its external dependencies my code
  77. 77. acceptance tests exercise system End-to-End from the outside my code
  78. 78. integration tests differ from acceptance tests only in HOW the Lambda functions are invoked observation
  79. 79. CI + CD PIPELINE
  80. 80. me the earlier you consider CI/CD the more time you save in the long run
  81. 81. “…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
  82. 82. me deployment scripts that only live on the CI box is a disaster waiting to happen…
  83. 83. Jenkins build config deploys and tests unit + integration tests deploy acceptance tests
  84. 84. if [ "$1" = "deploy" ] && [ $# -eq 4 ]; then STAGE=$2 REGION=$3 PROFILE=$4 npm install AWS_PROFILE=$PROFILE 'node_modules/.bin/sls' deploy -s $STAGE -r $REGION elif [ "$1" = "int-test" ] && [ $# -eq 4 ]; then STAGE=$2 REGION=$3 PROFILE=$4 npm install AWS_PROFILE=$PROFILE npm run int-$STAGE elif [ "$1" = "acceptance-test" ] && [ $# -eq 4 ]; then STAGE=$2 REGION=$3 PROFILE=$4 npm install AWS_PROFILE=$PROFILE npm run acceptance-$STAGE else usage exit 1 fi
  85. 85. if [ "$1" = "deploy" ] && [ $# -eq 4 ]; then STAGE=$2 REGION=$3 PROFILE=$4 npm install AWS_PROFILE=$PROFILE 'node_modules/.bin/sls' deploy -s $STAGE -r $REGION elif [ "$1" = "int-test" ] && [ $# -eq 4 ]; then STAGE=$2 REGION=$3 PROFILE=$4 npm install AWS_PROFILE=$PROFILE npm run int-$STAGE elif [ "$1" = "acceptance-test" ] && [ $# -eq 4 ]; then STAGE=$2 REGION=$3 PROFILE=$4 npm install AWS_PROFILE=$PROFILE npm run acceptance-$STAGE else usage exit 1 fi install Serverless framework as dev dependency
  86. 86. if [ "$1" = "deploy" ] && [ $# -eq 4 ]; then STAGE=$2 REGION=$3 PROFILE=$4 npm install AWS_PROFILE=$PROFILE 'node_modules/.bin/sls' deploy -s $STAGE -r $REGION elif [ "$1" = "int-test" ] && [ $# -eq 4 ]; then STAGE=$2 REGION=$3 PROFILE=$4 npm install AWS_PROFILE=$PROFILE npm run int-$STAGE elif [ "$1" = "acceptance-test" ] && [ $# -eq 4 ]; then STAGE=$2 REGION=$3 PROFILE=$4 npm install AWS_PROFILE=$PROFILE npm run acceptance-$STAGE else usage exit 1 fi install Serverless framework as dev dependency mitigate version conflicts
  87. 87. http://alistair.cockburn.us/Hexagonal+architecture
  88. 88. build.sh allows repeatable builds on both local & CI
  89. 89. Auto Auto Manual
  90. 90. LOGGING
  91. 91. 2016-07-12T12:24:37.571Z 994f18f9-482b-11e6-8668-53e4eab441ae GOT is off air, what do I do now?
  92. 92. 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
  93. 93. me Logs are not easily searchable in CloudWatch Logs.
  94. 94. CloudWatch Logs
  95. 95. CloudWatch Logs AWS Lambda ELK stack
  96. 96.
  97. 97. CloudWatch Events
  98. 98. DISTRIBUTED TRACING
  99. 99. a user my followers didn’t receive my new post!
  100. 100. where could the problem be?
  101. 101. correlation IDs* * eg. request-id, user-id, yubl-id, etc.
  102. 102. wrap HTTP client & AWS SDK clients to forward captured correlation IDs
  103. 103. kinesis client http client sns client
  104. 104. use X-Ray for performance tracing
  105. 105. Amazon X-Ray
  106. 106. Amazon X-Ray
  107. 107. X-Ray traces do not span over API Gateway, or async event sources
  108. 108. MONITORING + ALERTING
  109. 109. no place to install agents/daemons
  110. 110. • invocation Count • error Count • latency • throttling • granular to the minute • support custom metrics
  111. 111. • same metrics as CW • better dashboard • support custom metrics https://www.datadoghq.com/blog/monitoring-lambda-functions-datadog/
  112. 112. my code
  113. 113. my code
  114. 114. my code internet internet press button something happens
  115. 115. those extra 10-20ms for sending custom metrics would compound when you have microservices and multiple APIs are called within one slice of user event
  116. 116. Amazon found every 100ms of latency cost them 1% in sales. http://bit.ly/2EXPfbA
  117. 117. no more background processing, other than what the platform provides
  118. 118. console.log(“hydrating yubls from db…”); console.log(“fetching user info from user-api”); console.log(“MONITORING|1489795335|27.4|latency|user-api-latency”); console.log(“MONITORING|1489795335|8|count|yubls-served”); timestamp metric value metric type metric namemetrics logs
  119. 119. CloudWatch Logs AWS Lambda ELK stack logs metrics CloudWatch
  120. 120. don’t forget to setup dashboards & CW alarms
  121. 121. CONFIG MANAGEMENT
  122. 122. design for easy & quick propagation of config changes
  123. 123. me Environment variables make it hard to share configurations across functions.
  124. 124. me Environment variables make it hard to implement fine-grained access to sensitive info.
  125. 125. config service goes here
  126. 126. SSM Parameter Store
  127. 127. sensitive data should be encrypted in-flight, and at-rest
  128. 128. enforce role-based access to sensitive configuration values
  129. 129. SSM Parameter Store HTTPS role-based access encrypted in-flight
  130. 130. SSM Parameter Store encrypt role-based access
  131. 131. SSM Parameter Store encrypted at-rest
  132. 132. HTTPS role-based access SSM Parameter Store encrypted in-flight
  133. 133. invest into a robust client library
  134. 134. fetch & cache at cold-start
  135. 135. invalidate at interval & weak signals
  136. 136. That’s it, folks! Thank you all :-D
  137. 137. API Gateway and Kinesis Authentication & authorisation (IAM, Cognito) Testing Running & Debugging functions locally Log aggregation Monitoring & Alerting X-Ray Correlation IDs CI/CD Performance and Cost optimisation Error Handling Configuration management VPC Security Leading practices (API Gateway, Kinesis, Lambda) Canary deployments http://bit.ly/production-ready-serverless get 40% off with: ytcui
  138. 138. @theburningmonk theburningmonk.com github.com/theburningmonk

×