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.

Empowering businesses with serverless

1,284 views

Published on

Serverless technologies allow developers to go faster and do so much more with less. They allow businesses to innovate faster than ever possible before and the pay-per-use pricing model opens up a world of opportunities to improve cost efficiency. Cost optimization is no longer a guessing game, but a surgical operation that can target business areas with the most saving potential based on data. New business models based on pay-per-use will soon disrupt incumbents in established markets and create better value for customers. In this talk, we'll see how businesses around the world are using serverless technologies to drive their success and growth, and the lessons we can learn from them.

Published in: Technology
  • Be the first to comment

Empowering businesses with serverless

  1. 1. EMPOWERING businesses with # s e r v e r l e s s Yan Cui, @theburningmonk ServerlessDays ROME, 21.02.20
  2. 2. @theburningmonk theburningmonk.com the why of technology is to solve business problems and create business values
  3. 3. @theburningmonk theburningmonk.com my job as an engineer is NOT to write code
  4. 4. @theburningmonk theburningmonk.com the code is not the product
  5. 5. @theburningmonk theburningmonk.com the code is not the product it’s a cost, a means to an end
  6. 6. @theburningmonk theburningmonk.com my job as an engineer is to help the business create value
  7. 7. @theburningmonk theburningmonk.com what is the biggest challenge facing your company?
  8. 8. finding market fit
  9. 9. @theburningmonk theburningmonk.com runway
  10. 10. @theburningmonk theburningmonk.com runway: f(investment, cost) => time
  11. 11. @theburningmonk theburningmonk.com John Richard Boyd US air force colonel “Fighter Pilot who changed the Art of War”
  12. 12. @theburningmonk theburningmonk.com OODA loop
  13. 13. @theburningmonk theburningmonk.com Observe OODA loop collect data
  14. 14. @theburningmonk theburningmonk.com Observe Orient OODA loop collect data analyse data, form metal model
  15. 15. @theburningmonk theburningmonk.com Observe Orient Decide OODA loop collect data analyse data, form metal model decide course of action
  16. 16. @theburningmonk theburningmonk.com Observe Orient Decide Act OODA loop collect data analyse data, form metal model decide course of action action!
  17. 17. @theburningmonk theburningmonk.com Observe Orient Decide Act OODA loop collect data analyse data, form metal model decide course of action action!
  18. 18. @theburningmonk theburningmonk.com Observe Orient Decide Act OODA loop product development
  19. 19. @theburningmonk theburningmonk.com Observe Orient Decide Act OODA loop Understand product development
  20. 20. @theburningmonk theburningmonk.com Observe Orient Decide Act OODA loop Understand Define product development
  21. 21. @theburningmonk theburningmonk.com Observe Orient Decide Act OODA loop Understand Define Design product development
  22. 22. @theburningmonk theburningmonk.com Observe Orient Decide Act OODA loop Understand Define Design Deliver product development
  23. 23. @theburningmonk theburningmonk.com Boyd’s Law of Iteration Boyd decided that the primary determinant to winning dogfights was not observing, orienting, planning, or acting better. The primary determinant to winning dogfights was observing, orienting, planning, and acting faster. In other words, how quickly one could iterate. Speed of iteration, Boyd suggested, beats quality of iteration.
  24. 24. @theburningmonk theburningmonk.com Boyd’s Law of Iteration Boyd decided that the primary determinant to winning dogfights was not observing, orienting, planning, or acting better. The primary determinant to winning dogfights was observing, orienting, planning, and acting faster. In other words, how quickly one could iterate. Speed of iteration, Boyd suggested, beats quality of iteration.Speed of iteration, Boyd suggested, beats quality of iteration.
  25. 25. @theburningmonk theburningmonk.com
  26. 26. @theburningmonk theburningmonk.com runway
  27. 27. @theburningmonk theburningmonk.com runway
  28. 28. communication overhead
  29. 29. communication overhead inter-team dependencies
  30. 30. communication overhead inter-team dependencies lack of autonomy
  31. 31. Yan Cui http://theburningmonk.com @theburningmonk AWS user for 10 years
  32. 32. @theburningmonk theburningmonk.com http://bit.ly/yubl-serverless
  33. 33. Yan Cui http://theburningmonk.com @theburningmonk Developer Advocate @
  34. 34. Yan Cui http://theburningmonk.com @theburningmonk Independent Consultant advisetraining delivery
  35. 35. @theburningmonk theburningmonk.com https://theburningmonk.com/courses
  36. 36. @theburningmonk theburningmonk.com lambdabestpractice.com
  37. 37. @theburningmonk theburningmonk.com 2006
  38. 38. we’re getting a new server in 3 months time
  39. 39. yay! about time! hooray!! finally!
  40. 40. but we have to decide what dependencies to install on it now..
  41. 41.
  42. 42. @theburningmonk theburningmonk.com client tier logic tier data tier SQL
  43. 43. @theburningmonk theburningmonk.com monolithic, 3-tier architectures
  44. 44. @theburningmonk theburningmonk.com requires downtime for deployment
  45. 45. @theburningmonk theburningmonk.com requires downtime for deployment (OK for businesses that aren’t 24/7)
  46. 46. @theburningmonk theburningmonk.com
  47. 47. big-bang releases
  48. 48. @theburningmonk theburningmonk.com 2010
  49. 49. @theburningmonk theburningmonk.com on premise cloud
  50. 50. @theburningmonk theburningmonk.com EC2 EC2
  51. 51. @theburningmonk theburningmonk.com EC2 EC2 months minutes
  52. 52. @theburningmonk theburningmonk.com EC2 EC2 months minutes
  53. 53. @theburningmonk theburningmonk.com EC2 EC2 minutes compute becoming a commodity Genesis Custom-built Product Commodity http://bit.ly/wardley-maps
  54. 54. @theburningmonk theburningmonk.com EC2 EC2 minutes
  55. 55. @theburningmonk theburningmonk.com
  56. 56. @theburningmonk theburningmonk.com
  57. 57. @theburningmonk theburningmonk.com users are distributed around the world systems have to be available 24/7
  58. 58. SCALABILITY
  59. 59. SCALABILITY RESILIENCE
  60. 60. SCALABILITY RESILIENCE SECURITY
  61. 61. SCALABILITY RESILIENCE SECURITY SPEED
  62. 62. @theburningmonk theburningmonk.com Capex Opex capital expenditure operational expenditure
  63. 63. @theburningmonk theburningmonk.com Capex Opex capital expenditure operational expenditure levelled the playing field
  64. 64. @theburningmonk theburningmonk.com competition
  65. 65. @theburningmonk theburningmonk.com competition user demand & expectations
  66. 66. @theburningmonk theburningmonk.com
  67. 67. @theburningmonk theburningmonk.com faster delivery faster feedback loop we need…
  68. 68. @theburningmonk theburningmonk.com
  69. 69. @theburningmonk theburningmonk.com big-bang releases small, frequent releases
  70. 70. @theburningmonk theburningmonk.com
  71. 71. @theburningmonk theburningmonk.com co-evolution waterfall agile silos DevOps practice activity of and
  72. 72. @theburningmonk theburningmonk.com scale
  73. 73. @theburningmonk theburningmonk.com scale complexity
  74. 74. @theburningmonk theburningmonk.com but our cognitive capacity hasn’t increased…
  75. 75. @theburningmonk theburningmonk.com leverage: do more with less
  76. 76. @theburningmonk theburningmonk.com EC2 EC2
  77. 77. @theburningmonk theburningmonk.com EC2 EC2 we’re still managing infrastructure
  78. 78. @theburningmonk theburningmonk.com https://bit.ly/2Im61VK “Unless you’re an infrastructure company, infrastructure is basically overhead.” Matt Klein
  79. 79. @theburningmonk theburningmonk.com infrastructure you
  80. 80. @theburningmonk theburningmonk.com EC2EC2 EC2 RDSDynamoDB SQS
  81. 81. @theburningmonk theburningmonk.com Monoliths Microservices
  82. 82. @theburningmonk theburningmonk.com EC2 EC2 EC2 DynamoDB EC2 RDS EC2 SQS DynamoDB
  83. 83. @theburningmonk theburningmonk.com EC2 EC2 EC2 DynamoDB EC2 RDS EC2 SQS DynamoDB we’re managing lots more infrastructure!
  84. 84. @theburningmonk theburningmonk.com we need a better abstraction for the “server”
  85. 85. @theburningmonk theburningmonk.com we need an immutable infrastructure
  86. 86. @theburningmonk theburningmonk.com 70% utilization monolith 10% utilization x 10 microservices
  87. 87. @theburningmonk theburningmonk.com 70% utilization monolith 10% utilization x 10 microservices
  88. 88. @theburningmonk theburningmonk.com
  89. 89. @theburningmonk theburningmonk.com 0 Theory “it works on my machine!” “production ready!”days
  90. 90. @theburningmonk theburningmonk.com
  91. 91. @theburningmonk theburningmonk.com
  92. 92. @theburningmonk theburningmonk.com
  93. 93. @theburningmonk theburningmonk.com 0 Theory “it works on my machine!” “production ready!” 0 Reality “it works on my machine!” “production ready!” days days
  94. 94. @theburningmonk theburningmonk.com
  95. 95. @theburningmonk theburningmonk.com mooooo..
  96. 96. @theburningmonk theburningmonk.com what is the biggest challenge facing your company?
  97. 97. @theburningmonk theburningmonk.com “portability between cloud providers” - says no business, ever
  98. 98. @theburningmonk theburningmonk.com “choose Kubernetes because, portability!”
  99. 99. @theburningmonk theburningmonk.com what is the biggest challenge facing your company?
  100. 100. @theburningmonk theburningmonk.com
  101. 101. @theburningmonk theburningmonk.com runway
  102. 102. @theburningmonk theburningmonk.com runway how do we optimize the runway to get more iterations out of it?
  103. 103. @theburningmonk theburningmonk.com
  104. 104. @theburningmonk theburningmonk.com runway we need cheaper and lighter planes!
  105. 105. @theburningmonk theburningmonk.com 2016
  106. 106. 2016
  107. 107. @theburningmonk theburningmonk.com Server-ful Serverless
  108. 108. 2016 95% cost saving vs EC2
  109. 109. 2016 95% cost saving vs EC2 feature velocity went from months to days
  110. 110. 2016 95% cost saving vs EC2 feature velocity went from months to days same sized team
  111. 111. @theburningmonk theburningmonk.com
  112. 112. @theburningmonk theburningmonk.com minimise undifferentiated heavy-lifting
  113. 113. @theburningmonk theburningmonk.com Why serverless?
  114. 114. @theburningmonk theburningmonk.com more Scalable
  115. 115. @theburningmonk theburningmonk.com 1,000 concurrent executions (soft limit)
  116. 116. @theburningmonk theburningmonk.com 1,000 concurrent executions (soft limit) AUTO-APPROVED RAISE TO 3000
  117. 117. @theburningmonk theburningmonk.com containers are reused
  118. 118. @theburningmonk theburningmonk.com 100% SERVERLESS IN PRODUCTION
  119. 119. @theburningmonk theburningmonk.com
  120. 120. @theburningmonk theburningmonk.com 80 MILLION MONTHLY USERS
  121. 121. @theburningmonk theburningmonk.com
  122. 122. @theburningmonk theburningmonk.com Cheaper (don’t pay for idle servers)
  123. 123. 2016 95% cost saving vs EC2
  124. 124. https://aws.amazon.com/solutions/case-studies/financial-engines/
  125. 125. 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%…”
  126. 126. @theburningmonk theburningmonk.com
  127. 127. @theburningmonk theburningmonk.com
  128. 128. @theburningmonk theburningmonk.com Resilience (built-in redundancy and multi-AZ)
  129. 129. @theburningmonk theburningmonk.com http://bit.ly/2Vzfexo
  130. 130. @theburningmonk theburningmonk.com Secure
  131. 131. @theburningmonk theburningmonk.com Shared Responsibility Model
  132. 132. @theburningmonk theburningmonk.com Amazon automatically apply latest patches to host VMs
  133. 133. @theburningmonk theburningmonk.com
  134. 134. @theburningmonk theburningmonk.com
  135. 135. @theburningmonk theburningmonk.com request blue-green deployment req/s auto-scaling us-east-1a us-east-1b us-east-1c multi-AZ
  136. 136. the DevOps forcethe DevOps force is strong with serverlessis strong with serverless
  137. 137. @theburningmonk theburningmonk.com 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
  138. 138. @theburningmonk theburningmonk.com 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
  139. 139. @theburningmonk theburningmonk.com 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
  140. 140. @theburningmonk theburningmonk.com idea production greater Velocity from idea to product
  141. 141. 2016 15x number of production deploys same sized team
  142. 142. @theburningmonk theburningmonk.com leverage: do more with less
  143. 143. @theburningmonk theburningmonk.com focus on customer needs
  144. 144. @theburningmonk theburningmonk.com https://bit.ly/2Im61VK “Unless you’re an infrastructure company, infrastructure is basically overhead.” Matt Klein
  145. 145. @theburningmonk theburningmonk.com building a resilient, and scalable infrastructure is hard work
  146. 146. @theburningmonk theburningmonk.com building a resilient, and scalable infrastructure is hard work and crucial to your success!
  147. 147. @theburningmonk theburningmonk.com diverts attention from core business problems
  148. 148. @theburningmonk theburningmonk.com creates inter-team dependency
  149. 149. @theburningmonk theburningmonk.com leading to delays, and time pressure and stress
  150. 150. @theburningmonk theburningmonk.com serverless teams are smaller, and happier!
  151. 151. @theburningmonk theburningmonk.com smaller teams less comm overhead fewer meetings more time getting stuff done!
  152. 152. @theburningmonk theburningmonk.com
  153. 153. @theburningmonk theburningmonk.com
  154. 154. @theburningmonk theburningmonk.com developers are able to own more of their stack
  155. 155. @theburningmonk theburningmonk.com developers are able to own more of their stack more autonomy
  156. 156. @theburningmonk theburningmonk.com leverage: do more with less
  157. 157. cheaper, lighter, go faster
  158. 158. competition waits for no one
  159. 159. 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
  160. 160. @theburningmonk theburningmonk.com Production-Ready Serverless
  161. 161. senzo.io
  162. 162. @theburningmonk theburningmonk.com github.com/theburningmonk

×