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.
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
19.
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?
22.
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!"
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
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
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
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
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.