Advertisement
Advertisement

More Related Content

Advertisement

Recently uploaded(20)

Advertisement

Empowering businesses with serverless

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