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.

Unity Loves HelNode - Helsinki Node.js November Meetup

In HelNode November meetup, Tuomas Rinta (Development Director, Unity Technologies Helsinki) shares their five-year journey with Node.js, from a startup to a several hundred machine deployment one point was the biggest known Node.js deployment.

This talk is a 100 minute war story on Node.js featuring culture and practices it takes to run operations on scale. The talks will not limit to Node.js only, but the giant machinery as a whole.

More information on the event and the group: http://www.meetup.com/Helsinki-Node-js/

  • Login to see the comments

Unity Loves HelNode - Helsinki Node.js November Meetup

  1. 1. Five years of Node.js Unity <3 Node.js, or do we…?
  2. 2. The Beginning
  3. 3. The Beginning
  4. 4. PHP + MySQL
  5. 5. PHP + MongoDB
  6. 6. Node.js + MongoDB
  7. 7. Late 2010: Node.js 0.4 700M ads served per day
  8. 8. Thus began our 5-year journey with Node.js
  9. 9. Initially, Node was used only for APIs for ad delivery
  10. 10. New products and features were an easy way to transition
  11. 11. Backbone + Node.js + MongoDB
  12. 12. But it was not always a smooth ride…
  13. 13. Updating between Node versions was horrible
  14. 14. We ended up having different services run on different Node versions
  15. 15. A bleeding-edge tech stack will give you new challenges
  16. 16. Things we learned: MongoDB shards well… on paper
  17. 17. Things we learned: It was easier to optimize code and data layout than shard MongoDB
  18. 18. Things we learned: Handling memory leaks in Node.js is a pain
  19. 19. Things we learned: External dependencies, especially NPM, can make your deplos unreliable
  20. 20. While on the subject of NPM(JS.org)…
  21. 21. One of the best parts of Node.js is the community
  22. 22. One of the best worst parts of Node.js is the community
  23. 23. NPM, like actually most package managers, can be a security issue
  24. 24. Are you doing this? ~1.2.3 or ^1.2.3
  25. 25. Are you doing this? If you are, stop right now.
  26. 26. But you have no control over dependencies of used packages!
  27. 27. Worst case scenario Your application Dependency A Dependency B Sub- dependency A.1 Sub- dependency A.2
  28. 28. Worst case scenario Your application Dependency A Dependency B Sub- dependency A.1 Compromise d package
  29. 29. Worst case scenario Your application Dependency A Dependency B Sub- dependency A.1 Compromise d package
  30. 30. npm shrinkwrap
  31. 31. The Present
  32. 32. Tech Stack Node.js MongoDB + Cassandra + Redis Angular.js + Bootstrap
  33. 33. Infrastructure Everything on AWS Docker for deployment
  34. 34. Teams 2010: 8 people in Helsinki 2015: 70+ people in Helsinki
  35. 35. Requirements 99.9% uptime Continuous deployment Handle massive scale
  36. 36. How are we handling that?
  37. 37. #1: Testing
  38. 38. For continuous deployment, we must aim for ~100% test coverage
  39. 39. Tests are our compiler type- safety check
  40. 40. #2: Automated Deployment
  41. 41. Developers must be able to handle deployment and rollback independently
  42. 42. Auto-scaling must be able to set up new instances in a few minutes
  43. 43. Developer   commit   No.fies  of  commit   Clones  repository   Tests     run   Docker  container   pushed  to  private  registery   Deploy   Happiness  
  44. 44. #3: Understanding the weaknesses of Node.js
  45. 45. Leaking memory is easy, and debugging memory leaks is insanely difficult
  46. 46. Callback-hell makes debugging painful
  47. 47. Node.js is single-threaded
  48. 48. Let’s talk about that for a while…
  49. 49. Making sure your code yields adds complexity you don’t want
  50. 50. Measuring and monitoring these spikes is a nightmare
  51. 51. How do you measure?
  52. 52. Single-threaded also means that you cannot cache data efficiently on the local machine
  53. 53. We run 40 Redis instances to act as data caches
  54. 54. … and we still run Memcached locally in addition to that
  55. 55. Writing CPU-optimized code with Node.js is extremely difficult
  56. 56. The Future
  57. 57. Would we choose Node.js again?
  58. 58. Probably not.
  59. 59. Node.js is useful for prototyping.
  60. 60. Node.js does create burden in sustainable development.
  61. 61. Node.js requires a lot of discipline from the development team.
  62. 62. In the end: right tool for the right task.
  63. 63. Thank you! http://unity3d.com/helsinki

×