node and micro-services at ibm

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 storyWhy we chose micro-services and Node.js

–Gerrald Mast, The Comic Mind: Comedy and the Movies, 1973

Boy meets girl, boy looses girl, boy recovers true love.

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 12CONCEPT TENETS FACTORS

Our first Node.js service

We needed a good enough reason

We were sitting on the fenceI 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 collectiveBreak 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 antibodiesIt 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 brokersBecause 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 exampleRabbitMQ 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 clusteringBecause 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 clusteringRabbitMQ worker queue, round-robin to micro-service

workers

Truth in advertisingOther 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 usYou want us to vet how many modules again?

Ops hate usYou 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 regretsAs Ralph Wiggum would say, “We are learnding!"

Questions?

Thank you!@dglozic

http://dejanglozic.com