1. 從系統思考看 DevOps
以 microservices 為例例
Server Director @ Gogolook
葉秉哲
DevOps: a system dynamics perspective
2017-10-26

2. Why this talk?
3 reasons…

3. ❶

4. 2015-06-10
40 min
http://bit.ly/microservices-intro

5. 2015-06-10
40 min
https://www.slideshare.net/williamyeh/elements-of-cloudnative-apps
2017-06-23

6. 2015-06-10 2017-06-23
20 min
https://www.slideshare.net/williamyeh/system-dynamics-model-of-microservices-adoption
2017-07-21
不過癮！

7. ❷

9. System thinking
Microservices

10. [中略略]
[後略略]

11. ❸

12. TOC 觀點
Lean 觀點
http://school.soft-arch.net/blog/157917/devops-a-toc-perspective
DevOps Taiwan 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. TOC 觀點
Lean 觀點
DevOps系統思考觀點
Today

14. TOC觀點
Lean 觀點
槓桿解
系統思考觀點
效率取向
因果取向
flow
???
POOGI

15. 系統思考
狹義
廣義
以「系統」⾓角度思考
以「系統動⼒力力學」⾓角度思考
System dynamics

16. 狹義
以「系統動⼒力力學」⾓角度思考
System dynamics

17. 在⼤大多數的管理理情況中，真正的槓桿解在於
了了解動態性複雜 (dynamic complexity)，
⽽而非細節性複雜 (detail complexity)。

18. TOC觀點
Lean 觀點
槓桿解
系統思考觀點
效率取向
因果取向
flow
system dynamics
POOGI

19. 真實世界是由許多因果環組成的，但是我們
卻往往只看到線段。
使我們思考⽀支離破碎的原因之⼀一，是我們的
語⾔言。
如果要看整個系統的相互關聯聯，我們便便需要
相互關聯聯的語⾔言。 相互關聯聯的語⾔言

20. 相互關聯聯的語⾔言
causal-loop diagram
(CLD)
stock and flow diagram
(SFD)

21. 相互關聯聯的語⾔言

22. “Uncle Bob”
Chapter 3 to 6:
• Structured programming
• Object-oriented programming
• Functional programming

23. Chapter 3 to 6:
• 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 to 6:
• 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 allows modules
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
control structures
• 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
control structures
• 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. 兩兩種 CLD 圖⽰示法

29. Actions to restrict
control structures
• 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. http://bit.ly/2gxQFSA

31. Actions to restrict
control structures
• Structured programming is discipline imposed
upon direct transfer of control.
Actions to
decompose modules
Complexity of a single
programming unit
異異
異異
異異 Opposite -

32. http://bit.ly/2yXLVNk

33. Actions to restrict
control structures
• 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
control structures
• 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. http://bit.ly/2l4hjUx

36. Reluctance to tackle
the problem
Effort needed to
improve
engineering quality
of programs
Complexity of a single
programming unit
What if… reluctant?
同
同
同
滾雪球迴路路 (Reinforcing loop)
正增強 or 負增強

37. http://bit.ly/2zpyuCb

38. Actions to restrict
control structures
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
control structures
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. http://bit.ly/2zFox4i

41. 在⼤大多數的管理理情況中，真正的槓桿解在於
了了解動態性複雜 (dynamic complexity)，⽽而非
細節性複雜 (detail complexity)。
如果我們關注的只是細節性複雜，研究其中數
以千計的變數和複雜細節，實際上只會分散我
們的注意⼒力力，⽽而看不⾒見見那些主要的互動關係
及其他變化型態。

42. Chapter 3 to 6:
• 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 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.

44. OO is the ability, 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
be segregated 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 a single
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 a single
programming unit
Effort needed to
improve
engineering quality
of programs
Actions to impose
restriction
為了了簡化視覺呈現，這次演講採⽤用的特殊箭頭
同
異異

48. 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
Desire to take
fundamental
solutions
Operation
complexity
Actions to
merge services
Near-
sightedness
否則，畫⾯面會變成這樣⋯⋯
同 同
同
同
同
同
同
同
異異
異異
異異 異異
異異
異異
異異
異異

49. 從 系統思考 看 DevOps：
以 microservices 為例例

50. http://www.gartner.com/smarterwithgartner/top-10-technology-trends-impacting-infrastructure-operations/

51. http://www.gartner.com/smarterwithgartner/top-10-technology-trends-impacting-infrastructure-operations/

52. 結論／
Microservices 很夯！

53. 2015 2016

54. 2016 2017

55. Hardware
Communication
App platform
Microservices Domain-driven design
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 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, GraphQL…
DevOps: Ansible, Docker, Kubernetes…
Async choreography: ZooKeeper, etcd, Kafka…
Anti-fragility: Akka, Netflix OSS…
Monitoring: Prometheus, ELK…

57. ⼤大秘寶
One Piece

58. 疑點／
很多⼈人嘗試導入 Microservices，
卻困難重重？

59. 我的切入點／
System Dynamics Model of Microservices Adoption

60. ⾯面對
microservices
導入策略略
#2
導入策略略
#1
?System Dynamics

61. 意外的敵⼈人
Accidental Adversaries
捨本逐末
Shifting the Burden

62. 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
Desire to take
fundamental
solutions
# unplanned work
Operation
complexity
Actions to
merge services
Near-
sightedness
意外的敵⼈人
Accidental Adversaries
捨本逐末
Shifting the Burden

63. 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
Desire to take
fundamental
solutions
# unplanned work
Operation
complexity
Actions to
merge services
Near-
sightedness
Let’s Begin!

64. Dev velocity
Need for improving
architecture
Size of a single
service instance
Actions to
split services
平衡迴路路；
穩定均衡態

65. Dev velocity
Need for improving
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 for improving
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 for improving
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 for improving
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 for improving
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 for improving
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 for improving
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
Size of 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
Size of 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
Size of 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
Size of 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 for proper
coordination
Operation
complexity
Actions to
merge services

77. Stability
# services
Need for proper
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
merge services
?Two roads diverged in a wood, and I…

79. Stability
# services
Need for proper
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 to take
fundamental
solutions
Actions to
merge services
Near-
sightedness

81. Stability
# services
Need for proper
coordination
Actions to
enhance
anti-fragility
Desire to take
fundamental
solutions
Operation
complexity
Actions to
merge services
Near-
sightedness

82. # services
Need for proper
coordination
Desire to take
fundamental
solutions
Operation
complexity
Actions to
merge services
Near-
sightedness
Stability
Actions to
enhance
anti-fragility
捨本

83. # services
Need for proper
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 to take
fundamental
solutions
Near-
sightedness
逐末
Stability
# services
Need for proper
coordination
Operation
complexity
Actions to
merge services

85. # services
Need for proper
coordination
Operation
complexity
Stability
Actions to
enhance
anti-fragility
Desire to take
fundamental
solutions
Actions to
merge services
Near-
sightedness
耽溺
ㄉㄢ ㄋㄧˋ

86. Stability
# services
Need for proper
coordination
Actions to
enhance
anti-fragility
Desire to take
fundamental
solutions
Operation
complexity
Actions to
merge services
Near-
sightedness
逐末
捨本
耽溺

87. Stability
# services
Need for proper
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 for improving
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 for improving
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 the Burden
成長上限
Limits to Growth
⽬目標侵蝕
Eroding Goals
惡惡性競爭
Escalation
富者愈富
Success to Successful
公有地悲劇
Tragedy of the Commons 飲鴆⽌止渴
Fixes that Fail
成長與投資不⾜足
Growth and Underinvestment

91. 光是強調要有長遠深廣的觀點是不夠的，領會
基本的系統法則或是看出某⼀一問題背後的結構
也是不夠的。對學習型組織⽽而⾔言，只有當系統
基模 (archetype) 開始成為管理理者思考的⼀一部
分，系統思考才會發揮巨⼤大的功效。
熟習系統基模，是組織開始將系統觀點應⽤用於
實務的第⼀一步。

92. 從 系統思考 看 解法
以 microservices 為例例

93. 意外的敵⼈人
Accidental Adversaries
捨本逐末
Shifting the Burden

94. 捨本逐末
Shifting the Burden

95. 意外的敵⼈人
Accidental Adversaries

96. 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
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
Actions to
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
Actions to increase
operations efficiency
# unplanned work
意外的敵⼈人
Accidental Adversaries

99. Desire to take
fundamental
solutions
Near-
sightedness
Actions to
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 Meetup Taipei 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 Meetup Taipei 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. TOC觀點
Lean 觀點
槓桿解
系統思考觀點
效率取向
因果取向
flow
system dynamics
POOGI

108. 總結

109. ⼤大秘寶
One Piece

111. 意外的敵⼈人
Accidental Adversaries
捨本逐末
Shifting the Burden
嘗試導入前，請先做些系統思考

112. 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
Desire to take
fundamental
solutions
Operation
complexity
Actions to
merge services
Near-
sightedness
意外的敵⼈人
Accidental Adversaries
捨本逐末
Shifting the Burden

113. 知道何時該堅持，何時該妥協，
以及為何妥協。

114. 光是強調要有長遠深廣的觀點是不夠的，領會
基本的系統法則或是看出某⼀一問題背後的結構
也是不夠的。對學習型組織⽽而⾔言，只有當系統
基模 (archetype) 開始成為管理理者思考的⼀一部
分，系統思考才會發揮巨⼤大的功效。
熟習系統基模，是組織開始將系統觀點應⽤用於
實務的第⼀一步。

115. 意外的敵⼈人
Accidental Adversaries
捨本逐末
Shifting the Burden
成長上限
Limits to Growth
⽬目標侵蝕
Eroding Goals
惡惡性競爭
Escalation
富者愈富
Success to Successful
公有地悲劇
Tragedy of the Commons 飲鴆⽌止渴
Fixes that Fail
成長與投資不⾜足
Growth and Underinvestment

116. LOOPY

117. LOOPY
如果只想讀兩兩本書：

118. LOOPY
如果只想讀⼀一本書：