Modern-trade-off analysis

アーキテクチャConference 2024 基調講演
『Modern-trade-off analysis』 分散アーキテクチャにおける現代のトレードオフ分析と今後のソフトウェアアーキテクチャの展望

Neal Ford氏
ThoughtWorks
ディレクター、ソフトウェアアーキテクト

【アブストラクト】
2022年10月にオライリー社から日本語訳が発売された現代的なトレードオフ分析とその実践を学べる書籍「ソフトウェアアーキテクチャ・ハードパーツ―分散アーキテクチャのためのトレードオフ分析」の著者。同書は、現代のソフトウェアアーキテクチャに関わるソフトウェア開発者にとって必携の一冊と言われる。Neal Ford氏は、同書以外にもアーキテクチャに関する複数の本を執筆。
ソフトウェアアーキテクチャにおいて「最善の設計手法」というものは存在せず、すべてはトレードオフの問題です。しかし、それをどのように判断すべきでしょうか？
その答えは「時と場合による」です。
基調講演では、まず「何に依存するのか？」に答えます。そして、アーキテクトや他のチームメンバーがトレードオフを理解し、評価するためのさまざまな手法やツールを紹介し、サービスの粒度を反復的に設計する方法を解説します。 また、古くなったアーキテクチャを進化させるために必要なメカニズムと構造を明らかにし、適合度関数駆動のアーキテクチャが、どのようにしてコードを通じてアーキテクチャとガバナンスを確立するのかを紹介します。これにより、アーキテクチャの基盤を保ちながら、スケーラブルなアーキテクチャの構築を実現します。

Transcript

1. Modern Trade-off Analysis Thoughtworks Director / Software Architect / Meme Wrangler http://www.nealford.com @neal4d Neal Ford 11/25/24
2. First Law of Software Architecture “Everything in software architecture is a trade-off”
3. First Law of Software Architecture “If you think you’ve found something that isn’t a tradeoff, it just means you haven’t identified the tradeoff…yet.” First Corollary:
4. First Law of Software Architecture “You can’t avoid doing it over and over.” Second Corollary:
5. Architecture vs. Design
6. architecture design architecture design architecture vs. design
7. architecture vs. design A C B D architecture design strategic tactical high effort low effort significant tradeoffs insignificant tradeoffs is the choice more about architecture or more about design?
8. architecture vs. design A C B D architecture design strategic tactical high effort low effort significant tradeoffs insignificant tradeoffs “We are considering using microservices for the new system”
9. architecture vs. design A C B D architecture design strategic tactical high effort low effort significant tradeoffs insignificant tradeoffs “We need the cancel button moved to the bottom of the screen”
10. architecture vs. design A C B D architecture design strategic tactical high effort low effort significant tradeoffs insignificant tradeoffs “We're considering breaking the single payment service into separate services, one for each payment type"
11. scenario 1: update credit card processing separate: maintainability, testability, deployability architecture vs. design
12. scenario 2: add a new payment type scenario 1: update credit card processing separate: maintainability, testability, deployability separate: extensibility architecture vs. design
13. scenario 2: add a new payment type scenario 1: update credit card processing separate: maintainability, testability, deployability separate: extensibility scenario 3: use multiple types for payment separate: performance, data consistency architecture vs. design
14. architecture vs. design A C B D architecture design strategic tactical high effort low effort significant tradeoffs insignificant tradeoffs “The Payment Service will be broken up into separate services, one for each payment type"
15. Iterative architecture? adaptable architecture : An architecture that allows incremental additions while maintaining existing functionality. evolutionary architecture : An evolutionary architecture support guided, incremental change across multiple dimensions. emergent design : A design that gradually emerges as understanding of the domain deepens and broadens. Why can’t architecture be emergent like design?
16. why you can’t have emergent architecture design: architecture: behavior ≠ capabilities You can’t emerge capabilities—they require planning.
17. agile architecture “Agile means no architecture!” Agile + architecture = fast feedback Iterative architecture
18. Service Granularity
19. what is the right level of granularity for a service?
20. granularity integrators “when should I consider putting services back together?” service granularity granularity disintegrators “when should I consider breaking apart a service?”
21. service functionality service granularity granularity disintegrators “when should I consider breaking apart a service?”
22. service functionality service granularity granularity disintegrators “when should I consider breaking apart a service?”
23. service functionality service granularity granularity disintegrators “when should I consider breaking apart a service?”
24. code volatility service functionality service granularity granularity disintegrators “when should I consider breaking apart a service?”
25. code volatility code rarely changes code always changes service granularity granularity disintegrators “when should I consider breaking apart a service?”
26. code volatility code rarely changes code always changes service granularity granularity disintegrators “when should I consider breaking apart a service?”
27. code volatility scalability and throughput service functionality service granularity granularity disintegrators “when should I consider breaking apart a service?”
28. scalability and throughput 220,000 / min 1 / min 500 / min service granularity granularity disintegrators “when should I consider breaking apart a service?”
29. scalability and throughput 220,000 / min 1 / min 500 / min service granularity granularity disintegrators “when should I consider breaking apart a service?”
30. code volatility scalability and throughput fault tolerance X service functionality service granularity granularity disintegrators “when should I consider breaking apart a service?”
31. fault tolerance X service granularity granularity disintegrators “when should I consider breaking apart a service?”
32. fault tolerance X service granularity granularity disintegrators “when should I consider breaking apart a service?”
33. code volatility scalability and throughput fault tolerance X access restriction service functionality service granularity granularity disintegrators “when should I consider breaking apart a service?”
34. access restriction service granularity granularity disintegrators “when should I consider breaking apart a service?”
35. code volatility scalability and throughput access restriction fault tolerance X service functionality service granularity granularity disintegrators “when should I consider breaking apart a service?”
36. service granularity granularity disintegrators “when should I consider breaking apart a service?” granularity integrators “when should I consider putting services back together?”
37. database transactions service granularity granularity integrators “when should I consider putting services back together?”
38. “register a new customer” database transactions service granularity profile info security info {profile info, security info} no acid (db) transaction
39. database transactions service granularity granularity integrators “when should I consider putting services back together?”
40. database transactions data dependencies service granularity granularity integrators “when should I consider putting services back together?”
41. data dependencies service granularity 1 2 3 4 5 6
42. 1 2 3 4 5 6 data dependencies service granularity
43. data dependencies service granularity 1 2 3 4 5 6 1 2 4 6
44. data dependencies service granularity 1 2 3 4 5 6 1 2 4 6 3
45. data dependencies service granularity 1 2 3 4 5 6 1 2 4 6 3 5
46. data dependencies service granularity 1 2 4 6 3 5 1 2 3 4 5 6
47. data dependencies service granularity 1 2 4 6 3 5 1 2 3 4 5 6
48. data dependencies service granularity 1 2 4 6 3 5 1 2 3 4 5 6
49. 1 2 4 6 3 5 1 data dependencies service granularity 2 3 4 6 5
50. database transactions data dependencies service granularity granularity integrators “when should I consider putting services back together?”
51. database transactions workflow and choreography data dependencies service granularity granularity integrators “when should I consider putting services back together?”
52. service granularity
53. service granularity 1500ms 4500ms ! responsiveness and performance
54. service granularity ! reliability and data consistency
55. database transactions workflow and choreography data dependencies service granularity granularity integrators “when should I consider putting services back together?”
56. service granularity granularity disintegrators “when should I consider breaking apart a service?” granularity integrators “when should I consider putting services back together?”
57. Build Your Own Trade-off Analyses
58. First Law of Software Architecture “Everything in software architecture is a trade-off”
59. Modern Tradeoff Analysis “What happens when there are no best practices?” ?
60. Business Drivers Architecture Characteristics Trade-off Analysis “Time To Market!” Maintainability Testability Deployability Performance vs. Maintainability Analyzing Architecture Tradeoffs
61. Watch out for the “out of context” trap when analyzing trade-offs.
62. “I can’t decide whether to use shared libraries or shared services for the common functionality in the system.” software architect
63. scalability fault tolerance performance overall change risk heterogeneous code X high code volatility X ability to version changes X X X X X
64. “We have services written in 4 different languages in our ecosystem. Performance and fault tolerance aren't concerns for us – it’s all about managing frequent changes to shared functionality.” software architect
65. Use qualitative analysis to iterate on design, leading to quantitative analysis.
66. “I'm not sure which distributed architecture style would be most appropriate for the new system.” software architect Microservices Service-Based Event-Driven Space-Based
67. maintainability maintainability maintainability maintainability Microservices Service-Based Event-Driven Space-Based
68. Business Drivers Architecture Characteristics Trade-off Analysis “Time To Market!” Maintainability Testability Deployability Analyzing Architecture Tradeoffs
69. maintainability maintainability maintainability maintainability Microservices Service-Based Event-Driven Space-Based
70. “I'm not sure which transactional saga to use for the new system.” software architect
71. epic saga fantasy fiction saga fairy tale saga parallel saga phone tag saga horror story saga time travel saga anthology saga decoupled simplicity responsiveness scalability consistency coordination comm. atomic sync orchestration choreography choreography choreography choreography sync sync sync async async async async orchestration orchestration orchestration atomic atomic atomic eventual eventual eventual eventual saga summary
72. Business Drivers Architecture Characteristics Trade-off Analysis “Time To Market!” Maintainability Testability Deployability Analyzing Architecture Tradeoffs
73. epic saga fantasy fiction saga fairy tale saga parallel saga phone tag saga horror story saga time travel saga anthology saga decoupled simplicity responsiveness scalability consistency coordination comm. atomic sync orchestration choreography choreography choreography choreography sync sync sync async async async async orchestration orchestration orchestration atomic atomic atomic eventual eventual eventual saga summary eventual
74. “Now that the system is in place, we need to demonstrate overall agility to support our fast time-to-market needs.” software architect Quantitative Analysis
75. “An architectural fitness function provides an objective integrity assessment of some architectural characteristic(s).” architecture fitness functions Quantitative Analysis
76. average development to release hours and calendar days for features or bugs based on sizing (broken down by development, testing, and deployment effort) Quantitative Analysis average hours time
77. Quantitative Analysis number of errors and bugs over time # errors and bugs time
78. Model relevant business use-case scenarios to identify trade-offs.
79. “I wonder if we should have a single payment service or a separate service for each payment type.” software architect
80. scenario 1: update credit card processing separate: maintainability, testability, deployability
81. scenario 2: add a new payment type scenario 1: update credit card processing separate: maintainability, testability, deployability separate: extensibility
82. scenario 2: add a new payment type scenario 1: update credit card processing separate: maintainability, testability, deployability separate: extensibility scenario 3: use multiple types for payment separate: performance, data consistency
83. Business Drivers Architecture Characteristics Trade-off Analysis “Time To Market!” Maintainability Testability Deployability Analyzing Architecture Tradeoffs
84. scenario 2: add a new payment type scenario 1: update credit card processing separate: maintainability, testability, deployability separate: extensibility scenario 3: use multiple types for payment separate: performance, data consistency
85. Avoid over-evangelizing a particular solution or technology
86. “You should always use publish-and-subscribe broadcast messaging using topics because it supports architectural extensibility and evolutionary architecture!” software architect
87. bidder consumer consumer consumer bid capture consumer consumer consumer bid tracking consumer bid analytics consumer consumer queue item bid queue item bid queue item bid bid history consumer consumer consumer queue item bid
88. item bid bidder topic consumer consumer consumer bid capture consumer consumer consumer bid tracking consumer bid analytics consumer consumer bid history consumer consumer consumer
89. “You should always use publish-and-subscribe broadcast messaging using topics because it supports architectural extensibility and evolutionary architecture!” software architect “Wow, you are SO right! We're going to take your advice and always use it for everything.“
90. A little while later...
91. item bid producer topic consumer consumer consumer bid capture consumer consumer consumer bid tracking consumer bid analytics consumer consumer “I can't create separate contracts for each of the services!” ! “We just had a security breach because everyone has uncontrolled access to that data!” ! “I can't use auto-scaling because I don't have access to the queue-depth!” !
92. Modern Trade-off Analysis Thoughtworks Director / Software Architect / Meme Wrangler http://www.nealford.com @neal4d Neal Ford 11/25/24