You only need 100 lines of code

@rjrodger

nodeconfeu.com

Small services that do one thing and do it well. !

And there are lots of them. !

Fred George http://vimeo.com/search?q=fred+george

Micro-Services

Best Practices. !

Are a local maximum. !

They exist to mitigate inherent weakness.

Enterprise Software Development

Discovering Micro-services by accident.

The Sunday Business Post

Content processing flow

Article Process

Feed Reader

Article Store

Article Index

Image Store

Image Size

Image Load

Natural way to split the work... !

For machines and for humans

Individual node processes

Some services work hard. Other's don't. !

You can focus team effort where it counts. !

Cut corners. It works.

Scalable system? Scalable services!

What is the number one risk to enterprise software

development?

Small. Single-purpose. Use messages. There are many of them. Death is expected.

Micro-Services

100 lines of code. !

A few screens to scroll. !

Can fit inside your head.

Small

Use node modules. !

Prefer composition of libraries over the tyranny of frameworks.

Where does the code go?

Do one thing and do it well. !

Or badly. Rewrites are easy. !

Large source files are a code smell.

Single-purpose

A service that mediates. A service that knows about other services. A service that accepts and sends many kinds of messages.

Anti-pattern: the orchestrator

Standalone information. !

You can pattern-match them. !

They define the interface. !

The transport mechanism is not important.

Communicate with messages

No need for complex rules. !

Do named keys have given values? !

Use MUST IGNORE semantics. This makes your world extendable.

Pattern matching

Write your services so they can restart cleanly. !

This is Node best practice. You MUST die on uncaught exceptions. !

So expect to die.

Crash-first Software

How do you give your Node.js app

"enterprise-grade" reliability?

Make decisions later, with more information. !

Calibrate quality and performance. !

Make rewrites cheap. !

Avoid project management ceremony. !

Services are the right size for humans.

Micro-service Architecture

The classic agile iteration cycle

Design

refactor

developtest

release

The classic enterprise iterations

"We need a bug-fix iteration!" !

"Let's refactor!" !

"Unit test coverage is under 90%" !

"Lock down!"

My previous startup: FeedHenry

Monolithic Java System. !

30 developer team, 3 years. Strict 2-week agile iterations. !

Custom integrations. On-premise rollouts. !

FeedHenry uses Node now ... because Technical Debt!

"Telecoms" Grade

We were stuck with our original design decisions

When you have more information, later in the project, you can: !

Split services. Combine services. Add services for special cases. Extend messages with more context. !

Rewrite bad services. Throw away and start again. It's only 100 lines.

Changing services is easy

Calibrate

Some code is critical: high performance with high cost of failure !

Other code has much weaker constraints: - low request volumes - batch processes - idempotent operations - obvious immediate failure modes

Not all code is created equal

Services are a comfortable size. !

You can easily group them by scale and quality requirements. !

This lets you focus effort where it counts.

Services can be grouped by quality

The universal law of defectsproject stage

cost

to

fix

Rewriting buggy services is not expensive. They are small and independent. Messages keep you safe.

Micro-services reduce the slope of this curve

Does it matter if a junior developer makes a mess of a service that has low quality requirements? !

Does it even matter if developers randomly pick services to work on? !

Do you deploy a system? Or do you deploy services?

Ceremony

Architecture

Let's design a system!

A basic approach

User Stories

capabilities

services

messages

User stories

autocomplete query perform search view info page rank modules update with new modules get metadata from github etc.

Capabilities

Search Engine

Module Store

Meta Data

Services

search-engine module-store meta-data

auto-complete

search

info request

update

Messages

IN OUT

auto-complete: list auto-complete: add

search: query search: index search: rank

info: set info: get

Update: notify

request: request info: set

search: index

auto-complete:addauto-complete:add

request: request

How many of each service to run? !

How do messages make it from one service to another? !

What happens when you deploy a new version?

Micro-services in Production

Time domain. !

Scale domain. !

Behavioral domain. !

+ Context-dependent domains.

Domain analysis

Time domain

real-time (1ms) soft real-time (100ms) responsive (1s) process (1m) batch (1h)

Scale domain

Messages per minute? !

Message size? !

CPU burn per message? !

Acceptable error rate?

Behavioral domain

Idempotent? !

At most once / exactly once / At least once ? !

Transactional?

Message Transport

Should not matter. Do not decide upfront. !

You will need to reconfigure later anyway.

Transport Modes

In Process. - mostly for development - also works for low volume services !

Direct. - use HTTP - use load balancers to scale

More Transport Modes

PubSub. - messages generate multiple actions - senders know nothing - publish interesting stuff !

Message Queues. - Needed for scale - Choose wisely

- we like Apache Kafka

Message Delivery

In principle, every service could listen for every message, ignoring most. !

In practice, you will define a more appropriate architecture (over time). !

Micro-services allow you to defer this design work until you have more information.

Some Examples

An MVP, with two instances behind a load balancer. In-Process, and Direct transports will take you quite far as you scale up. !

Booking engine with 100 queries per second, and 100 000 000 bookings per year. You'll need PubSub and Queues.

Production Monitoring

Monitor your services. But the information is not as useful as you think. !

There are too many of them. !

Monitor business outcomes. !

Example: purchases per minute

Production Deployment

Business outcome monitoring enables low risk deployments. !

Messages (with MUST IGNORE) insulate services from each other. You can run multiple versions of the same service. !

Deploy in stages, replacing a old version with a new version gradually.

It's not about Node

You can build micro-services in any language. !

Node's event-drive nature does make it very suitable. !

More important: Node gives you covering fire. Make a real change to the way you build software.

Let's take the next step

Thank You! richardrodger.com/monolithic-nodejs

@rjrodger