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.
IBM and Node.js: Old Doge, 
New Tricks 
Dejan Glozic, Full-Stack Architect, IBM Bluemix DevOps
Show Us Your 
Stack
About Me 
IBM Canada Toronto Lab 
Full-Stack Architect 
IBM Bluemix DevOps 
@dglozic 
http://dejanglozic.com
What I Work On
Part 1 
Motivation for change
Enterprise products 
Yearly release cycle, moves at the speed of the slowest component.
Large teams 
Complex coordination, large change sets, difficult to get a good stable build.
Products run on premise 
Managed by customer admins, limited control over hardware choices.
Enterprise stacks 
Java Enterprise Something Something, WS*, Apache, SQL
Overindulgence in JavaScript 
‘Extreme Ajax’ - Dojo/Dijit pushed well beyond sane limits 
desktop != server != client
A Need for a Reset 
• Complexity and crud built up over time 
• Apollo 13: sooner or later you hit 12 amps 
• Solution: tu...
Motivators 
• New attractive stacks built for humans 
• The need to bring the fun back 
• The need to built ‘fit for cloud...
Evolution of Thought 
• 12-factors 
• Netflix 
• Reactive Manifesto 
• Micro-services
Part 2 
From Dojo/Dijit to jQuery/Bootstrap/MV* 
JS
Client Side Reset 
Swapping Dojo/Dijit for jQuery/Bootstrap. No point arguing with gravity.
Bootstrap 
We love the emphasis on HTML5/CSS and away from JavaScript.
After jQuery? 
• Sometimes jQuery is too big 
• Alternatives for newer browsers: zepto, jqLite 
• Or nothing? http://youmi...
Part 3 
From Java to Node.js 
JS
Now The Server Side 
Nothing much wrong with servlets and JSPs, but we wanted more.
Sitting on the Node.js Fence 
• We watched cautious companies like 
Walmart and PayPal jump in. 
• After plugging the ‘Wal...
‘Control Your Urges’ Rule 
We will use a new technology to solve a real problem, not as an excuse to play 
with the new ho...
Our Case for Node.js 
• We wanted to build a UI for a delivery pipeline 
• The pipeline had a number of moving parts 
• We...
Unlocking New Opportunities 
• With Node.js, we could run JavaScript templating engine for the V of 
MVC 
• We chose Dust....
Part 4 
From a monolith to micro-services
Tackling the Hard Problems 
So far we upgraded our stack but didn’t handle any of our systemic problems.
Architectural Impasse 
If monoliths were pain for on-premise products, they were killing us in the cloud.
Cloud Imposter Rule 
Standing up a traditional product in a VM does not mean you ‘solved the cloud’.
Putting Manifestos To Work 
This is where the principles of micro-services, reactive manifesto and 12 factors 
come into p...
How Micro-Services Help 
• Many micro-services instead of a monolith 
• Deploy micro-services independently 
• Communicate...
This Is Not A Micro-Service Talk 
There are others at this conference, and tons of material online.
Part 5 
From REST to REST+Messaging
What Monolith Giveth, Micro- 
Service Taketh Away 
In-process, we just add event listeners to objects. Between processes, ...
Event Collaboration 
• Instead of polling using REST, react to 
events 
• Instead of peer to peer, publish without 
knowin...
REST/MQ Mirroring 
• Yin and Yang of micro-service communication 
• API services own state 
• MQ broadcasts stage changes ...
Messaging and Clustering
Part 6 
From SQL to, well, NoSQL (duh)
Our Data is Aggregate 
It is a pain to join data from a number of tables using foreign keys
Our Integration Points Are API 
Services 
Persistance is implementation detail.
JavaScript All The Way Down 
With Node.js, JSON-based NoSQL DB like CouchDB is a natural choice.
Pulling It All Together
Part 7 
No free lunch - micro-services introduce new problems.
Latency Needs Mitigation 
Keeping micro-services in co-located VMs, strategic caching (combined with MQ 
invalidation).
Guards Against Brownouts 
Circuit breakers, using ‘last good values’, exponential back-off. See Netflix libraries 
for ide...
Authentication 
We need to stay authenticated as we transition between micro-services.
UI Composition 
Including page fragments is easy in monoliths using partials. In micro-service 
systems, we need distribut...
Part 8 
Lessons from the trenches
Legal Hates Us 
• Hundreds of modules to scan licenses and 
content 
• Torrent is now turning into a trickle (phew!) 
• Oc...
Ops Hate Us 
• Operational complexity 
• Many firewall rules for service to service links 
• Many proxy_pass rules 
• Unkn...
IaaS Too Low for Micro-Services 
• Sweet spot - highly customized back-end systems 
• Node.js services are a shoe-in for a...
“Use the simplest solution you can get away withTM.” 
–Dejan’s Razor (in honour of William of Ockham)
Dejan’s Razor 
• If server-side MVC does the job, use it 
• If jQuery + Bootstrap do the job, use them 
• If adding Backbo...
*Use Client-Side MVC 
• If highly dynamic behaviour is needed and… 
• You promise to use pushState (no # or #!) and… 
• Yo...
**Use Angular.js 
• If all the rules for client-side MVC apply and… 
• You promise not to leave us to maintain 1.3 when 2....
Micro-Service Benefit 
We can apply Dejan’s Razor on each service independently. Each service can be 
only as smart as nee...
DEMO
The Devil Is In The Pudding 
NNggiinnxx 
Angular 
Seed HHeeaaddeerr 
HHoommee IIssoommoorrpphhiicc SSeerrvveerr PPuusshh A...
How To Follow 
• Source code on GitHub: https://github.com/dglozic/fsto-demo 
• Hosted on Bluemix: http://fsto-demo.myblue...
Q/A 
?
Thank you! 
Follow me on Twitter: @dglozic 
Read my blog: dejanglozic.com
Upcoming SlideShare
Loading in …5
×

IBM and Node.js - Old Doge, New Tricks

1,663 views

Published on

Presentation at Full Stack Toronto Conference, November 23, 2014

Published in: Software
  • Be the first to comment

IBM and Node.js - Old Doge, New Tricks

  1. 1. IBM and Node.js: Old Doge, New Tricks Dejan Glozic, Full-Stack Architect, IBM Bluemix DevOps
  2. 2. Show Us Your Stack
  3. 3. About Me IBM Canada Toronto Lab Full-Stack Architect IBM Bluemix DevOps @dglozic http://dejanglozic.com
  4. 4. What I Work On
  5. 5. Part 1 Motivation for change
  6. 6. Enterprise products Yearly release cycle, moves at the speed of the slowest component.
  7. 7. Large teams Complex coordination, large change sets, difficult to get a good stable build.
  8. 8. Products run on premise Managed by customer admins, limited control over hardware choices.
  9. 9. Enterprise stacks Java Enterprise Something Something, WS*, Apache, SQL
  10. 10. Overindulgence in JavaScript ‘Extreme Ajax’ - Dojo/Dijit pushed well beyond sane limits desktop != server != client
  11. 11. A Need for a Reset • Complexity and crud built up over time • Apollo 13: sooner or later you hit 12 amps • Solution: turn everything off and and start from scratch
  12. 12. Motivators • New attractive stacks built for humans • The need to bring the fun back • The need to built ‘fit for cloud’ software • The need to ‘do it right this time’
  13. 13. Evolution of Thought • 12-factors • Netflix • Reactive Manifesto • Micro-services
  14. 14. Part 2 From Dojo/Dijit to jQuery/Bootstrap/MV* JS
  15. 15. Client Side Reset Swapping Dojo/Dijit for jQuery/Bootstrap. No point arguing with gravity.
  16. 16. Bootstrap We love the emphasis on HTML5/CSS and away from JavaScript.
  17. 17. After jQuery? • Sometimes jQuery is too big • Alternatives for newer browsers: zepto, jqLite • Or nothing? http://youmightnotneedjquery.com
  18. 18. Part 3 From Java to Node.js JS
  19. 19. Now The Server Side Nothing much wrong with servlets and JSPs, but we wanted more.
  20. 20. Sitting on the Node.js Fence • We watched cautious companies like Walmart and PayPal jump in. • After plugging the ‘Walmart leak’, it looked like Node.js was ready. • We were ready to jump ourselves by January 2014.
  21. 21. ‘Control Your Urges’ Rule We will use a new technology to solve a real problem, not as an excuse to play with the new hotness.
  22. 22. Our Case for Node.js • We wanted to build a UI for a delivery pipeline • The pipeline had a number of moving parts • We didn’t want to poll the server to the ground • Solution: Node.js + WebSockets (via Socket.io)
  23. 23. Unlocking New Opportunities • With Node.js, we could run JavaScript templating engine for the V of MVC • We chose Dust.js because LinkedIn, PayPal, Yahoo, Netflix • Bonus: we can now run Dust partials on the client as well (demo spoiler)
  24. 24. Part 4 From a monolith to micro-services
  25. 25. Tackling the Hard Problems So far we upgraded our stack but didn’t handle any of our systemic problems.
  26. 26. Architectural Impasse If monoliths were pain for on-premise products, they were killing us in the cloud.
  27. 27. Cloud Imposter Rule Standing up a traditional product in a VM does not mean you ‘solved the cloud’.
  28. 28. Putting Manifestos To Work This is where the principles of micro-services, reactive manifesto and 12 factors come into play.
  29. 29. How Micro-Services Help • Many micro-services instead of a monolith • Deploy micro-services independently • Communicate using message queues • Cluster locally
  30. 30. This Is Not A Micro-Service Talk There are others at this conference, and tons of material online.
  31. 31. Part 5 From REST to REST+Messaging
  32. 32. What Monolith Giveth, Micro- Service Taketh Away In-process, we just add event listeners to objects. Between processes, we need a distributed event notification.
  33. 33. Event Collaboration • Instead of polling using REST, react to events • Instead of peer to peer, publish without knowing your subscribers • Message broker smooths out throughput mismatches • Message broker can hold onto messages
  34. 34. REST/MQ Mirroring • Yin and Yang of micro-service communication • API services own state • MQ broadcasts stage changes on matching topics • Example: • DELETE /v1/projects/ffya14 • Subscribe to: /v1/projects/+ (MQTT) • Message body: { “event”: “deleted” }
  35. 35. Messaging and Clustering
  36. 36. Part 6 From SQL to, well, NoSQL (duh)
  37. 37. Our Data is Aggregate It is a pain to join data from a number of tables using foreign keys
  38. 38. Our Integration Points Are API Services Persistance is implementation detail.
  39. 39. JavaScript All The Way Down With Node.js, JSON-based NoSQL DB like CouchDB is a natural choice.
  40. 40. Pulling It All Together
  41. 41. Part 7 No free lunch - micro-services introduce new problems.
  42. 42. Latency Needs Mitigation Keeping micro-services in co-located VMs, strategic caching (combined with MQ invalidation).
  43. 43. Guards Against Brownouts Circuit breakers, using ‘last good values’, exponential back-off. See Netflix libraries for ideas.
  44. 44. Authentication We need to stay authenticated as we transition between micro-services.
  45. 45. UI Composition Including page fragments is easy in monoliths using partials. In micro-service systems, we need distributed solutions.
  46. 46. Part 8 Lessons from the trenches
  47. 47. Legal Hates Us • Hundreds of modules to scan licenses and content • Torrent is now turning into a trickle (phew!) • Occasional spike (e.g. express 4, Socket.io 1.0)
  48. 48. Ops Hate Us • Operational complexity • Many firewall rules for service to service links • Many proxy_pass rules • Unknown new platforms and tools (what is ‘PM2’?)
  49. 49. IaaS Too Low for Micro-Services • Sweet spot - highly customized back-end systems • Node.js services are a shoe-in for a PaaS • DBaaS takes away storage management headaches • We are moving to a PaaS now (Cloud Foundry/Bluemix)
  50. 50. “Use the simplest solution you can get away withTM.” –Dejan’s Razor (in honour of William of Ockham)
  51. 51. Dejan’s Razor • If server-side MVC does the job, use it • If jQuery + Bootstrap do the job, use them • If adding Backbone.js helps, do it* • If you really need Angular.js, use it**
  52. 52. *Use Client-Side MVC • If highly dynamic behaviour is needed and… • You promise to use pushState (no # or #!) and… • You promise to send initial content from the server… • You promise to watch the client JS size
  53. 53. **Use Angular.js • If all the rules for client-side MVC apply and… • You promise not to leave us to maintain 1.3 when 2.0 comes out
  54. 54. Micro-Service Benefit We can apply Dejan’s Razor on each service independently. Each service can be only as smart as needed for the task at hand.
  55. 55. DEMO
  56. 56. The Devil Is In The Pudding NNggiinnxx Angular Seed HHeeaaddeerr HHoommee IIssoommoorrpphhiicc SSeerrvveerr PPuusshh Angular Seed RReeddiiss RRaabbbbiittMMQQ // about /isomorphic /server-push /angular-seed /page1 /page2 OAuth2 provider
  57. 57. How To Follow • Source code on GitHub: https://github.com/dglozic/fsto-demo • Hosted on Bluemix: http://fsto-demo.mybluemix.net
  58. 58. Q/A ?
  59. 59. Thank you! Follow me on Twitter: @dglozic Read my blog: dejanglozic.com

×