Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

How did we get here and where are we going

697 Aufrufe

Veröffentlicht am

Serverless is all the rage these days, but how did we get here and why should businesses and developer care about serverless? In this talk, we will hear about Yan's journey from running on-prem servers to EC2, to containers, and finally to serverless. We will hear about the evolution of development practices and debunk some common misconceptions about serverless. We'll also get a glimpse of how we can build new kinds of businesses on top of serverless, and why FinDev might be an even bigger game changer for businesses than DevOps.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

How did we get here and where are we going

  1. 1. HOW DID WE HEADED WHERE AREWE HEREGET serverless:
  2. 2. Yan Cui http://theburningmonk.com @theburningmonk Principal Engineer @ Independent Consultant
  3. 3. available in Austria, Switzerland, Germany, Japan, Canada, Italy, US and Spain
  4. 4. available on 30+ platforms
  5. 5. ~1,000,000 concurrent viewers
  6. 6. follow @dazneng for updates about the engineering team We’re hiring! Visit engineering.dazn.com to learn more. WE’RE HIRING!
  7. 7. AWS user since 2009
  8. 8. AWS user since 2009
  9. 9. 2006
  10. 10. big meetings to decide how to provision new servers
  11. 11. 3-6 months (!!!!) turn around time
  12. 12. client tier logic tier data tier SQL
  13. 13. monolithic, 3-tier architectures
  14. 14. requires downtime for deployment
  15. 15. requires downtime for deployment (OK for businesses that aren’t 24/7)
  16. 16. install monitoring agents/daemons on server
  17. 17. big-bang releases
  18. 18. 2010
  19. 19. on premise cloud
  20. 20. 2012
  21. 21. 2016
  22. 22. 2019
  23. 23. EC2 EC2
  24. 24. EC2 EC2 months minutes
  25. 25. EC2 EC2 months minutes
  26. 26. EC2 EC2 minutes compute becoming a commodity Genesis Custom-built Product Commodity http://bit.ly/wardley-maps
  27. 27. EC2 EC2 minutes
  28. 28. users are distributed around the world systems have to be available 24/7
  29. 29. SCALABILITY
  30. 30. SCALABILITY RESILIENCE
  31. 31. SCALABILITY RESILIENCE SECURITY
  32. 32. SCALABILITY RESILIENCE SECURITY SPEED
  33. 33. Capex Opex capital expenditure operational expenditure
  34. 34. Capex Opex capital expenditure operational expenditure levelled the playing field
  35. 35. competition
  36. 36. competition user demand & expectations
  37. 37. faster delivery faster feedback loop we need…
  38. 38. big-bang releases small, frequent releases
  39. 39. co-evolution waterfall agile silos DevOps practice activity of and
  40. 40. scale
  41. 41. scale complexity
  42. 42. but our cognitive capacity hasn’t increased…
  43. 43. leverage: do more with less
  44. 44. EC2 EC2
  45. 45. EC2 EC2 we’re still managing infrastructure
  46. 46. https://bit.ly/2Im61VK “Unless you’re an infrastructure company, infrastructure is basically overhead.” Matt Klein
  47. 47. infrastructure you
  48. 48. EC2EC2 EC2 RDSDynamoDB SQS
  49. 49. Monoliths Microservices
  50. 50. EC2 EC2 EC2 DynamoDB EC2 RDS EC2 SQS DynamoDB
  51. 51. EC2 EC2 EC2 DynamoDB EC2 RDS EC2 SQS DynamoDB we’re managing lots more infrastructure!
  52. 52. we need a better abstraction for the “server”
  53. 53. we need an immutable infrastructure
  54. 54. 70% utilization monolith 10% utilization x 10 microservices
  55. 55. 70% utilization monolith 10% utilization x 10 microservices
  56. 56. EC2 EC2 EC2 DynamoDB EC2 RDS EC2 SQS DynamoDB
  57. 57. EC2 DynamoDB EC2 RDS EC2 SQS DynamoDB DynamoDB RDS SQS DynamoDB
  58. 58. EC2 DynamoDB EC2 RDS EC2 SQS DynamoDB DynamoDB RDS SQS DynamoDB
  59. 59. EC2 docker us-east-1a us-east-1b us-east-1a us-east-1b
  60. 60. 0 Theory “it works on my machine!” “production ready!”days
  61. 61. 0 Theory “it works on my machine!” “production ready!” 0 Reality “it works on my machine!” “production ready!” days days
  62. 62. mooooo..
  63. 63. 2016
  64. 64. SQL NoSQL OOP Functional On Premise Cloud Waterfall Agile Monoliths Microservices
  65. 65. 2016
  66. 66. 2016
  67. 67. Server-ful Serverless
  68. 68. https://gtnr.it/2KGyGCM
  69. 69. What do you mean by ‘serverless’?
  70. 70. “Serverless”
  71. 71. Gojko Adzic It is serverless the same way WiFi is wireless. http://bit.ly/2yQgwwb
  72. 72. Serverless means… don’t pay for it if no-one uses it don’t need to worry about scaling don’t need to provision and manage servers
  73. 73. “Function-as-a-Service” AWS Lambda Azure Functions Google Cloud Functions Auth0 Webtask Spotinst Functions Kubeless IBM Cloud Functions
  74. 74. AWS Lambda
  75. 75. AWS Lambda API Gateway IOT SNS Kinesis CloudWatch
  76. 76. IaaS Function Application Runtime Container OS Virtualization Hardware CaaS Function Application Runtime Container OS Virtualization Hardware PaaS Function Application Runtime Container OS Virtualization Hardware FaaS Function Application Runtime Container OS Virtualization Hardware User User (scalable unit) Provider
  77. 77. IaaS Function Application Runtime Container OS Virtualization Hardware CaaS Function Application Runtime Container OS Virtualization Hardware PaaS Function Application Runtime Container OS Virtualization Hardware FaaS Function Application Runtime Container OS Virtualization Hardware User User (scalable unit) Provider
  78. 78. Serverless FaaS other services… Database Storage BI
  79. 79. Simon Wardley Serverless will fundamentally change how we build business around technology and how you code.
  80. 80. Why serverless?
  81. 81. more Scalable
  82. 82. 1,000 concurrent executions (soft limit) 500 increase per minute (hard-ish limit)
  83. 83. 1,000 concurrent executions (soft limit) 500 increase per minute (hard-ish limit) AUTO-APPROVED RAISE TO 3000
  84. 84. 1,000 concurrent executions (soft limit) 500 increase per minute (hard-ish limit)
  85. 85. containers are reused
  86. 86. 100% SERVERLESS IN PRODUCTION
  87. 87. 80 MILLION MONTHLY USERS
  88. 88. Cheaper (don’t pay for idle servers)
  89. 89. Resilience (built-in redundancy and multi-AZ)
  90. 90. http://bit.ly/2Vzfexo
  91. 91. Secure
  92. 92. Shared Responsibility Model
  93. 93. Shared Responsibility Model
  94. 94. protection from OS attacks Amazon automatically apply latest patches to host VMs
  95. 95. Deploy
  96. 96. serverless.yml {} Code
  97. 97. {} Code serverless.yml
  98. 98. serverless.yml {} Code S3
  99. 99. {} Code serverless.yml S3 CloudFormation
  100. 100. {} Code serverless.yml S3 CloudFormation
  101. 101. request blue-green deployment
  102. 102. request blue-green deployment
  103. 103. request blue-green deployment
  104. 104. request blue-green deployment req/s auto-scaling us-east-1a us-east-1b us-east-1c multi-AZ
  105. 105. the DevOps forcethe DevOps force is strong with serverlessis strong with serverless
  106. 106. 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
  107. 107. 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
  108. 108. idea production greater Velocity from idea to product
  109. 109. minimise undifferentiated heavy-lifting
  110. 110. less ops responsibility on your shoulders
  111. 111. infrastructure you
  112. 112. DynamoDBDynamoDB RDS SQS DynamoDB DynamoDB API Gateway Lambda API Gateway Lambda RDS Lambda DynamoDBSQS
  113. 113. abstractionlayer
  114. 114. abstractionlayer paradigm shift!!!!
  115. 115. paradigm shift
  116. 116. paradigm shift opportunity
  117. 117. performance time serverless containers
  118. 118. performance time serverless containers higher ceiling
  119. 119. speed
  120. 120. performance time serverless containers higher ceiling strong baseline
  121. 121. performance time serverless containers dilemma zone
  122. 122. paradigm shift opportunity challenges
  123. 123. broken existing toolchains
  124. 124. observability securityframework
  125. 125. best practices are still emerging
  126. 126. ๏ tips for writing Lambda functions ๏ migration to serverless ๏ serverless ops ๏ design patterns ๏ performance optimization ๏ chaos engineering ๏ security ๏ general thoughts and techniques http://bit.ly/theburningmonk-serverless
  127. 127. https://bit.ly/production-ready-serverless
  128. 128. is serverless production-ready?
  129. 129. 2018
  130. 130. 1,000 concurrent executions (soft limit) 500 increase per minute (hard-ish limit)
  131. 131. ~1,000,000 concurrent viewers
  132. 132. serverless is not right for every use case (yet)
  133. 133. http://bit.ly/2WSfcky
  134. 134. Lambda VPC
  135. 135. there are no silver bullets
  136. 136. 0 Containers “it works on my machine!” “production ready!”days Serverless 0 “it works!” “production ready!” days
  137. 137. 0 Containers “it works on my machine!” “production ready!”days Serverless 0 “it works!” “production ready!” days v2! v3! v4! v5! v6!
  138. 138. EC2 docker us-east-1a us-east-1b us-east-1a us-east-1b Theory
  139. 139. Reality
  140. 140. Reality
  141. 141. scale-to-zero
  142. 142. serverful serverless us-east-1a us-east-1b us-east-1a us-east-1bscaled to zero!
  143. 143. HOW DID WE HEREGET serverless:
  144. 144. HEADED WHERE AREWE serverless:
  145. 145. scaling limits VPC long-running cold starts performance
  146. 146. scaling limits VPC long-running cold starts performance
  147. 147. scaling limits VPC long-running cold starts performance
  148. 148. http://bit.ly/2X0ksCY
  149. 149. http://bit.ly/2X0ksCY
  150. 150. http://bit.ly/2X0ksCY
  151. 151. scaling limits VPC long-running cold starts performance
  152. 152. http://bit.ly/2I7GJeJ
  153. 153. scaling limits VPC long-running cold starts performance
  154. 154. scaling limits VPC long-running cold starts performance
  155. 155. + pay-per-use?
  156. 156. Simon Wardley Serverless will fundamentally change how we build business around technology and how you code.
  157. 157. @theburningmonk theburningmonk.com github.com/theburningmonk

×