Slides for the presentation at the nodeconf.eu conference in Waterford, Ireland on Sept 8, 2014.

1. Node.js Micro-
Services at IBM
Dejan Glozic, IBM
nodeconf.eu 2014

2. About me
Dejan Glozic, Full-Stack Architect
IBM Canada Toronto Laboratory
@dglozic
http://dejanglozic.com

3. Disclaimer: I don’t
speak for the entire IBM
Just my cozy corner in IBM Rational

6. Our story
Why we chose micro-services and Node.js

7. Boy meets girl, boy looses girl, boy recovers
true love.
–Gerrald Mast, The Comic Mind: Comedy and the Movies,
1973

8. The new cliché
• Boy builds a monolith quickly (because MVP)
• Boy bloats the monolith with features
• Boy makes a big ball of mud
• Boy rewrites the system using small services
• Boy cannot shut up about it at conferences

9. We used micro-services
before they were cool
We just called them ’12-factor apps’.

10. 1 4 12
CONCEPT TENETS FACTORS

11. Our first Node.js
service
We needed a good enough reason

12. We were sitting on the fence
I have a blog post to prove it

13. What made us bite the
bullet?
NodeSummit 2013 - Walmart, Groupon, PayPal, Yahoo

16. It is not hard to build
one app
For two or more, you need an actual architecture

17. Our key tenets
1. Many micro-services instead of a monolith
2. Deploy micro-services independently
3. Communicate using message queues
4. Cluster locally

18. 1. Many micro-services
Down with the monolith!

19. We used to build
monoliths
Practically a must on-premise

20. The cloud changed
everything
Bizarro world - everything good on premise is bad in the
cloud

21. Borg collective
Break a large system into manageable chunks. Say,
using Node.js.

23. Small services are
Node.js’ sweet spot
There is a reason for the hexagon icon (you know, bee
hive?)

24. Monolith antibodies
It takes a gigantic effort NOT to arrive at a micro-service
system using Node.js

25. Node.js is a great candidate
• Miserly on the resources
• Component model + NPM
• Great test and build tools (e.g. JSHint, Mocha,
Grunt)
• Easy to write (and completely rewrite)

26. 2. Deploy micro-services
independently
No maintenance downtime

27. No budget for big
outages
Need to fix and evolve the system in mid-flight

28. Node.js is a great candidate
• Services start and stop in seconds
• Tools to keep the services up (e.g. PM2)
• PaaS-friendly (we use Bluemix)
• Clustering is great for rolling deploys

29. 3. Message brokers
Because there is life beyond REST

30. REST uses request/
response pattern
This makes micro-service systems too ‘chatty’.

31. Test: review firewall
rules
The more IPs listed, the chattier the service.

32. Alternative: event
collaboration
State changes are published into topics, interested
services subscribe to them.

33. Advantages
• No wasted requests (are we there yet?)
• Resiliency (fire and forget)
• Safety valve
• Loose coupling of services
• Enables server push

34. Messaging example
RabbitMQ between micro-services, WebSockets for
server push

35. Node.js is a great candidate
• Great support for MQ protocols (MQTT, AMQP)
• Async processing of incoming messages
• Great support for WebSockets (server push)

36. 4. Local clustering
Because load is rarely uniform

37. Concerns
• Apply extra capacity where it matters
• Evolve the system as needed
• Vertical vs horizontal scaling
• HA vs scaling

38. Node.js is a great candidate
• Single threaded event loop
• ‘Share nothing’ from day 1
• Local clustering to use multiple cores
• Load balancing across VMs for horizontal
scaling

39. MQ clustering
RabbitMQ worker queue, round-robin to micro-service
workers

40. Truth in advertising
Other people develop micro-services using Java/Netty or
Scala/Akka or Go

41. Node.js is (still) a great
candidate
• Browsers running JS give Node.js an edge
• Express or Hapi make API services easy
• NoSQL DBs with JSON (JS all the way down)
• Developer happiness

42. (More) Truth in
advertising
We have some battle scars to show

43. Legal hates us
You want us to vet how many modules again?

44. Ops hate us
You need how many VMs, again?

45. We get PaaS now
Luckily we can move from SoftLayer we own to Bluemix
we also own.

46. SSO is hard
Nontrivial to make a federated system secure yet
transparent.

47. Composition is hard
Stitching a page from several micro-services is non-trivial
(yeah, yeah, Web Components HTML Imports…)

48. We have no regrets
As Ralph Wiggum would say, “We are learnding!"

50. Questions?

51. Thank you!
@dglozic
http://dejanglozic.com