The document discusses IBM's transition from older enterprise stacks like Java and SQL to newer technologies like Node.js, NoSQL, and microservices. It describes motivations for the change like yearly release cycles, large teams, and running products on-premise. It then covers specifics of the transition, including moving from Dojo/Dijit to jQuery/Bootstrap on the client side, using Node.js and WebSockets for real-time updates, adopting a microservices architecture, switching from SQL to NoSQL databases, and addressing challenges that arise from the new approaches.

1. IBM and Node.js: Old Doge,
New Tricks
Dejan Glozic, Full-Stack Architect, IBM Bluemix DevOps

2. Show Us Your
Stack

3. About Me
IBM Canada Toronto Lab
Full-Stack Architect
IBM Bluemix DevOps
@dglozic
http://dejanglozic.com

4. What I Work On

5. Part 1
Motivation for change

6. Enterprise products
Yearly release cycle, moves at the speed of the slowest component.

7. Large teams
Complex coordination, large change sets, difficult to get a good stable build.

8. Products run on premise
Managed by customer admins, limited control over hardware choices.

9. Enterprise stacks
Java Enterprise Something Something, WS*, Apache, SQL

10. Overindulgence in JavaScript
‘Extreme Ajax’ - Dojo/Dijit pushed well beyond sane limits
desktop != server != client

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. 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. Evolution of Thought
• 12-factors
• Netflix
• Reactive Manifesto
• Micro-services

14. Part 2
From Dojo/Dijit to jQuery/Bootstrap/MV*
JS

15. Client Side Reset
Swapping Dojo/Dijit for jQuery/Bootstrap. No point arguing with gravity.

16. Bootstrap
We love the emphasis on HTML5/CSS and away from JavaScript.

17. After jQuery?
• Sometimes jQuery is too big
• Alternatives for newer browsers: zepto, jqLite
• Or nothing? http://youmightnotneedjquery.com

18. Part 3
From Java to Node.js
JS

19. Now The Server Side
Nothing much wrong with servlets and JSPs, but we wanted more.

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. ‘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. 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. 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. Part 4
From a monolith to micro-services

25. Tackling the Hard Problems
So far we upgraded our stack but didn’t handle any of our systemic problems.

26. Architectural Impasse
If monoliths were pain for on-premise products, they were killing us in the cloud.

27. Cloud Imposter Rule
Standing up a traditional product in a VM does not mean you ‘solved the cloud’.

28. Putting Manifestos To Work
This is where the principles of micro-services, reactive manifesto and 12 factors
come into play.

29. How Micro-Services Help
• Many micro-services instead of a monolith
• Deploy micro-services independently
• Communicate using message queues
• Cluster locally

30. This Is Not A Micro-Service Talk
There are others at this conference, and tons of material online.

31. Part 5
From REST to REST+Messaging

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. 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. 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. Messaging and Clustering

36. Part 6
From SQL to, well, NoSQL (duh)

37. Our Data is Aggregate
It is a pain to join data from a number of tables using foreign keys

38. Our Integration Points Are API
Services
Persistance is implementation detail.

39. JavaScript All The Way Down
With Node.js, JSON-based NoSQL DB like CouchDB is a natural choice.

40. Pulling It All Together

41. Part 7
No free lunch - micro-services introduce new problems.

42. Latency Needs Mitigation
Keeping micro-services in co-located VMs, strategic caching (combined with MQ
invalidation).

43. Guards Against Brownouts
Circuit breakers, using ‘last good values’, exponential back-off. See Netflix libraries
for ideas.

44. Authentication
We need to stay authenticated as we transition between micro-services.

45. UI Composition
Including page fragments is easy in monoliths using partials. In micro-service
systems, we need distributed solutions.

46. Part 8
Lessons from the trenches

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. 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. 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. “Use the simplest solution you can get away withTM.”
–Dejan’s Razor (in honour of William of Ockham)

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. *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. **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. 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. DEMO

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. How To Follow
• Source code on GitHub: https://github.com/dglozic/fsto-demo
• Hosted on Bluemix: http://fsto-demo.mybluemix.net

58. Q/A
?

59. Thank you!
Follow me on Twitter: @dglozic
Read my blog: dejanglozic.com