從系統思考看 DevOps:以 microservices 為例 (DevOps: a system dynamics perspective)
Preview:
Citation preview
- 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.
- 8. System thinking Microservices
- 9. [] []
- 10.
- 11. 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
- 12. TOC Lean DevOps Today
- 13. TOC Lean ow ??? POOGI
- 14. System dynamics
- 15. System dynamics
- 16. (dynamic complexity) (detail complexity)
- 17. TOC Lean ow system dynamics POOGI
- 18.
- 19. causal-loop diagram(CLD) stock and ow diagram(SFD)
- 20.
- 21. Uncle Bob Chapter 3 to 6: Structured programming
Object-oriented programming Functional programming
- 22. 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 iswhat not to do.
- 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 iswhat not to do.
- 24. 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.
- 25. 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 Eort needed to prove the correctness of a programs
- 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 Eort needed to prove the correctness of a program
- 27. CLD
- 28. Actions to restrict control structures Structured
programming is discipline imposed upon direct transfer of control.
Actions to decompose modules Eort needed to prove the correctness
of a program Same +
- 29. http://bit.ly/2gxQFSA
- 30. 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 -
- 31. http://bit.ly/2yXLVNk
- 32. 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 Eort needed to prove the correctness of a program Same +
Opposite -
- 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 Eort needed to prove the correctness of a program (Balancing
loop)
- 34. http://bit.ly/2l4hjUx
- 35. Reluctance to tackle the problem Eort needed to improve
engineering quality of programs Complexity of a single programming
unit What if reluctant? (Reinforcing loop) or
- 36. http://bit.ly/2zpyuCb
- 37. Actions to restrict control structures Actions to decompose
modules Complexity of a single programming unit Eort needed to
prove the correctness of a program Reluctance to tackle the
problem
- 38. Actions to restrict control structures Actions to decompose
modules Complexity of a single programming unit Reluctance to
tackle the problem #2 #1 ?System Dynamics Eort needed to prove the
correctness of a program
- 39. http://bit.ly/2zFox4i
- 40. (dynamic complexity) (detail complexity)
- 41. 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 iswhat not to do.
- 42. 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.
- 43. 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.
- 44. 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 immutableand, therefore, entirely functional.
Functional programming is discipline imposed upon variable
assignment.
- 45. Complexity of a single programming unit Eort 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
- 46. Complexity of a single programming unit Eort needed to
improve engineering quality of programs Actions to impose
restriction
- 47. 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
- 48. DevOps microservices
- 49.
http://www.gartner.com/smarterwithgartner/top-10-technology-trends-impacting-infrastructure-operations/
- 50.
http://www.gartner.com/smarterwithgartner/top-10-technology-trends-impacting-infrastructure-operations/
- 51. Microservices
- 52. 2015 2016
- 53. 2016 2017
- 54. 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
- 55. 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-rst design: RAML, Swagger, GraphQL DevOps: Ansible, Docker,
Kubernetes Async choreography: ZooKeeper, etcd, Kafka
Anti-fragility: Akka, Netix OSS Monitoring: Prometheus, ELK
- 56. One Piece
- 57. Microservices
- 58. System Dynamics Model of Microservices Adoption
- 59. microservices #2 #1 ?System Dynamics
- 60. Accidental Adversaries Shifting the Burden
- 61. Dev velocity Need for improving architecture Size of a
single service instance Stability Actions to increase operations
eciency # 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
- 62. Dev velocity Need for improving architecture Size of a
single service instance Stability Actions to increase operations
eciency # 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 Lets Begin!
- 63. Dev velocity Need for improving architecture Size of a
single service instance Actions to split services
- 64. 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
- 65. 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
- 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 or
- 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
- 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 Accidental Adversaries
- 71. 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
- 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 Ops
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 Coding
Testing 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 Discovery
Delivery Accidental Adversaries
- 75. Stability # services Need for proper coordination Operation
complexity Actions to merge services
- 76. 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
- 77. Stability Actions to enhance anti-fragility Actions to
merge services ?Two roads diverged in a wood, and I
- 78. Stability # services Need for proper coordination Actions
to enhance anti-fragility Desire to take fundamental solutions
Operation complexity Actions to merge services Near-
sightedness
- 79. Stability Actions to enhance anti-fragility Desire to take
fundamental solutions Actions to merge services Near-
sightedness
- 80. Stability # services Need for proper coordination Actions
to enhance anti-fragility Desire to take fundamental solutions
Operation complexity Actions to merge services Near-
sightedness
- 81. # services Need for proper coordination Desire to take
fundamental solutions Operation complexity Actions to merge
services Near- sightedness Stability Actions to enhance
anti-fragility
- 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 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-rst design: RAML, Swagger DevOps: Ansible, Docker, Kubernetes
Async choreography: ZooKeeper, etcd, Kafka Anti-fragility: Akka,
Netix OSS Monitoring: Prometheus, ELK microsevices
- 83. Actions to enhance anti-fragility Desire to take
fundamental solutions Near- sightedness Stability # services Need
for proper coordination Operation complexity Actions to merge
services
- 84. # services Need for proper coordination Operation
complexity Stability Actions to enhance anti-fragility Desire to
take fundamental solutions Actions to merge services Near-
sightedness
- 85. Stability # services Need for proper coordination Actions
to enhance anti-fragility Desire to take fundamental solutions
Operation complexity 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
Shifting the Burden
- 87. 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
- 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 Accidental
Adversaries Shifting the Burden
- 89. Accidental Adversaries Shifting the Burden Limits to Growth
Eroding Goals Escalation Success to Successful Tragedy of the
Commons Fixes that Fail Growth and Underinvestment
- 90. (archetype)
- 91. microservices
- 92. Accidental Adversaries Shifting the Burden
- 93. Shifting the Burden
- 94. Accidental Adversaries
- 95. 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
- 96. 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
- 97. Dev velocity Stability Actions to increase operations
eciency # unplanned work Accidental Adversaries
- 98. 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 eciency # services Need for proper coordination
Actions to split services Actions to enhance anti-fragility #
unplanned work Operation complexity
- 99. 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
- 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
- 101. TOC Lean ow system dynamics POOGI
- 102.
- 103. One Piece
- 104. Accidental Adversaries Shifting the Burden
- 105. 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
- 106.
- 107. (archetype)
- 108. Accidental Adversaries Shifting the Burden Limits to
Growth Eroding Goals Escalation Success to Successful Tragedy of
the Commons Fixes that Fail Growth and Underinvestment
- 109. LOOPY
- 110. LOOPY
- 111. LOOPY