This talk is an appeal to server-side JavaScript developers to make use of this time of change - Node.js is going to become the primary server-side platform for most developers. We can move forward from the old way of building web apps as large inter-locking co-dependent code bases. The Node.js module system has shown us the way. It's the first step. Now, we need to use the beauty of Node modules to help us build robust, scalable apps. This approach is called the Micro-Services Architecture. It's more than just having some services with HTTP end-points. It's about taking this to the extreme. Everything is a service, and no service is larger than 100 lines of code. We've been using this approach for most of our projects for the last 18 months and it works really well. We get to drop loads of project management ceremony. There will be some customer war stories.

1. You only need
100 lines of code
@rjrodger
nodeconfeu.com

2. 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

3. Best Practices.
!
Are a local maximum.
!
They exist to mitigate
inherent weakness.
Enterprise Software
Development

4. Discovering Micro-
services by accident.
The Sunday Business Post

5. Content processing flow
Article
Process
Feed
Reader
Article
Store
Article
Index
Image
Store
Image
Size
Image
Load

6. Natural way to split
the work...
!
For machines and for
humans
Individual node processes

7. Some services work
hard. Other's don't.
!
You can focus team
effort where it counts.
!
Cut corners. It works.
Scalable system?
Scalable services!

8. What is the number one risk
to enterprise software
development?

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

13. 100 lines of code.
!
A few screens to scroll.
!
Can fit inside your head.
Small

14. Use node modules.
!
Prefer composition of
libraries over the tyranny
of frameworks.
Where does the code go?

15. Do one thing and do it well.
!
Or badly. Rewrites are easy.
!
Large source files are a code
smell.
Single-purpose

16. 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

17. Standalone information.
!
You can pattern-match them.
!
They define the interface.
!
The transport mechanism is
not important.
Communicate with messages

18. No need for complex rules.
!
Do named keys have given values?
!
Use MUST IGNORE semantics.
This makes your world extendable.
Pattern matching

20. 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

21. How do you give
your Node.js app
"enterprise-grade" reliability?

23. 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

24. The classic agile iteration cycle
Design
refactor
developtest
release

25. The classic enterprise iterations
"We need a bug-fix iteration!"
!
"Let's refactor!"
!
"Unit test coverage is under 90%"
!
"Lock down!"

26. My previous startup:
FeedHenry

27. 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

28. We were stuck with our
original design decisions

29. 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

30. Calibrate

31. 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

32. 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

33. The universal law of defects
project stage
costtofix

34. Rewriting buggy services is not expensive.
They are small and independent.
Messages keep you safe.
Micro-services reduce
the slope of this curve

35. 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

36. Architecture

37. Let's design a system!

38. A basic approach
User Stories
capabilities
services
messages

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

40. Capabilities
Search
Engine
Module
Store
Meta
Data

41. Services
search-engine module-store meta-data
auto-complete
search
info request
update

42. 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:add
auto-complete:add
request: request

43. 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

44. Time domain.
!
Scale domain.
!
Behavioral domain.
!
+ Context-dependent domains.
Domain analysis

45. Time domain
real-time (1ms)
soft real-time (100ms)
responsive (1s)
process (1m)
batch (1h)

46. Scale domain
Messages per minute?
!
Message size?
!
CPU burn per message?
!
Acceptable error rate?

47. Behavioral domain
Idempotent?
!
At most once / exactly once / At least once ?
!
Transactional?

48. Message Transport
Should not matter. Do not decide upfront.
!
You will need to reconfigure later anyway.

49. Transport Modes
In Process.
- mostly for development
- also works for low volume services
!
Direct.
- use HTTP
- use load balancers to scale

50. 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

51. 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.

52. 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.

53. 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

54. 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.

55. 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.

56. Let's take the next step

57. Thank You!
richardrodger.com/monolithic-nodejs
@rjrodger