Downloaded 122 times
![[中略略]
[後略略]](https://image.slidesharecdn.com/devops-asystemdynamicsperspective-171025153717/85/DevOps-microservices-DevOps-a-system-dynamics-perspective-10-320.jpg)
![Structured programming allows modules
to be recursively decomposed into
provable units […] using the restricted
control structures.
• Structured programming is discipline imposed
upon direct transfer of control.](https://image.slidesharecdn.com/devops-asystemdynamicsperspective-171025153717/85/DevOps-microservices-DevOps-a-system-dynamics-perspective-25-320.jpg)
![Structured programming allows modules
to be recursively decomposed into
provable units […] using the restricted
control structures.
Building on this foundation, disciplines
such as structured analysis and
structured design became popular in the
late 1970s and throughout the 1980s.
• Structured programming is discipline imposed
upon direct transfer of control.](https://image.slidesharecdn.com/devops-asystemdynamicsperspective-171025153717/85/DevOps-microservices-DevOps-a-system-dynamics-perspective-43-320.jpg)
Uploaded byWilliam Yeh
從系統思考看 DevOps：以 microservices 為例 (DevOps: a system dynamics perspective)
This document discusses the perspective of system dynamics on DevOps using microservices as an example, highlighting the importance of understanding dynamic complexity over detail complexity in management. It emphasizes the concepts of structured programming, object-oriented programming, and functional programming, illustrating their impact on coding practices and system design. The talk also explores challenges in adopting microservices and suggests strategies for effective implementation and coordination within DevOps.
More Related Content
Similar to 從系統思考看 DevOps：以 microservices 為例 (DevOps: a system dynamics perspective)
從系統思考看 DevOps：以 microservices 為例 (DevOps: a system dynamics perspective)
- 1. 從系統思考看 DevOps 以 microservices為例例 Server Director @ Gogolook 葉秉哲 DevOps: a system dynamics perspective 2017-10-26
- 2. Why this talk? 3reasons…
- 3.
- 4.
- 5.
- 6.
- 7.
- 9.
- 10.
- 11.
- 12. TOC 觀點 Lean 觀點 http://school.soft-arch.net/blog/157917/devops-a-toc-perspective DevOpsTaiwan Meetup #2 (2016-08-17) DevOps Summit 2016 (2016-07-05) http://school.soft-arch.net/blog/115652/devops-a-lean-perspective Agile Meetup Taipei 2016五⽉月聚會 (2016-05-03) DevOps
- 13.
- 14.
- 15.
- 16.
- 17. 在⼤大多數的管理理情況中，真正的槓桿解在於 了了解動態性複雜 (dynamic complexity)， ⽽而非細節性複雜(detail complexity)。
- 18.
- 19.
- 20. 相互關聯聯的語⾔言 causal-loop diagram (CLD) stock andflow diagram (SFD)
- 21.
- 22. “Uncle Bob” Chapter 3to 6: • Structured programming • Object-oriented programming • Functional programming
- 23. Chapter 3 to6: • Structured programming is discipline imposed upon direct transfer of control. • Object-oriented programming is discipline imposed upon indirect transfer of control. • Functional programming is discipline imposed upon variable assignment. Each of these three paradigms has taken something away from us. Each restricts some aspect of the way we write code. None of them has added to our power or our capabilities. What we have learned over the last half-century is what not to do.
- 24. Chapter 3 to6: • Structured programming is discipline imposed upon direct transfer of control. • Object-oriented programming is discipline imposed upon indirect transfer of control. • Functional programming is discipline imposed upon variable assignment. Each of these three paradigms has taken something away from us. Each restricts some aspect of the way we write code. None of them has added to our power or our capabilities. What we have learned over the last half-century is what not to do. 讓我們⽤用「相互關聯聯的語⾔言」 來來重新詮釋吧！
- 25. Structured programming allowsmodules to be recursively decomposed into provable units […] using the restricted control structures. • Structured programming is discipline imposed upon direct transfer of control.
- 26. Actions to restrict controlstructures • Structured programming is discipline imposed upon direct transfer of control. Actions to decompose modules Complexity of a single programming unit Effort needed to prove the correctness of a programs
- 27. Actions to restrict controlstructures • Structured programming is discipline imposed upon direct transfer of control. Actions to decompose modules Complexity of a single programming unit Effort needed to prove the correctness of a program 分解動作
- 28.
- 29. Actions to restrict controlstructures • Structured programming is discipline imposed upon direct transfer of control. Actions to decompose modules Effort needed to prove the correctness of a program 同 同 同 Same +
- 30.
- 31. Actions to restrict controlstructures • Structured programming is discipline imposed upon direct transfer of control. Actions to decompose modules Complexity of a single programming unit 異異 異異 異異 Opposite -
- 32.
- 33. Actions to restrict controlstructures • Structured programming is discipline imposed upon direct transfer of control. Actions to decompose modules Complexity of a single programming unit Effort needed to prove the correctness of a program 同 同 異異 異異 同 Same + 異異 Opposite -
- 34. Actions to restrict controlstructures • Structured programming is discipline imposed upon direct transfer of control. Actions to decompose modules Complexity of a single programming unit Effort needed to prove the correctness of a program 同 同 異異 異異 同 平衡迴路路 (Balancing loop) 穩定均衡態
- 35.
- 36. Reluctance to tackle theproblem Effort needed to improve engineering quality of programs Complexity of a single programming unit What if… reluctant? 同 同 同 滾雪球迴路路 (Reinforcing loop) 正增強 or 負增強
- 37.
- 38. Actions to restrict controlstructures Actions to decompose modules Complexity of a single programming unit Effort needed to prove the correctness of a program 同 同 異異 異異 同 Reluctance to tackle the problem 同 同 合併來來看！
- 39. Actions to restrict controlstructures Actions to decompose modules Complexity of a single programming unit 同 同 異異 異異 同 Reluctance to tackle the problem 同 同 合併來來看！ ⾯面對抉擇 應對策略略 #2 應對策略略 #1 ?System Dynamics Effort needed to prove the correctness of a program
- 40.
- 41. 在⼤大多數的管理理情況中，真正的槓桿解在於 了了解動態性複雜 (dynamic complexity)，⽽而非 細節性複雜(detail complexity)。 如果我們關注的只是細節性複雜，研究其中數 以千計的變數和複雜細節，實際上只會分散我 們的注意⼒力力，⽽而看不⾒見見那些主要的互動關係 及其他變化型態。
- 42. Chapter 3 to6: • Structured programming is discipline imposed upon direct transfer of control. • Object-oriented programming is discipline imposed upon indirect transfer of control. • Functional programming is discipline imposed upon variable assignment. Each of these three paradigms has taken something away from us. Each restricts some aspect of the way we write code. None of them has added to our power or our capabilities. What we have learned over the last half-century is what not to do.
- 43. Structured programming allowsmodules to be recursively decomposed into provable units […] using the restricted control structures. Building on this foundation, disciplines such as structured analysis and structured design became popular in the late 1970s and throughout the 1980s. • Structured programming is discipline imposed upon direct transfer of control.
- 44. OO is theability, through the use of polymorphism, to gain absolute control over every source code dependency in the system. It allows the architect to create a plugin architecture, in which modules that contain high-level policies are independent of modules that contain low-level details. • Object-oriented programming is discipline imposed upon indirect transfer of control.
- 45. Well-structured applications will besegregated into those components that do not mutate variables and those that do. If we have enough storage and enough processor power, we can make our applications entirely immutable—and, therefore, entirely functional. • Functional programming is discipline imposed upon variable assignment.
- 46. Complexity of asingle programming unit Effort needed to improve engineering quality of programs Actions to impose restriction Each restricts some aspect of the way we write code. 同 異異 同 • Spaghetti • Dependency • Race condition 槓 桿 解 • Structured programming • OOP • FP
- 47. Complexity of asingle programming unit Effort needed to improve engineering quality of programs Actions to impose restriction 為了了簡化視覺呈現，這次演講採⽤用的特殊箭頭 同 異異
- 48. Dev velocity Need forimproving architecture Size of a single service instance Stability # services Need for proper coordination Actions to split services Actions to enhance anti-fragility Desire to take fundamental solutions Operation complexity Actions to merge services Near- sightedness 否則，畫⾯面會變成這樣⋯⋯ 同 同 同 同 同 同 同 同 異異 異異 異異 異異 異異 異異 異異 異異
- 49. 從 系統思考 看DevOps： 以 microservices 為例例
- 50.
- 51.
- 52.
- 53.
- 54.
- 55. Hardware Communication App platform Microservices Domain-drivendesign DevOps: Jenkins, GitLab, ELK, Prometheus… Service infra: ZooKeeper, etcd, Consul, Kafka… Server infra: Ansible, Docker, Kubernetes, Mesos, OpenStack, db… Microservice ecosystem: 4-layer model
- 56. model around businessconcepts adopt a culture of automation hide internal implementation details decentralize all the things deploy independently isolate failure highly observable Domain-driven design CI/CD: Jenkins, GitLab, Docker ecosystem… API-first design: RAML, Swagger, GraphQL… DevOps: Ansible, Docker, Kubernetes… Async choreography: ZooKeeper, etcd, Kafka… Anti-fragility: Akka, Netflix OSS… Monitoring: Prometheus, ELK…
- 57.
- 58.
- 59. 我的切入點／ System Dynamics Modelof Microservices Adoption
- 60.
- 61.
- 62. Dev velocity Need forimproving architecture Size of a single service instance Stability Actions to increase operations efficiency # services Need for proper coordination Actions to split services Actions to enhance anti-fragility Desire to take fundamental solutions # unplanned work Operation complexity Actions to merge services Near- sightedness 意外的敵⼈人 Accidental Adversaries 捨本逐末 Shifting the Burden
- 63. Dev velocity Need forimproving architecture Size of a single service instance Stability Actions to increase operations efficiency # services Need for proper coordination Actions to split services Actions to enhance anti-fragility Desire to take fundamental solutions # unplanned work Operation complexity Actions to merge services Near- sightedness Let’s Begin!
- 64. Dev velocity Need forimproving architecture Size of a single service instance Actions to split services 平衡迴路路； 穩定均衡態
- 65. Dev velocity Need forimproving architecture Size of a single service instance Stability # services Need for proper coordination Operation complexity Actions to merge services Actions to split services 平衡迴路路； 穩定均衡態
- 66. Dev velocity Need forimproving architecture Size of a single service instance Stability # services Need for proper coordination Actions to split services Operation complexity Actions to merge services 雙・穩定均衡態？
- 67. Dev velocity Need forimproving architecture Size of a single service instance Stability # services Need for proper coordination Actions to split services Operation complexity Actions to merge services
- 68. Dev velocity Need forimproving architecture Size of a single service instance Stability # services Need for proper coordination Actions to split services Operation complexity Actions to merge services
- 69. Dev velocity Need forimproving architecture Size of a single service instance Stability # services Need for proper coordination Actions to split services Operation complexity Actions to merge services 滾雪球迴路路； 正增強 or 負增強
- 70. Dev velocity Need forimproving architecture Size of a single service instance Stability # services Need for proper coordination Actions to split services Operation complexity Actions to merge services
- 71. Dev velocity Need forimproving architecture Size of a single service instance Stability # services Need for proper coordination Actions to split services Operation complexity Actions to merge services 意外的敵⼈人 Accidental Adversaries
- 72. Need for improving architecture Sizeof a single service instance # services Need for proper coordination Actions to split services Operation complexity Actions to merge services Dev velocity Stability 意外的敵⼈人 Accidental Adversaries
- 73. Need for improving architecture Sizeof a single service instance # services Need for proper coordination Actions to split services Operation complexity Actions to merge services Dev Ops 意外的敵⼈人 Accidental Adversaries 似曾相識？
- 74. Need for improving architecture Sizeof a single service instance # services Need for proper coordination Actions to split services Operation complexity Actions to merge services Coding Testing 意外的敵⼈人 Accidental Adversaries 似曾相識？
- 75. Need for improving architecture Sizeof a single service instance # services Need for proper coordination Actions to split services Operation complexity Actions to merge services Discovery Delivery 意外的敵⼈人 Accidental Adversaries 似曾相識？
- 76. Stability # services Need forproper coordination Operation complexity Actions to merge services
- 77. Stability # services Need forproper coordination Actions to enhance anti-fragility Operation complexity Actions to merge services model around business concepts adopt a culture of automation hide internal implementation details decentralize all the things deploy independently isolate failure highly observable
- 78. 林林⼦子裡有兩兩條分歧的路路，⽽而我⋯⋯ Stability Actions to enhance anti-fragility Actions to mergeservices ?Two roads diverged in a wood, and I…
- 79. Stability # services Need forproper coordination Actions to enhance anti-fragility Desire to take fundamental solutions Operation complexity Actions to merge services Near- sightedness
- 80. Stability Actions to enhance anti-fragility Desire totake fundamental solutions Actions to merge services Near- sightedness
- 81. Stability # services Need forproper coordination Actions to enhance anti-fragility Desire to take fundamental solutions Operation complexity Actions to merge services Near- sightedness
- 82. # services Need forproper coordination Desire to take fundamental solutions Operation complexity Actions to merge services Near- sightedness Stability Actions to enhance anti-fragility 捨本
- 83. # services Need forproper coordination Desire to take fundamental solutions Operation complexity Actions to merge services Near- sightedness Stability Actions to enhance anti-fragility model around business concepts adopt a culture of automation hide internal implementation details decentralize all the things deploy independently isolate failure highly observable Domain-driven design CI/CD: Jenkins, GitLab, Docker ecosystem… API-first design: RAML, Swagger… DevOps: Ansible, Docker, Kubernetes… Async choreography: ZooKeeper, etcd, Kafka… Anti-fragility: Akka, Netflix OSS… Monitoring: Prometheus, ELK… 撇 開 microsevices 不 論 ， 試 問 ： 這 些 是 本 來來 就 該 做 的 嗎 ？ 本？
- 84. Actions to enhance anti-fragility Desire totake fundamental solutions Near- sightedness 逐末 Stability # services Need for proper coordination Operation complexity Actions to merge services
- 85. # services Need forproper coordination Operation complexity Stability Actions to enhance anti-fragility Desire to take fundamental solutions Actions to merge services Near- sightedness 耽溺 ㄉㄢ ㄋㄧˋ
- 86. Stability # services Need forproper coordination Actions to enhance anti-fragility Desire to take fundamental solutions Operation complexity Actions to merge services Near- sightedness 逐末 捨本 耽溺
- 87. Stability # services Need forproper coordination Actions to enhance anti-fragility Desire to take fundamental solutions Operation complexity Actions to merge services Near- sightedness 捨本逐末 Shifting the Burden
- 88. Dev velocity Need forimproving architecture Size of a single service instance Stability # services Need for proper coordination Actions to split services Actions to enhance anti-fragility Desire to take fundamental solutions Operation complexity Actions to merge services Near- sightedness
- 89. Dev velocity Need forimproving architecture Size of a single service instance Stability # services Need for proper coordination Actions to split services Actions to enhance anti-fragility Desire to take fundamental solutions Operation complexity Actions to merge services Near- sightedness 意外的敵⼈人 Accidental Adversaries 捨本逐末 Shifting the Burden
- 90. 意外的敵⼈人 Accidental Adversaries 捨本逐末 Shifting theBurden 成長上限 Limits to Growth ⽬目標侵蝕 Eroding Goals 惡惡性競爭 Escalation 富者愈富 Success to Successful 公有地悲劇 Tragedy of the Commons 飲鴆⽌止渴 Fixes that Fail 成長與投資不⾜足 Growth and Underinvestment
- 91.
- 92. 從 系統思考 看解法 以 microservices 為例例
- 93.
- 94.
- 95.
- 96. Dev velocity Need forimproving architecture Size of a single service instance Stability # services Need for proper coordination Actions to split services Actions to enhance anti-fragility Desire to take fundamental solutions Operation complexity Actions to merge services Near- sightedness 意外的敵⼈人 Accidental Adversaries 捨本逐末 Shifting the Burden
- 97. Desire to take fundamental solutions Near- sightedness Actionsto merge services Dev velocity Need for improving architecture Size of a single service instance Stability # services Need for proper coordination Actions to split services Actions to enhance anti-fragility Operation complexity 捨本逐末 Shifting the Burden
- 98. Dev velocity Stability Actionsto increase operations efficiency # unplanned work 意外的敵⼈人 Accidental Adversaries
- 99. Desire to take fundamental solutions Near- sightedness Actionsto merge services Dev velocity Need for improving architecture Size of a single service instance Stability Actions to increase operations efficiency # services Need for proper coordination Actions to split services Actions to enhance anti-fragility # unplanned work Operation complexity
- 100. Lean 觀點 http://school.soft-arch.net/blog/115652/devops-a-lean-perspective Agile MeetupTaipei 2016五⽉月聚會 (2016-05-03) TOC 觀點 http://school.soft-arch.net/blog/157917/devops-a-toc-perspective DevOps Taiwan Meetup #2 (2016-08-17) DevOps Summit 2016 (2016-07-05) DevOps 類似的觀念念，其實去年年也講過⋯⋯
- 105. Lean 觀點 http://school.soft-arch.net/blog/115652/devops-a-lean-perspective Agile MeetupTaipei 2016五⽉月聚會 (2016-05-03) TOC 觀點 http://school.soft-arch.net/blog/157917/devops-a-toc-perspective DevOps Taiwan Meetup #2 (2016-08-17) DevOps Summit 2016 (2016-07-05) DevOps 類似的觀念念，其實去年年也講過⋯⋯
- 107.
- 108.
- 109.
- 111. 意外的敵⼈人 Accidental Adversaries 捨本逐末 Shifting theBurden 嘗試導入前，請先做些系統思考
- 112. Dev velocity Need forimproving architecture Size of a single service instance Stability # services Need for proper coordination Actions to split services Actions to enhance anti-fragility Desire to take fundamental solutions Operation complexity Actions to merge services Near- sightedness 意外的敵⼈人 Accidental Adversaries 捨本逐末 Shifting the Burden
- 113.
- 114.
- 115. 意外的敵⼈人 Accidental Adversaries 捨本逐末 Shifting theBurden 成長上限 Limits to Growth ⽬目標侵蝕 Eroding Goals 惡惡性競爭 Escalation 富者愈富 Success to Successful 公有地悲劇 Tragedy of the Commons 飲鴆⽌止渴 Fixes that Fail 成長與投資不⾜足 Growth and Underinvestment
- 116.
- 117.
- 118.