Richardrodger nodeday-2014-final
1 like370 views
The document discusses the principles and advantages of microservices architecture, emphasizing the design of small, single-purpose services that communicate through messages. It highlights best practices for building scalable and reliable systems, including the importance of simplicity, adaptability, and monitoring. The text advocates for using Node.js for its suitability in developing microservices while asserting that the architecture can be implemented in any programming language.
Richardrodger nodeday-2014-final
- 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
- 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!"
- 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.
- 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