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.

You wouldn't build a toast, would you

336 views

Published on

In 2011, Thomas Thwaites spent 9 months and £1187.54 and built his own toaster.

In his own words, he described the toaster as a partial success because "for about five seconds, the toaster toasted, but then unfortunately, the elements kind of melted itself". He is right in the sense that his audacious attempt won him fame and attention, and his TED talk was viewed more than 1M times. But judging his creation on its own and it's an abject failure that was 300 time more expensive than a commercial toaster, took too long to build and was utterly unfit for purpose.

As a business that is competing in an increasingly competitive world enabled by advancements in technology, the questions we should be asking ourselves are: "what are the business value, cost and risk in building our own infrastructure vs using a managed service?". In this talk, let's take an objective look at the ongoing debate of containers vs serverless and look at the arguments of control vs responsibility, vendor lock-in and more!

Published in: Technology
  • Be the first to comment

  • Be the first to like this

You wouldn't build a toast, would you

  1. 1. You wouldn't build your own toaster would you? Yan Cui @theburningmonk
  2. 2. “ for about five seconds, the toaster toasted, but then unfortunately, the element kind of melted itself ”
  3. 3. £3.94 9 months + £1187.54
  4. 4. £3.94 9 months + £1187.54
  5. 5. £3.94 9 months + £1187.54 OVER BUDGET
  6. 6. £3.94 9 months + £1187.54 OVER BUDGET OVER TIME
  7. 7. £3.94 9 months + £1187.54 OVER BUDGET OVER TIME UNUSABLE
  8. 8. if you depend on a working toaster to survive, what would you do?
  9. 9. £3.94 A. buy one
  10. 10. £3.94 9 months + £1187.54 A. buy one B. build your own
  11. 11. X is a multi-national conglomerate
  12. 12. compute platform on
  13. 13. 18 months team of 8 2 versions compute platform on
  14. 14. no documentation
  15. 15. no documentation unstable
  16. 16. OVER BUDGET OVER TIME UNUSABLE
  17. 17. why???
  18. 18. Y is a small startup
  19. 19. We sell socks, but we’re also building our own Kubernetes cluster! Cool, right?
  20. 20. “in startups, and perhaps in life in general, time is the most scarce resource.” - Yevgeniy Brikman, co-founder of Gruntwork http://bit.ly/2OyvxLq
  21. 21. if your business depend on the ability to execute code to meet customer needs, what would you do?
  22. 22. Yan Cui http://theburningmonk.com @theburningmonk AWS user for 10 years
  23. 23. http://bit.ly/yubl-serverless
  24. 24. Yan Cui http://theburningmonk.com @theburningmonk Developer Advocate @
  25. 25. Yan Cui http://theburningmonk.com @theburningmonk Independent Consultant
  26. 26. What do you mean by ‘serverless’?
  27. 27. “Serverless”
  28. 28. Gojko Adzic It is serverless the same way WiFi is wireless. http://bit.ly/2yQgwwb
  29. 29. 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
  30. 30. “Function-as-a-Service” AWS Lambda Azure Functions Google Cloud Functions Auth0 Webtask Spotinst Functions Kubeless IBM Cloud Functions
  31. 31. AWS Lambda
  32. 32. AWS Lambda API Gateway IOT SNS Kinesis CloudWatch
  33. 33. 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
  34. 34. 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
  35. 35. Serverless FaaS other services… Database Storage BI
  36. 36. Simon Wardley Serverless will fundamentally change how we build business around technology and how you code.
  37. 37. Why serverless?
  38. 38. more Scalable (and scales faster!)
  39. 39. Cheaper (don’t pay for idle servers)
  40. 40. Resilience (built-in redundancy and multi-AZ)
  41. 41. Secure
  42. 42. 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
  43. 43. 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
  44. 44. idea production greater Velocity from idea to product
  45. 45. minimise undifferentiated heavy-lifting
  46. 46. less ops responsibility on your shoulders
  47. 47. idea production greater Velocity from idea to product
  48. 48. What about containers?
  49. 49. important, but invisible subsystem
  50. 50. https://read.acloud.guru/acg-faas-and-furious-b9574b6675c5
  51. 51. serverless is NOT the goal!
  52. 52. build products customers love to use
  53. 53. test ideas against the market quickly
  54. 54. iterate on s
  55. 55. deliver frequently, deliver quickly
  56. 56. own less technology, focus on creating Business Values
  57. 57. own less technology, focus on creating Business Values (serverless is just a good fit for this mindset)
  58. 58. serverless technologies are still maturing
  59. 59. https://www.youtube.com/watch?v=pptsgV4bKv8
  60. 60. https://bit.ly/production-ready-serverless
  61. 61. http://bit.ly/2C9LwIM
  62. 62. “you have no control over infrastructure” “good luck when Amazon decides to raise the price of Lambda!” “Lambda can’t scale” “you will be locked into AWS”
  63. 63. “you have no control over infrastructure” “good luck when Amazon decides to raise the price of Lambda!” “Lambda can’t scale” “you will be locked into AWS”
  64. 64. AWS announced 67 price reductions in the last 5 years, and 0 price hikes
  65. 65. “you have no control over infrastructure” “good luck when Amazon decides to raise the price of Lambda!” “Lambda can’t scale” “you will be locked into AWS”
  66. 66. “you have no control over infrastructure” “good luck when Amazon decides to raise the price of Lambda!” “Lambda can’t scale” “you will be locked into AWS”
  67. 67. 1,000 concurrent executions (soft limit) 500 increase per minute (hard-ish limit)
  68. 68. 1,000 concurrent executions (soft limit) 500 increase per minute (hard-ish limit) AUTO-APPROVED RAISE TO 3000
  69. 69. 1,000 concurrent executions (soft limit) 500 increase per minute (hard-ish limit)
  70. 70. containers are reused
  71. 71. 80 MILLION MONTHLY USERS
  72. 72. Control Responsibility
  73. 73. Controlling your own infrastructure comes with Responsibilities
  74. 74. to take on these responsibilities you need to have the relevant skills sets in the organization Controlling your own infrastructure comes with Responsibilities
  75. 75. to take on these responsibilities you need to have the relevant skills sets in the organization Controlling your own infrastructure comes with Responsibilities ENGINEERS
  76. 76. to take on these responsibilities you need to have the relevant skills sets in the organization Controlling your own infrastructure comes with Responsibilities ENGINEERS ADMIN
  77. 77. to take on these responsibilities you need to have the relevant skills sets in the organization Controlling your own infrastructure comes with Responsibilities ENGINEERS ADMIN RECRUITMENT
  78. 78. to take on these responsibilities you need to have the relevant skills sets in the organization Controlling your own infrastructure comes with Responsibilities ENGINEERS ADMIN RECRUITMENT MARKET
  79. 79. what are you paying for?
  80. 80. guard against the temptation to look for control for control sake
  81. 81. AWS Lambda, Azure Functions, Google Cloud Functions Your custom, container-based, general purpose compute platform
  82. 82. Lock-in risk Reward
  83. 83. “VENDOR LOCK-IN IS THE ROOT OF ALL EVIL”
  84. 84. use our private cloud instead, it’s totally not a lock-in because containers!
  85. 85. to take on these responsibilities you need to have the relevant skills sets in the organization Controlling your own infrastructure comes with Responsibilities ENGINEERS ADMIN RECRUITMENT MARKET
  86. 86. risk is just one side of the coin
  87. 87. extracting maximum value from your cloud provider minimising undifferentiated heavy-lifting faster time-to-market reward
  88. 88. vendor lock-in is a problem that is all bark but no bite
  89. 89. own less technology, focus on creating Business Values
  90. 90. “DATABASE LOCK-IN IS THE ROOT OF ALL EVIL”
  91. 91. ORM
  92. 92. a load of unnecessary complexity that didn’t end up making DB migrations any easier, and forced you to the least common denominator of feature sets and stop you from taking advantage of your DB in the first place…
  93. 93. nooooooooooo, wish I hadn’t used an ORM!!
  94. 94. The true danger with lock-in, especially with serverless, is the potential for data lock-in. Data has gravity. It accumulates. Data is economically disincentivized to leave, by way of platform pricing. This is the single biggest threat to vendor choice.
  95. 95. is vendor lock-in a risk? YES
  96. 96. is the return worth the risk? ABSOLUTELY!
  97. 97. there are no silver bullets
  98. 98. understand the trade-offs
  99. 99. control comes with its own baggages
  100. 100. but sometimes the benefits outweigh the baggages

×