Node.js Micro-Services: The Water is Fine, Jump In!

Dr. Dejan Glozic, IBM

About me

• IBM Canada, Toronto Lab

• Full-stack architect

• IBM DevOps Services

• @dglozic

• dejan@ca.ibm.com

• http://dejanglozic.com

GIVING YOU SOME CONTEXT Part 1

IBM and me

Planet IBM Software Group IBM Rational IBM DevOps Services

Me (hi!)

IBM DevOps Services for Bluemix • Integrated task tracking,

agile planning, source control

• Optimized for Bluemix

• Use your favorite tools or work from the Web IDE

• Hosted SCM Jazz or Git or link to GitHub

• Continuous Integration and Deployment

• Mobile quality and application performance monitoring (coming)

http://jazzhub.com

Humble beginnings

• Skunkworks project to host Rational Team Concert for academic users (JazzHub)

• Generous use of duct tape

• JEE container, SQL, Dojo/Digit, extreme Ajax

Challenge

• From hosting RTC to ‘Rational as a Service’

• Convert one-engine Cesna into a jet airliner

• Apply solid architectural principles

• Do it mid-air

Wish list

• Grow the system without sinking it

• Allow parallel development

• Many deployments per day

• Zero-downtime deployment

• A/B testing

• Web scale

• World peace

MEANWHILE, IN A PARALLEL EFFORT…

Part 2

Rethinking apps

• Lessons from monolithic applications on premise

• Need to avoid: – Stack lock-in

– Lock-step development

• Client-side reset – embrace HTML5 – jQuery, Bootstrap instead of

Dojo, Dijit

• The 12-factor app

What about the server?

• From extreme Ajax to a more balanced approach

• Simple, straightforward servlets and JSPs

• Lightweight containers (Jetty, WebSpere Liberty Profile)

• Still sitting on the Node.js fence

Dec 2013 Node.js flood

• The Walmart memory leak

• Walmart Thanksgiving

• NodeSummit 2013

• Groupon: Dismantling the monoliths

• PayPal: Project Kraken.js

TAKING THE PLUNGE Part 3

Convincing ourselves

• Felix Geisendörfer - Node.js Convincing the Boss Guide

• Never mind the boss, what do we think?

• It had to be something hard to do in JEE

• Perfect use case: DevOps Pipeline Web app

Server push

• A lot happening on the server

• Polling would not scale

• WebSockets to the rescue

• Server push is the ‘killer app’ of Node.js

• We got our ‘foot in the door’, now what?

Coping with success

• One is easy, multiple requires architecture

• Luckily, Node.js didn’t leave us a lot of options

• A classic case of ‘The Medium is the Message’

• The medium influences and becomes a part of the message itself

Example

• This is Billy Corgan. He is my guitar hero.

• He has a signature Fender guitar, but he started with one that was not very good.

• It had no sustain to speak of.

What he wanted

• Billy always wanted to sound like this guy – Frank “Tony” Iommi from Black Sabbath.

What he got

• Unfortunately, due to the lack of sustain, Billy had to play a lot of short notes to fill in.

• He ended up sounding like this guy – Robert James Smith from The Cure.

• The medium (no sustain guitar) changed Billy’s message.

Good match

• So what is Node.js good for?

• Tasks with a lot of waiting for I/O

• Small services that do one thing well

• DIRT apps with server push

• JavaScript all the way down: – Storing data in JSON-based NoSQL

DBs

– Rendering pages using JavaScript templating engines

Micro-services

• Building blocks of modern distributed systems in the cloud

• Do one thing well

• Is this SOA? Maybe SOA done right.

• Node.js fits like a glove.

Medium revisited

• ‘The medium is the message’ applies both ways.

• If you want to use Node.js: – It will force you into micro-service

architecture – There are no big monolithic Node apps.

• If you want micro-service architecture: – You can use other technologies, but… – They have more overhead – Node recommends itself as a great fit – For fairness: Netty-based Scala apps (see

Reactive Manifesto) – Fairness #2: Go

THE MASTER PLAN Part 4

North star

Load balancing, routing, proxy

Jenkins UCD RTC Docker Git/Gerrit

Composition

Activities

MQTT Broker

Web UI services

API services

Backend

services Integration services

Storage services

(NoSQL)

Native mobile clients

Single Sign On

(affects all services)

Desktop, mobile Web

Metering

API docs

Loggin

g

REST/MQTT mirroring

• Micro-services make messaging a ‘must have’ • Prevents micro-service ‘chatter’ and polling • Works harmoniously with WebSockets • Protocol of choice – MQTT (lightweight

pub/sub) • We devised a technique we call ‘REST/MQTT

mirroring’ • REST CRUD is mirrored by messages for C, U

and D • Message broker of choice – RabbitMQ for now

(polyglot broker) • Not a hard dependency – we may swap an

IBM-provided MQ in the future

Pipeline revisited

• Revisiting server push

• MQTT event flow between micro-services

• ‘Last mile’ in the Node.js app

• MQTT to WebSockets

Web services

• Serve one or more Web pages • Good pattern – federation of SPAs • Proxy pass of routes to services • Our template library choice – Dust.js

(LinkedIn fork) • Server rendering for fast initial page

and headless clients • Client side rendering for user

interactions • Lazy loading of JS via Require.js • Responsive design

API docs

• APIs not an afterthought in micro-services

• Ball of mud without strong contracts

• Internal APIs first • External APIs:

– Different Auth – Subset of endpoints – Rate limiting – MQ to WebSockets/event

streaming

• API docs served by micro-services

• Aggregation and rendering

HA and scaling

• With micro-services, clustering decisions are local

• Cluster hotspots • 2 nodes enough for HA

unless hotspot • Node.js clustering for

vertical scaling • Load balancing for

horizontal scaling • Worker queues for MQ

events

Social micro-services

• Events are good for state synchronization

• Social events need more information

• Dedicated activity stream service

• Uses Activity Stream draft 2.0 spec

• User and project streams

{ "verb": "post", "published": "2011-02-10T15:04:55Z", "language": "en", "actor": { "objectType": "person", "id": "urn:example:person:jane", "displayName": "Jane Doe", "url": "http://example.org/jane", "image": { "url": "http://example.org/jane/image.jpg", "mediaType": "image/jpeg", "width": 250, "height": 250 } }, "object" : { "objectType": "picture", "id": "urn:example:picture:abc123/xyz" "url": "http://example.org/pictures/2011/02/pic1", "displayName": "Jane jumping into water" }, "target" : { "objectType": "album", "id": "urn:example:albums:abc123", "displayName": "Jane's Vacation", "url": "http://example.org/pictures/albums/janes_vacation/" } }

FROM THE TRENCHES Part 5

We are not done

• Not a rear-view mirror story

• We are far from done

• We didn’t yet forget the bad

• You can learn from us and steel yourself

Legal will hate you

• Entire dependency chain needs to be vetted by legal

• Sometimes it will give them a heart attack

• Eventually the torrent will subside

• Prominent modules: – Express.js – Web service middleware

– Dust.js – server/client templating (LinkedIn fork)

– Socket.io – server push using Web Sockets

– Nano.js – for Cloudant DB

– Mqtt.js – for messaging

– Kraken.js – Express-based app suite for security, i18n, code structure, configuration, testing

Ops will hate you

• You are upsetting the routine • NoSQL, Node.js, MQ • You want how many VMs again? • Easily hundreds:

– Dozens of micro-services x HA x DEV/QA/PROD stages

– You can cheat with vertical scaling

• Each VM needs to: – Know other VMs it will talk to (firewalls) – List the ports it will use

• Partial mitigation: automate, use DevOps • Makes you seriously get PaaS

Learning curve

• You cannot do it alone

• You need to sell the whole story to the team

• Surprisingly little resistance

• Node.js is cool, it is an easy sell

• Our North Star is a compelling story

Chipping away

• Mothership in active use is a hard thing to evolve

• Baseline what exists, define fault lines

• Plan micro-services along the fault lines

• Rule #1: Write all new code as micro-services

• Rule #2: For substantial refactoring, extract a micro-service

• Continue until Mothership is no more

Step 1: baseline

Load balancing, routing, proxy

Composition

Activities

Web UI services

API services

Mothership

Step 2: Web services

Load balancing, routing, proxy

Composition

Activities

Web UI services

API services

Mothership

Step 3: Web UI done

Load balancing, routing, proxy

Composition

Activities

Web UI services

API services

Mothership (headless)

Step 4: API services

Load balancing, routing, proxy

Composition

Activities

Web UI services

API services

Mothership (headless)

Step 5: all done

Load balancing, routing, proxy

Composition

Activities

Web UI services

API services

Conclusion

• Our journey continues

• We have no regrets

• Despite difficulties, we are having fun

• I am documenting it along the way

• Follow me on twitter, drop me a line, read my blog and you will be in the know

Q and A

Thank You!