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.

Slaying Monoliths with Node and Docker

1,666 views

Published on

Slaying Monoliths with Node and Docker

Published in: Technology
  • Be the first to comment

Slaying Monoliths with Node and Docker

  1. 1. November 2016 Slaying Monoliths with & Yunong Xiao Principal Engineer @yunongx http://yunong.io
  2. 2. #netflixeverywhere
  3. 3. Subscriber Growth 20M 33M 46M 59M 72M 85M 2011 2012 2013 2014 2015 2016
  4. 4. API Evolution
  5. 5. So You Want to Watch Netflix
  6. 6. So You Want to Watch Netflix
  7. 7. Watch Anywhere
  8. 8. In The Beginning…
  9. 9. Java Web Server ❖ Java based web server ❖ Renders UI ❖ Accesses data ❖ Individual clients for each service ❖ Different behavior for each client Java Web server Route A Route B Route C Route D Route N … Client Library A Client Library B Client Library C Client Library N … Backend Service A Backend Service B Backend Service C Backend Service N …
  10. 10. Spot the Monolith Java Web server Route A Route B Route C Route D Route N … Client Library A Client Library B Client Library C Client Library N … Backend Service A Backend Service B Backend Service C Backend Service N … M O N O LITH
  11. 11. New Devices
  12. 12. API Evolution
  13. 13. Java Web Server Java Web server Route A Route B Route C Route D Route N … Client Library A Client Library B Client Library C Client Library N … Backend Service A Backend Service B Backend Service C Backend Service N … M O N O LITH
  14. 14. REST API REST API Backend Service A Backend Service B Backend Service C Backend Service N …
  15. 15. REST API ❖ Inflexible: waiting for weeks between API changes. ❖ Inefficient: multiple round trips ❖ Complex API: hard to maintain
  16. 16. API Evolution
  17. 17. Design for Innovation ❖ Rapid innovation ❖ More AB tests and devices ❖ Customized API ❖ Performance matters
  18. 18. REST API REST API Backend Service A Backend Service B Backend Service C Backend Service N …
  19. 19. API.NEXT API Server Script A Script B Script C Script D Script N … Client Library A Client Library B Client Library C Client Library N … Backend Service A Backend Service B Backend Service C Backend Service N … M O N O LITH
  20. 20. Scale ❖ 42.5 billion hours watched in 2015 ❖ “Massive” RPS: Billions/day ❖ 1000s of scripts active in prod, 10000s in test ❖ 100s of changes/day ❖ 100s of AB tests with many variants/test
  21. 21. All Scripts Live in One Process ❖ Vertical Scale: Running out of headroom ❖ Memory ❖ I/O ❖ Instance cost: Largest instances $ can buy
  22. 22. HappySad Together? ❖ Resource contention ❖ 1 bad script takes out everyone ❖ Conflicting dependencies
  23. 23. API Server Script A Script B Script C Script D Script N … Client Library A Client Library B Client Library C Client Library N … Backend Service A Backend Service B Backend Service C Backend Service N … Developer Ergonomics UI Engineering Systems Engineering
  24. 24. API Evolution
  25. 25. Requirements ❖ Scalability ❖ Availability ❖ Developer productivity
  26. 26. Runtime Scalability & Availability ❖ Process isolation ❖ Separation of data access scripts and API servers ❖ Reduce infrastructure costs ❖ Horizontally scalable architecture ❖ Faster startup times ❖ Immutable deployment artifacts
  27. 27. Developer Productivity ❖ JS to rule them all ❖ Run and debug scripts locally, set breakpoints, step through code ❖ Fast, incremental builds ❖ As closely mirrors production as possible
  28. 28. API Evolution API Server Script A Script B Script C Script D Script N … Client Library A Client Library B Client Library C Client Library N … Backend Service A Backend Service B Backend Service C Backend Service N … M O N O LITH
  29. 29. API Server Script A Script B Script C Script D Script N … Client Library A Client Library B Client Library C Client Library N … Backend Service A Backend Service B Backend Service C Backend Service N … Natural Separation UI Engineering Systems Engineering
  30. 30. Next Generation Data Access API TV iOS Android Windows Browsers Remote Service Layer Search MAP GPS Playback … Clients Node API Edge API Backend Services
  31. 31. Node API Platform ❖ Set of JS data access scripts ❖ Running Node.js + restify ❖ Inside of a Docker /browse /search /account /signup Unified Remote Service Layer /bootstrap /search /account /login Unified Remote Service Layer
  32. 32. Evolutionary Traits ❖ Runtime platform ❖ Application management ❖ Container infrastructure ❖ Developer tools “Production”
  33. 33. Evolutionary Traits ❖ Runtime platform ❖ Application management ❖ Container infrastructure ❖ Developer tools “Production”
  34. 34. -Twitter “A full-stack developer is one who can add technical debt to any layer of the application”
  35. 35. Aim: Paved Path for Data Access Apps ❖ Metrics ❖ Alerts ❖ Autoscaling ❖ Load balancing ❖ Discovery ❖ Analytics
  36. 36. Node Runtime: Platform as a Service ❖ Production ready Node platform ❖ Just bring JS business logic ❖ Everything else is “free” ❖ No servers/infrastructure to manage nf-iso- properties Properties Discovery RPC nf-eureka- client reactive- datasource Insight nf-atlas- client bunyan- suro (data- pipeline) bunyan (logging) nf-salp Web serverRuntime reactive- socket-lb HTTP Client
  37. 37. Evolutionary Traits ❖ Runtime platform ❖ Application management ❖ Container infrastructure ❖ Developer tools “Production”
  38. 38. Aim: Simple App Management ❖ Versioning ❖ Deployment ❖ Operational Insights
  39. 39. Versioning: Current Problems ❖ APIs change all the time ❖ 100000s different versions ❖ 1000s live in prod
  40. 40. Versioning: Inconsistency api.netflix.com/tvui/1469577600021 api.netflix.com/web/6dbd361 api.netflix.com/ios/1.3.2 api.netflix.com/android/1234 Build Timestamp Git sha App version Integer
  41. 41. Aim: Consistent Versions & Reproducible Builds
  42. 42. Solution: Use SemVer
  43. 43. Versioning: Node API Index
  44. 44. Routing api.netflix.com/tvui/1469577600021 api.netflix.com/web/6dbd361 api.netflix.com/ios/1.3.2 api.netflix.com/android/1234 Build Timestamp Git sha App version Integer
  45. 45. Problem: API Upgrades api.netflix.com/ios/1.3.2 1.3.2 1.3.3 Path immutably baked into client
  46. 46. Solution: SemVer Routing api.netflix.com/ios/^1.0.0 1.3.2 1.3.3 1.4.0 1.6.5 nq.netflix.com api.netflix.com/ios/1.3.2 ^1.0.0 ^1.0.0 1.3.2 1.3.2
  47. 47. Operational Insights ❖ List and view deployed apps and routes ❖ Deployment history ❖ Metrics: RPS, latency, errors, … ❖ Analytics
  48. 48. Generated Dashboards
  49. 49. Evolutionary Traits ❖ Runtime platform ❖ Application management ❖ Container infrastructure ❖ Developer tools “Production”
  50. 50. Titus: Container Management & Scheduling Fenzo
  51. 51. Evolutionary Traits ❖ Runtime platform ❖ Application management ❖ Container infrastructure ❖ Developer tools “Production”
  52. 52. Aim: Developer Productivity ❖ Run and debug scripts locally ❖ Fast, incremental builds ❖ Local “prod” environment
  53. 53. Local Development: Builds are Slow Build deps Commit to SCM Document JS NQ Scripts Build Docker Image Tens of Minutes
  54. 54. Rapid Local Development: Debug in Seconds Developer Laptop (Mac OSX) Virtual Box (Linux) Running Docker Host Docker Server Container Running MyApp Image MyApp Image MyApp scripts & config NodeQuark Image Prana Image NodeJS Image Ubuntu Image
  55. 55. Recap: Containers ❖ Process isolation ❖ Layered dependency management ❖ Portability across environments: prod->test ❖ Fast deployment ❖ Single deployment artifact: Docker image
  56. 56. Recap: Node.js ❖ JS everywhere: client & server ❖ Performant ❖ Lightweight & efficient: run locally ❖ Non blocking ❖ Superb ecosystem (npm) ❖ Built for the web
  57. 57. Recap: Node Platform ❖ Developer productivity ❖ Fast incremental builds ❖ Run, debug, and test locally ❖ Local prod like environment ❖ Scalability & availability ❖ Monolith -> micro-services ❖ Process isolation: better availability ❖ Horizontally scalable architecture ❖ Immutable deployment artifacts Unified Remote Service Layer Backend Service A Backend Service B Backend Service C Backend Service N …
  58. 58. Thanks! ❖ Interested? is hiring! ❖ @yunongx ❖ yunong@netflix.com ❖ yunong.io

×