Richardrodger nodeday-2014-final
-
Upload
richard-rodger -
Category
Internet
-
view
70 -
download
0
Transcript of Richardrodger nodeday-2014-final
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
Content processing flow
Article Process
Feed Reader
Article Store
Article Index
Image Store
Image Size
Image Load
Some services work hard. Other's don't. !
You can focus team effort where it counts. !
Cut corners. It works.
Scalable system? Scalable services!
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
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 enterprise iterations
"We need a bug-fix iteration!" !
"Let's refactor!" !
"Unit test coverage is under 90%" !
"Lock down!"
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
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
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
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
User stories
autocomplete query perform search view info page rank modules update with new modules get metadata from github etc.
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
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.