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.

One App on Four Platforms - Serverless London 2018

263 views

Published on

Running the exact same app on four different platforms. Presentation at Serverless London, 13 Nov 2018.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

One App on Four Platforms - Serverless London 2018

  1. 1. One App, Four Platforms Avi Deitcher | @avideitcher | avi@atomicinc.com | https://blog.atomicinc.com
  2. 2. Who Am I? Avi Deitcher avi@atomicinc.com
  3. 3. Who Am I? Life in Tech Business Avi Deitcher avi@atomicinc.com
  4. 4. Who Am I? Life in Tech Business Mission-Critical IT 10 yrs Avi Deitcher avi@atomicinc.com
  5. 5. Who Am I? Life in Tech Business Mission-Critical IT Consulting 10 yrs 12+ yrs Avi Deitcher avi@atomicinc.com
  6. 6. Who Am I? Life in Tech Business Mission-Critical IT Consulting 10 yrs 12+ yrs S t a r t u p s Avi Deitcher avi@atomicinc.com
  7. 7. Who Am I? Life in Tech Business Mission-Critical IT Consulting 10 yrs 12+ yrs S t a r t u p s Avi Deitcher avi@atomicinc.com
  8. 8. Who Am I? Life in Tech Business Mission-Critical IT Consulting 10 yrs 12+ yrs S t a r t u p s Avid (if not very good) ice hockey player Avi Deitcher avi@atomicinc.com
  9. 9. Who Am I? Life in Tech Business Mission-Critical IT Consulting 10 yrs 12+ yrs S t a r t u p s Avid (if not very good) ice hockey player Long-time lover of great engineering… when used to make a real difference Avi Deitcher avi@atomicinc.com
  10. 10. Who Am I? Life in Tech Business Mission-Critical IT Consulting 10 yrs 12+ yrs S t a r t u p s Avid (if not very good) ice hockey player Atomic Inc: Generalist Practitioner | product : engineering : operations | Incentives and culture Long-time lover of great engineering… when used to make a real difference Avi Deitcher avi@atomicinc.com
  11. 11. Avi Deitcher avi@atomicinc.com What is “serverless”?
  12. 12. Avi Deitcher avi@atomicinc.com What is “serverless”?
  13. 13. Avi Deitcher avi@atomicinc.com What is “serverless”?
  14. 14. Avi Deitcher avi@atomicinc.com What is “serverless”?
  15. 15. Avi Deitcher avi@atomicinc.com What is “serverless”?
  16. 16. Avi Deitcher avi@atomicinc.com What is “serverless”?
  17. 17. What about….
  18. 18. What about….
  19. 19. What about…. Monolith
  20. 20. What about…. Monolith
  21. 21. What about…. Monolith Services
  22. 22. What about…. Monolith Services
  23. 23. What about…. Monolith Services Services
  24. 24. Nanoservices Courtesy of and Copyright Container Solutions, Ltd. 2016
  25. 25. Avi Deitcher avi@atomicinc.com Biggest expense…
  26. 26. Avi Deitcher avi@atomicinc.com Biggest expense…
  27. 27. Avi Deitcher avi@atomicinc.com Biggest expense…
  28. 28. Avi Deitcher avi@atomicinc.com Number One Priority Management
  29. 29. The Café Table Metric Courtesy, Andy McCammont
  30. 30. Two (Maybe Controversial) Claims 1. The single most valuable part of serverless is “server-less” 2. Nanoservices or Functions-as-a-Service do not define serverless; they are enabled by it
  31. 31. The Platforms • One of the original Platform-as-a-Service • Deployment methodology - git push heroku master • Serverless score (2/5) No management ✔ Auto-scale ✖ Costs on precise usage ✖ Performance definition ✖ Implicit high-availability ✔
  32. 32. The Platforms • Darling of the container world • Deployment methodology - kubectl apply -f config.yml • Serverless score (4/5 or 0/5): No management ✔ ✖ Auto-scale ✔ ✖ Costs on precise usage ✖ ✖ Performance definition ✔ ✖ Implicit high-availability ✔ ✖
  33. 33. The Platforms • Open FaaS (literally) • Deployment methodology - faas deploy -f stack.yml • Serverless score (5/5 or 0/5): No management ✔ ✖ Auto-scale ✔ ✖ Costs on precise usage ✔ ✖ Performance definition ✔ ✖ Implicit high-availability ✔ ✖
  34. 34. The Platforms • Amazon’s pure FaaS • Deployment methodology - sam deploy … or aws lambda … or aws cloudformation or serverless or terraform or … • Serverless score (5/5): No management ✔ Auto-scale ✔ Costs on precise usage ✔ Performance definition ✔ Implicit high-availability ✔
  35. 35. Avi Deitcher avi@atomicinc.com The App www.studymesh.com
  36. 36. Avi Deitcher avi@atomicinc.com The App www.studymesh.com What: Split study goals among one, two, a thousand people worldwide
  37. 37. Avi Deitcher avi@atomicinc.com The App www.studymesh.com What: Split study goals among one, two, a thousand people worldwide When: Built in a single week, off-hours, a few years ago, gratis for a non-profit
  38. 38. Avi Deitcher avi@atomicinc.com The App www.studymesh.com What: Split study goals among one, two, a thousand people worldwide When: Built in a single week, off-hours, a few years ago, gratis for a non-profit How:
  39. 39. Avi Deitcher avi@atomicinc.com The App www.studymesh.com What: Split study goals among one, two, a thousand people worldwide When: Built in a single week, off-hours, a few years ago, gratis for a non-profit How:
  40. 40. Avi Deitcher avi@atomicinc.com The App www.studymesh.com What: Split study goals among one, two, a thousand people worldwide When: Built in a single week, off-hours, a few years ago, gratis for a non-profit How:
  41. 41. Deploy 1 • Heroku “slug” is complete single deployment • Literally Platform-as-a-Service - not a server in sight! • Classic 3-tier app, right down to starting a listening server • Easy to reason about - easy transition, fast deployment • Select from pre-defined app environments (unless you like buildpacks) • Need to think about scaling… maybe (Jan 2017 Web dyno auto-scaling) • git push heroku master easy to understand.. easy to abuse ! • Open standards - git, Procfile, process, https://12factor.net
  42. 42. Deploy 2
  43. 43. Deploy 2 • Is it serverless? It depends!
  44. 44. Deploy 2 • Is it serverless? It depends! • Operator: 😂
  45. 45. Deploy 2 • Is it serverless? It depends! • Operator: 😂 • App Owner: Pretty much
  46. 46. Deploy 2 • Is it serverless? It depends! • Operator: 😂 • App Owner: Pretty much • Easy to reason about - easy transition, fast deployment
  47. 47. Deploy 2 • Is it serverless? It depends! • Operator: 😂 • App Owner: Pretty much • Easy to reason about - easy transition, fast deployment • Enables microservices… which take time to learn
  48. 48. Deploy 2 • Is it serverless? It depends! • Operator: 😂 • App Owner: Pretty much • Easy to reason about - easy transition, fast deployment • Enables microservices… which take time to learn • Packaging, kubectl and config ymls have a learning curve
  49. 49. Deploy 2 • Is it serverless? It depends! • Operator: 😂 • App Owner: Pretty much • Easy to reason about - easy transition, fast deployment • Enables microservices… which take time to learn • Packaging, kubectl and config ymls have a learning curve • As flexible as it gets
  50. 50. Deploy 2 • Is it serverless? It depends! • Operator: 😂 • App Owner: Pretty much • Easy to reason about - easy transition, fast deployment • Enables microservices… which take time to learn • Packaging, kubectl and config ymls have a learning curve • As flexible as it gets • Open standards
  51. 51. Deploy 2 • Is it serverless? It depends! • Operator: 😂 • App Owner: Pretty much • Easy to reason about - easy transition, fast deployment • Enables microservices… which take time to learn • Packaging, kubectl and config ymls have a learning curve • As flexible as it gets • Open standards
  52. 52. Deploy 2 • Is it serverless? It depends! • Operator: 😂 • App Owner: Pretty much • Easy to reason about - easy transition, fast deployment • Enables microservices… which take time to learn • Packaging, kubectl and config ymls have a learning curve • As flexible as it gets • Open standards
  53. 53. Deploy 2 • Is it serverless? It depends! • Operator: 😂 • App Owner: Pretty much • Easy to reason about - easy transition, fast deployment • Enables microservices… which take time to learn • Packaging, kubectl and config ymls have a learning curve • As flexible as it gets • Open standards
  54. 54. About that yml
  55. 55. Deploy 3 • Is it serverless? It depends! • Operator: (see “Kubernetes”) • App Owner: Yes! Makes FaaS possible • Harder to reason about • Enables nanoservices… which take longer to learn • Packaging, faas-cli and config ymls have learning curve (easier than kubernetes!) • Composability: OpenFaaS Function Store • Open standard FaaS • OCI packaging • “handlers” to make it easier to build
  56. 56. Deploy 4 • Is it serverless? Yes! • Hardest to reason about • Almost enforces nanoservices… which take longer to learn • Packaging has a steep learning curve • Composability: Serverless Application Repository • Proprietary - but not opaque - standards • Zip packaging • “handlers”are only interface • Limited runtimes… but growing • Full suite of AWS services simplify decomposition: not everything is a function • More options to chain functions
  57. 57. Doug McIlroy
  58. 58. “Working on the chain gang” 🎶
  59. 59. “Working on the chain gang” 🎶
  60. 60. “Working on the chain gang” 🎶
  61. 61. “Working on the chain gang” 🎶
  62. 62. “Working on the chain gang” 🎶
  63. 63. “Working on the chain gang” 🎶
  64. 64. “Working on the chain gang” 🎶
  65. 65. Avi Deitcher avi@atomicinc.com FaaS Challenges
  66. 66. Avi Deitcher avi@atomicinc.com FaaS Challenges Testing: unit is easier, integration is hard
  67. 67. Avi Deitcher avi@atomicinc.com FaaS Challenges Testing: unit is easier, integration is hard Monitoring & Debugging: these are hyper-distributed systems
  68. 68. Avi Deitcher avi@atomicinc.com FaaS Challenges Testing: unit is easier, integration is hard Monitoring & Debugging: these are hyper-distributed systems Common libraries/frameworks/functions: (how) should we do them?
  69. 69. Avi Deitcher avi@atomicinc.com FaaS Challenges Lifecycle: tooling and culture Testing: unit is easier, integration is hard Monitoring & Debugging: these are hyper-distributed systems Common libraries/frameworks/functions: (how) should we do them?
  70. 70. Avi Deitcher avi@atomicinc.com FaaS Challenges Time to market: never discount it Lifecycle: tooling and culture Testing: unit is easier, integration is hard Monitoring & Debugging: these are hyper-distributed systems Common libraries/frameworks/functions: (how) should we do them?
  71. 71. Lock-In
  72. 72. Lock-In?
  73. 73. Lock-In?
  74. 74. Lock-In?
  75. 75. Lock-In?
  76. 76. Lock-In?
  77. 77. Lock-In
  78. 78. Lock-In • Every platform has some binding of app to runtime: app, config, packaging • Every platform has some cost of on-board and off-board
  79. 79. Lock-In • Every platform has some binding of app to runtime: app, config, packaging • Every platform has some cost of on-board and off-board
  80. 80. Lock-In • Every platform has some binding of app to runtime: app, config, packaging • Every platform has some cost of on-board and off-board
  81. 81. Lock-In • Every platform has some binding of app to runtime: app, config, packaging • Every platform has some cost of on-board and off-board
  82. 82. Lock-In • Every platform has some binding of app to runtime: app, config, packaging • Every platform has some cost of on-board and off-board
  83. 83. Lock-In • Every platform has some binding of app to runtime: app, config, packaging • Every platform has some cost of on-board and off-board
  84. 84. Lock-In • Every platform has some binding of app to runtime: app, config, packaging • Every platform has some cost of on-board and off-board Promise: At some point (if you survive), you will migrate platforms. No one will dominate forever.
  85. 85. Avi Deitcher avi@atomicinc.com Technology Takeaways
  86. 86. Avi Deitcher avi@atomicinc.com Technology Takeaways Constraints are liberating
  87. 87. Avi Deitcher avi@atomicinc.com Technology Takeaways Match local to cloud Constraints are liberating
  88. 88. Avi Deitcher avi@atomicinc.com Technology Takeaways Service to data sync Match local to cloud Constraints are liberating
  89. 89. Avi Deitcher avi@atomicinc.com Technology Takeaways Web Front-End: SPA vs Server- Service to data sync Match local to cloud Constraints are liberating
  90. 90. Avi Deitcher avi@atomicinc.com Technology Takeaways Web Front-End: SPA vs Server- Service to data sync Match local to cloud Constraints are liberating Change is… Easy (no worries) Hard (new mindset)
  91. 91. Avi Deitcher avi@atomicinc.com Summary
  92. 92. Avi Deitcher avi@atomicinc.com Summary The less you worry about, the better (power? cooling? firmware? IPMI?)
  93. 93. Avi Deitcher avi@atomicinc.com Summary The less you worry about, the better (power? cooling? firmware? IPMI?) Architecture matters… affects skills, culture, designs, tooling, everything
  94. 94. Avi Deitcher avi@atomicinc.com Summary The less you worry about, the better (power? cooling? firmware? IPMI?) Architecture matters… affects skills, culture, designs, tooling, everything Mel Conway
  95. 95. Avi Deitcher avi@atomicinc.com Summary The less you worry about, the better (power? cooling? firmware? IPMI?) Architecture matters… affects skills, culture, designs, tooling, everything Changes take time - lots and lots of time - to evolve to complete lifecycle benefits Mel Conway
  96. 96. Avi Deitcher avi@atomicinc.com Summary The less you worry about, the better (power? cooling? firmware? IPMI?) Architecture matters… affects skills, culture, designs, tooling, everything Changes take time - lots and lots of time - to evolve to complete lifecycle benefits Focus on the benefits you need. It is not about ideological purity! • Life-and-shift is ok if it helps • Remember the “Cafe Table Metric” • Serverless != FaaS ; Serverless ⊇ FaaS Mel Conway
  97. 97. Avi Deitcher avi@atomicinc.com Summary The less you worry about, the better (power? cooling? firmware? IPMI?) Architecture matters… affects skills, culture, designs, tooling, everything Changes take time - lots and lots of time - to evolve to complete lifecycle benefits Focus on the benefits you need. It is not about ideological purity! • Life-and-shift is ok if it helps • Remember the “Cafe Table Metric” • Serverless != FaaS ; Serverless ⊇ FaaS “if we lose this business next week, there is no next month!” Mel Conway
  98. 98. Questions and assistance: @avideitcher avi@atomicinc.com

×