richardrodger-microservice-algebra-cluj-apr.pdf
•
0 likes•5 views
This presentation delves into the mathematical principles underpinning microservices, drawing inspiration from historical numeral systems to illustrate the significance of adopting efficient mental models in software architecture. By contrasting the complexities of Roman numerals with the streamlined Indian numerical system, the talk sets the stage for rethinking software design through an algebraic lens, where microservices are seen as algebraic functions transforming inputs to outputs, akin to CRUD operations. The core idea revolves around conceptualizing microservices as operations on messages, ensuring seamless service integration within complex systems through transport independence and pattern matching. This approach fosters a loosely coupled architecture where services communicate based on message content rather than direct identities, enhancing system flexibility and scalability. Practical examples, including the development of a Node.js module search engine, demonstrate the application of these concepts, showcasing the ease of system expansion and modification when services are designed to interact through a message-driven paradigm. The presentation concludes by underscoring the benefits of this methodology, such as increased system adaptability, easier management of technical debt, and a more granular approach to system evolution, advocating for a shift towards viewing microservices as integral components of a coherent and scalable system architecture.
Recommended
Recommended
More Related Content
Similar to richardrodger-microservice-algebra-cluj-apr.pdf
Similar to richardrodger-microservice-algebra-cluj-apr.pdf (20)
More from Richard Rodger
More from Richard Rodger (20)
Recently uploaded
Recently uploaded (20)
richardrodger-microservice-algebra-cluj-apr.pdf
- 1. The Algebra of Microservices 𝜇0(m0) = {mʹ 0, mʹ 1, ..., mʹ n} Richard Rodger @rjrodger
- 2. How did the Romans do Long Division?
- 3. LXXII MMMDCXII L rem XII
- 4. How did the Romans do Addition?
- 5. 1. Normalize: IV → IIII 2. Concatenate: IIII + XI → IIIIXI 3. Sort, descending: IIIIXI → XIIIII 4. Reduce: XIIIII → XV IV + XI = ?
- 6. How did the Romans do Subtraction?
- 7. 1. Normalize: XXIV → XXIIII 2. Eliminate: XXIIII - XV → XIIII - V 3. Expand: XIIII - V → VIIIIIIIII - V 4. Repeat 2 and 3 until no moves left 5. Reduce: IIIIIIIII → IX XXIV - XV = ?
- 8. How did the Romans do Multiplication?
- 9. III → 3 VI → 6 → 110 III × VI = ? 3 × 001 × 0 = 0 3 × 010 × 1 = 6 3 × 100 × 1 = 12 18 bit shifting
- 10. How did the Romans do Division?
- 11. they didn't
- 13. How did the Indians do Division?
- 14. 72 3612 50 rem 12 LXXII MMMDCXII L rem XII
- 15. Good Mental Models make you More Intelligent
- 16. What Mental Model describes your Software Architecture?
- 17. An "algebra" is a good mental model. What is an algebra anyway?
- 18. function formula arguments value add x + y 1, 2 3 multiply x * y 2, 3 6 negate - x 4 -4 square x2 5 25 max x|x >= y, ∀y,x ∈ A 6, 7, 8 8
- 19. You put numbers in ... you get a number out. You put something in ... You get the same thing out. That's an algebra
- 20. operation before after create [r0, r1, ..., rn] [r0, r1, ..., rn, , rn+1] read [r0, r1, ..., rn] [r0, r1, ..., rn] update [r0, r1, ..., ri, ..., rn] [r0, r1, ..., riʹ, ..., rn] delete [r0, r1, ..., rk-1, rk, rk+1, ..., rn] [r0, r1, ..., rk-1, rk+1, ..., rn]
- 21. Update: • validation • permission • modify • logging • finally, update record data
- 22. operation before after update [r0, r1, ..., ri, ..., rn] user context business rules infrastructure special cases [r0, r1, ..., riʹ, ..., rn]
- 23. Our programming models have too many features.
- 24. Question: how good is your component model?
- 27. •reusable? •well-defined (strict!) interfaces? •low coupling and high coherence? •independently deployable? •composable? Components:
- 29. Components make it easy to build big things out of little things.
- 30. Composition! ax2 + bx + c
- 32. ... if you define an algebra!
- 33. How?
- 34. We need things that are "easy" to combine.
- 35. component model interface dimensionality command line •stream of bytes HTTP REST •verbs (GET, POST, ...) •headers (mini-formats) Functions •arguments •types (scalar and complex) Objects •methods (instance and static) •properties (instance and static) •interfaces and class hierarchy Plugins •configuration •lifecycle •shared data structures
- 36. component model identity command line none HTTP REST network location and URL path Functions reference or pointer Objects reference or pointer Plugins integration hooks
- 37. Command line pipes are a highly effective component model because: a) no concept of identity b) low dimension interface
- 38. The need to identify components to each other is bad because you: •lose the ability to swap •require static configuration •get an hidden extra dimension
- 39. A component interface with many dimensions is bad because you: •get combinatorial explosion •need "design patterns" •have a weak human brain
- 40. You can use microservices as a component model if you: •remove the need for identity •use schema-free messages
- 41. Little web servers with REST APIs are not composable.
- 42. Strictly enforced message schemas are not composable.
- 43. Topic-based message buses are not composable.
- 44. You can use microservices as a component model if you have two properties: •Transport Independence •removes identity •Pattern matching •one schema-free dimension
- 48. Pattern Matching
- 55. Too Much Theory!
- 56. How do you decide which microservices to build? How can you use microservices as powerful components?
- 58. "Build a user registration page"
- 59. Requirements ๏ a) capture user details ๏ b) send confirmation email
- 60. Requirements ๏ a) capture user details ๏ b) send confirmation email Messages ๏ a) register-user: {name: ..., email: ...} ๏ b) confirm-email: {email: ...}
- 61. Requirements ๏ a) capture user details ๏ b) send confirmation email Messages ๏ a) register-user: {name: ..., email: ...} ๏ b) confirm-email: {email: ...} Services ๏ registration sends register-user to user ๏ user sends confirm-email to mailer
- 62. user registration mailer register-user confirm-email
- 63. When do you need an answer? ๏Now: synchronous ๏Never: asynchronous
- 64. Who does the work? ๏One: message consumed ๏Many: message observed
- 65. micro- service A micro- service B solid line means synchronous solid arrow means consumed hexagons are microservices synchronous/consumed request-response
- 66. micro- service A micro- service B dashed line means asynchronous empty arrow means observed asynchronous/observed publish-subscribe
- 67. micro- service A micro- service B solid line means synchronous empty arrow means observed synchronous/observed sidewinder
- 68. micro- service A micro- service B dashed line means asynchronous solid arrow means consumed asynchronous/consumed winner-take-all
- 69. Visual conventions Service Synchronous Message Asynchronous Message Consumed Message Observed Message
- 71. Let's build a Search Engine for Node.js modules... Business Requirements: ๏ a) search for Node.js modules ๏ b) index published Node.js modules ๏ c) show Node.js module details
- 74. Requirements ๏ a) search for Node.js modules Messages ๏ role:search,cmd:search (sync+consume) Services ๏ web sends role:search,cmd:search to search
- 76. Requirements ๏ b) index published Node.js modules Messages ๏ role:search,cmd:insert (async+observe) Services ๏ npm sends role:search,cmd:insert to search
- 78. Requirements ๏ c) show Node.js module details Messages ๏ role:info,cmd:get (sync+consume) Services ๏ web sends role:info,cmd:get to info
- 80. Requirements ๏ c) show Node.js module details Messages ๏ role:info,need:part (async+observe) ๏ role:info,collect:part (async+observe) Services ๏ info sends role:info,need:part to npm, github ๏ npm, github send role:info,collect:part to info
- 83. Good Mental Models make you More Intelligent
- 84. Messages are operations on data
- 85. Messages: You put data in ... You get data out. m : D ↦ D
- 87. Microservices: You put messages in ... You get messages out. 𝜇 : M ↦ M
- 89. Send register-user message to registration service: register-user registration
- 90. What really happens: (because GDPR!) register-user registration update-personal personal-data storage update-profile user-profile
- 91. Your mental model: (messages first!) register-user update-personal update-profile registration( )
- 92. Why do this? What do you get?
- 93. New requirement? New message and new microservice (maybe)
- 94. Changed requirement? New microservice on subset of messages
- 95. Technical debt? Delete and replace microservice - no refactoring!
- 96. Latency problems? Combine services but keep messages
- 97. Want to know what's going on? Just monitor message flows
- 98. A search engine for Node.js modules: github.com/nodezoo senecajs.org
- 100. A social network for the conferences and events industry