Zero to scaleable in ten minutes

Zero to scaleable in ten minutes

Less than obvious tools & tips for writing software that lasts

Matt Walters @mateodelnorte mattwalters5@gmail.com

What do you mean… ‘scaleable’?

As businesses grow, their understanding of problems they’re solving also grows

Scaleable = easy to understand, maintain, and add to

During that growth, software changes. Good software is easiest to change, while still getting

things done.

Combining standard, available tools, and repeating simple, predictable patterns during development will keep your code understandable, maintainable, and easily improved.

Our toolkit will be: • gitslave • tmuxinator • rabbitmq • servicebus *and some very simple patterns

How do we scale an architecture?

gitslaveWhy have a monolith, when you can have a

metarepo?

> man gits

Gitslave Home Page: <http://gitslave.sf.net>

NAME gits - The git slave repository tool for multi-repository management

SYNOPSIS gits [-p|--parallel COUNT] [-v|--verbose]+ [--quiet] [--help] [--version] [-n|--no-pager] [--paginate] [--eval-args] [--exclude SLAVE-REGEXP] [--keep-going] [--no-commit] [--no-hide] [--no-progress] [--no-master] [--with-ifpresent|--just-ifpresent] SUBCOMMAND [ARGS]...

OVERVIEW gits is a program that assists in assembling a meta-project from a number of individual git repositories which operate (when using gits) as if they were one git repository instead of many, similar to the way that CVS works by default and svn (v1.5) can be coerced to work. Some of these individual git repositories may be part of other meta- projects as well.

gitslaveWhy have a monolith, when you can have a

metarepo?

gitslave allows you to have all of your code in one location, like a monolithic app, while allowing fine grained updates of each of your solution’s component projects.

one ‘gits pull origin master’ gets all new changes, for all related projects / repositories, while you can still perform fine grained operations on any particular repo.

gitslaveWhy have a monolith, when you can have a

metarepo?

> ls -ladrwxr-xr-x 18 mateodelnorte staff 612 Jul 14 00:52 . drwxr-xr-x 77 mateodelnorte staff 2618 Jul 19 23:01 .. -rw-r--r-- 1 mateodelnorte staff 411 Jul 12 22:22 .eslintrc.js drwxr-xr-x 12 mateodelnorte staff 408 Jul 20 11:34 .git -rw-r--r-- 1 mateodelnorte staff 59 Jul 14 00:25 .gitignore -rw-r--r-- 1 mateodelnorte staff 127 Jul 14 00:26 .gitslave -rw-r--r-- 1 mateodelnorte staff 2849 Jul 5 15:56 Makefile drwxr-xr-x 16 mateodelnorte staff 544 Jul 14 01:18 denormalizer drwxr-xr-x 16 mateodelnorte staff 544 Jul 10 17:51 my-service-one drwxr-xr-x 18 mateodelnorte staff 612 Jul 14 00:39 my-service-two drwxr-xr-x 18 mateodelnorte staff 612 Jul 14 00:39 my-site -rw-r--r-- 1 mateodelnorte staff 1184 Jul 19 23:32 tmuxinator.all.yml

gitslaveWhy have a monolith, when you can have a

metarepo?

> cat .gitignore/denormalizer/ /my-service-one/ /my-service-two/ /my-site/

gitslaveWhy have a monolith, when you can have a

metarepo?

> cat .gitslave

"../denormalizer" “denormalizer" “../my-service-one“ “my-service-one“ "../my-service-two" “my-service-two“ “../my-site" “my-site"

gitslave

brew install gitslave

tmuxinatorHeads up. You need a good view of your system.

tmuxinator.yml-based config-driven tmux. that’s it.

name: my-system root: ./

windows: - site: layout: tiled panes: - my-site: - printf ‘\033]2;my-site\033\\' - cd ./my-site - make run - services: layout: tiled panes: - my-service-one: - printf '\033]2;my-service-one\033\\' - cd ./my-service-one - make run - my-service-two: - printf '\033]2;my-service-two\033\\' - cd ./my-service-two

=

tmuxinatorHeads up. You need a good view of your system.

Panes per process

tmuxinatorHeads up. You need a good view of your system.

Windows per context, business domain, etc

tmuxinator

gem install tmuxinator

Neat whats next?We’ve talked about where you’ll house your project, and

the different sub-projects within it. (hint: one gitslave metarepo and n project repos)

Let’s talk a bit about messaging.

And we’ve talked about how you’ll stare at it while it’s on your screen.

(hint: tmuxinator)

Why messaging?

Your processes need an interface

Why messaging?

Your processes need an interface

REST

Why messaging?

Your processes need an interface

REST ?What happens when a process dies?

Why messaging?

Your processes need an interface

REST ??What happens when a process dies?

Why messaging?

Your processes need an interface

Why messaging?

Your processes need an interface

Shared DB

Why messaging?

Your processes need an interface

Shared Spaghetti

Doable, but usually unclear which process ‘owns’ database structure and data. Can lead to maintenance hell.

Why messaging?

Your processes need an interface

Why messaging?

Your processes need an interface

Queues

Why messaging?

Your processes need an interface

Queues

?Processes go down with queues…

Why messaging?

Your processes need an interface

Queues

And come right back up with no message loss.

Why messaging?

Your system gets a safety net

Queues

?x5Added benefit: Planned human intervention for errors.

rabbitmqmessaging that just works

• direct send to queue • fanout / topic routing • highly available • highly performant • used in financial exchanges, industrial applications and more • open source • free

rabbitmqmessaging that just works

brew install rabbitmq

servicebussuper simple messaging in node

• direct send • pub / sub / fanout / topic -routing • simple to set up • highly performant • used in financial exchanges, online advertising and more • open source • free • perfect for creating microservices!

servicebussuper simple messaging in node

npm install servicebus —save

servicebussuper simple send+listen messaging in node

// process 1 var bus = require('servicebus').bus(); bus.listen('my.event', function (event) { console.log(event); });

// process 2 var bus = require('servicebus').bus();

setInterval(function () { bus.send('my.event', { my: 'event' }); }, 1000);

servicebussuper simple pub+sub messaging in node

// process 1 var bus = require('servicebus').bus(); bus.subscribe('my.event', function (event) { console.log(event); });

// process 2 var bus = require('servicebus').bus();

setInterval(function () { bus.publish('my.event', { my: 'event' }); }, 1000);

// process 3

(micro)servicebussome simple patterns get us going

// order-svc index.js const bus = require(‘servicebus').bus(); const create = require(‘./lib/create’); bus.listen(‘order.create', function (event) { create(event); });

(micro)servicebussome simple patterns get us going

// order-svc index.js const bus = require(‘servicebus’).bus(); const retry = require(‘servicebus-retry’); bus.use(retry({ store: new retry.RedisStore({ host: process.env.REDIS_HOST, port: process.env.REDIS_PORT }) })); const create = require(‘./lib/create’); bus.listen(‘order.create', function (event) { create(event, (err) => { if (err) return event.handle.reject(); event.handle.ack(); }); });

(micro)servicebussome simple patterns get us going

// order-svc refactored bus to ./lib/bus.js const bus = require(‘servicebus’).bus(); const retry = require(‘servicebus-retry’); bus.use(retry({ store: new retry.RedisStore({ host: process.env.REDIS_HOST, port: process.env.REDIS_PORT }) })); module.exports = bus;

(micro)servicebussome simple patterns get us going

// order-svc index.js

const bus = require(‘./bus’); // moved bus initialization to own module const create = require(‘./lib/create’); bus.listen(‘order.create', function (event) { create(event, (err) => { if (err) return event.handle.reject(); event.handle.ack(); }); });

(micro)servicebussome simple patterns get us going

// order-svc index.js

const bus = require(‘./bus’); // moved bus initialization to own module const create = require(‘./lib/create’); bus.listen(‘order.create', function (event) { create(event, (err, order) => { if (err) return event.handle.reject(); bus.publish(‘order.created’, order, () => { event.handle.ack();

}); }); });

service publishes to the world when it’s done!

commands tell services when an actor wants an action

client send commands to instruct a service to do work

commands are sent async, fire and forget

commands are sent directives: order.create

web app order-svc

order.create!

events tell the world when you’re done

services publish when done performing work

services publish messages to any services that wish to listen

events are sent past-tense: order.created

order-svc fulfillment-svc

order.created!order.created!

(micro)servicebussome simple patterns get us going

// order-svc index.js

const bus = require(‘./bus’); // moved bus initialization to own module const create = require(‘./lib/create’); bus.listen(‘order.create', function (event) { create(event, (err, order) => { if (err) return event.handle.reject(); bus.publish(‘order.created’, order, () => { event.handle.ack();

}); }); });

(micro)servicebussome simple patterns get us going

// order-svc index.js

const bus = require(‘./bus’); // moved bus initialization to own module const cancel = require(‘./lib/cancel’); const create = require(‘./lib/create’); bus.listen(‘order.create', function (event) { create(event, (err, order) => { if (err) return event.handle.reject(); bus.publish(‘order.created’, order); bus.publish(‘order.created’, order, () => { event.handle.ack();

}); }); }); bus.listen(‘order.cancel', function (event) { cancel(event, (err, order) => { if (err) return event.handle.reject(); bus.publish(‘order.canceled’, order); bus.publish(‘order.created’, order, () => { event.handle.ack();

}); }); });

code buildupincreases

cognitive load

(micro)servicebussome simple patterns get us going

// order-svc index.js

const bus = require(‘./bus’); // moved bus initialization to own module require(‘./lib/handlers/orderCanceled’); require(‘./lib/handlers/orderCreated’); // moved handlers to their own modules, // hiding their complexity from other code

(micro)servicebussome simple patterns get us going

// order-svc index.js

const bus = require(‘./bus’); const log = require(‘llog’); const registerHandler = require(‘servicebus-register-handlers’); registerHandlers({ bus, handleError: function handleError (msg, err) { log.error(`error handling ${msg.type}: ${err}. rejecting message` + `w/cid ${msg.cid} and correlationId ${this.correlationId}.`); log.fatal(err); msg.handle.reject(() => { bus.close(); process.exit(1); }); }, path: ‘./lib/handlers', // handlers are now one listen or subscribe per file queuePrefix: 'order-svc', });

Show the stuff!

quick show and tell

Let’s recap!‘cause there was a lot!

1. gitslave lets you structure a project like a monolith, but have the convenience of many repositories

2. tmuxinator gives you a head’s up view of your system, all running locally

3. messaging provides a durable, convenient interface between your processes

4. rabbitmq + servicebus enable easy send+listen & pub+sub messaging patterns between processes

5. processes send commands and publish events 6. simple, expected, structure in your services keeps

cognitive load low, and projects easy to maintain

Thanks!We’ll cover more on event-driven architecture, microsvc, CQRS, and

more in a future talk!

Zero to scaleable in ten minutes

Matt Walters github & twitter: @mateodelnorte email: mattwalters5@gmail.com

https://github.com/tmuxinator/tmuxinatorrabbitmq.com

http://gitslave.sourceforge.net/

https://www.npmjs.com/package/servicebus