從系統思考看 DevOps:以 microservices 為例 (DevOps: a system dynamics perspective)
118
從系統思考看 DevOps 以 microservices 為 Server Director @ Gogolook 葉秉哲 DevOps: a system dynamics perspective 2017-10-26
-
Upload
william-yeh -
Category
Software
-
view
1.755 -
download
0
Transcript of 從系統思考看 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?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