KEMBAR78
Node and Micro-Services at IBM | PDF
Node.js Micro- 
Services at IBM 
Dejan Glozic, IBM 
nodeconf.eu 2014
About me 
Dejan Glozic, Full-Stack Architect 
IBM Canada Toronto Laboratory 
@dglozic 
http://dejanglozic.com
Disclaimer: I don’t 
speak for the entire IBM 
Just my cozy corner in IBM Rational
Our story 
Why we chose micro-services and Node.js
Boy meets girl, boy looses girl, boy recovers 
true love. 
–Gerrald Mast, The Comic Mind: Comedy and the Movies, 
1973
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
We used micro-services 
before they were cool 
We just called them ’12-factor apps’.
1 4 12 
CONCEPT TENETS FACTORS
Our first Node.js 
service 
We needed a good enough reason
We were sitting on the fence 
I have a blog post to prove it
What made us bite the 
bullet? 
NodeSummit 2013 - Walmart, Groupon, PayPal, Yahoo
It is not hard to build 
one app 
For two or more, you need an actual architecture
Our key tenets 
1. Many micro-services instead of a monolith 
2. Deploy micro-services independently 
3. Communicate using message queues 
4. Cluster locally
1. Many micro-services 
Down with the monolith!
We used to build 
monoliths 
Practically a must on-premise
The cloud changed 
everything 
Bizarro world - everything good on premise is bad in the 
cloud
Borg collective 
Break a large system into manageable chunks. Say, 
using Node.js.
Small services are 
Node.js’ sweet spot 
There is a reason for the hexagon icon (you know, bee 
hive?)
Monolith antibodies 
It takes a gigantic effort NOT to arrive at a micro-service 
system using Node.js
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)
2. Deploy micro-services 
independently 
No maintenance downtime
No budget for big 
outages 
Need to fix and evolve the system in mid-flight
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
3. Message brokers 
Because there is life beyond REST
REST uses request/ 
response pattern 
This makes micro-service systems too ‘chatty’.
Test: review firewall 
rules 
The more IPs listed, the chattier the service.
Alternative: event 
collaboration 
State changes are published into topics, interested 
services subscribe to them.
Advantages 
• No wasted requests (are we there yet?) 
• Resiliency (fire and forget) 
• Safety valve 
• Loose coupling of services 
• Enables server push
Messaging example 
RabbitMQ between micro-services, WebSockets for 
server push
Node.js is a great candidate 
• Great support for MQ protocols (MQTT, AMQP) 
• Async processing of incoming messages 
• Great support for WebSockets (server push)
4. Local clustering 
Because load is rarely uniform
Concerns 
• Apply extra capacity where it matters 
• Evolve the system as needed 
• Vertical vs horizontal scaling 
• HA vs scaling
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
MQ clustering 
RabbitMQ worker queue, round-robin to micro-service 
workers
Truth in advertising 
Other people develop micro-services using Java/Netty or 
Scala/Akka or Go
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
(More) Truth in 
advertising 
We have some battle scars to show
Legal hates us 
You want us to vet how many modules again?
Ops hate us 
You need how many VMs, again?
We get PaaS now 
Luckily we can move from SoftLayer we own to Bluemix 
we also own.
SSO is hard 
Nontrivial to make a federated system secure yet 
transparent.
Composition is hard 
Stitching a page from several micro-services is non-trivial 
(yeah, yeah, Web Components HTML Imports…)
We have no regrets 
As Ralph Wiggum would say, “We are learnding!"
Questions?
Thank you! 
@dglozic 
http://dejanglozic.com

Node and Micro-Services at IBM

  • 1.
    Node.js Micro- Servicesat IBM Dejan Glozic, IBM nodeconf.eu 2014
  • 2.
    About me DejanGlozic, 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 Whywe 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 sittingon the fence I have a blog post to prove it
  • 13.
    What made usbite the bullet? NodeSummit 2013 - Walmart, Groupon, PayPal, Yahoo
  • 16.
    It is nothard 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 tobuild 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 Breaka 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 Ittakes a gigantic effort NOT to arrive at a micro-service system using Node.js
  • 25.
    Node.js is agreat 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 forbig outages Need to fix and evolve the system in mid-flight
  • 28.
    Node.js is agreat 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 • Nowasted requests (are we there yet?) • Resiliency (fire and forget) • Safety valve • Loose coupling of services • Enables server push
  • 34.
    Messaging example RabbitMQbetween micro-services, WebSockets for server push
  • 35.
    Node.js is agreat 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 • Applyextra capacity where it matters • Evolve the system as needed • Vertical vs horizontal scaling • HA vs scaling
  • 38.
    Node.js is agreat 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 RabbitMQworker 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 PaaSnow 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 noregrets As Ralph Wiggum would say, “We are learnding!"
  • 50.
  • 51.
    Thank you! @dglozic http://dejanglozic.com