never done
play

never done jalewis@thoughtworks.com @boicy 1 never done 2 never - PowerPoint PPT Presentation

building systems that are never done jalewis@thoughtworks.com @boicy 1 never done 2 never done Incomplete adjective not having all the necessary or appropriate parts 3 never done Incomplete adjective not having all the necessary or


  1. building systems that are never done jalewis@thoughtworks.com @boicy 1

  2. never done 2

  3. never done Incomplete adjective not having all the necessary or appropriate parts 3

  4. never done Incomplete adjective not having all the necessary or appropriate parts 3

  5. 4

  6. KERRBOX! 4

  7. 5

  8. How big are they?

  9. never done 10

  10. never done 11

  11. never done “This, milord, is my family's axe . We have owned it for almost nine hundred years, see. Of course, sometimes it needed a new blade . And sometimes it has required a new handle , new designs on the metalwork, a little refreshing of the ornamentation . . . but is this not the nine hundred-year-old axe of my family? And because it has changed gently over time, it is still a pretty good axe, y'know. Pretty good.” 11

  12. replaceable component architectures Dan North 12

  13. the future is scary 13

  14. BACK IN 2004 (ISH) 14

  15. 15

  16. TIME PASSES…

  17. TIME PASSES… 16

  18. These companies are doing things a bit di ff erently They can deploy small, independent services on demand They scale teams independently of one another around these services They operate at web-scale if they need to 17

  19. HELL YEAH! CONSULTANTS!

  20. Ability to adopt new technologies and practices Unicorns Enterprise And the speed at which they can deliver software is increasing 19

  21. https://www.thoughtworks.com/radar/ 20

  22. microservices should allow us to go as “fast as possible” be cheap to replace be deployable on demand be resilient on imperfect networks but it’s not as simple as that 21

  23. “the fi rst post-devops architectural style” Neal Ford 22

  24. a note on the law of unintended consequences 23

  25. Consider a single application - its a website, lets call it A A 24

  26. we want to get A into production and since we are hipsters we are going to practice continuous delivery - we will have a full automated build pipeline compile, unit acceptance integration and test test functional test deploy to production deployed on deployed to run on build build integration machine machine environment 25

  27. we want to get A into production and since we are hipsters we are going to practice continuous delivery - we will have a full automated build pipeline Tappety tap compile, unit acceptance integration and test test functional test deploy to production deployed on deployed to run on build build integration machine machine environment 25

  28. we want to get A into production and since we are hipsters we are going to practice continuous delivery - we will have a full automated build pipeline Tappety tap compile, unit acceptance integration and test test functional test deploy to production deployed on deployed to run on build build integration machine machine environment 25

  29. How many environments do we need? 26

  30. How many environments do we need? compile, unit acceptance integration and test test functional test deploy to production deployed on deployed to run on build build integration machine machine environment 27

  31. OK, so we are going to be cool and use microservices A B 28

  32. and we might as well call them something interesting webapp customers 29

  33. and they have a dependency on one another… webapp customers 30

  34. How do we traditionally make sure that new versions of the services work with each other? Let me illustrate this 31

  35. V1 V1 32

  36. git push origin master V1 V1 32

  37. git push origin master V2 V1 V1 32

  38. git push origin master V2 V1 V1 32

  39. git push origin master V2 V1 V1 32

  40. git push origin master V2 V1 V1 32

  41. git push origin master V2 V1 V1 32

  42. V2 V1 What should V2 of the blue app be tested against here 33

  43. This is in production, so presumably we should test against this? V1 34

  44. V1 V1 35

  45. git push origin master V1 V1 git push origin master 35

  46. git push origin master V2 V1 V1 V2 git push origin master 35

  47. git push origin master V2 V1 V1 V2 git push origin master 35

  48. git push origin master V2 V1 V1 V2 git push origin master 35

  49. git push origin master V2 V1 V1 V2 git push origin master 35

  50. git push origin master V2 V1 V1 V2 git push origin master 35

  51. I’m sorry Dave, I can’t let you do that I’m sorry Dave, I can’t let you do that 36

  52. 37

  53. 37

  54. Locks == Delay 38

  55. V1 V1 s V1 s V1 39

  56. 40

  57. 41

  58. 41

  59. 2 services => 4 environments 42

  60. 2 services 43

  61. 2 services 4 43

  62. 2 services 4 >600 43

  63. 44

  64. 45

  65. http://james-iry.blogspot.com.au/2009/05/brief-incomplete-and-mostly-wrong.html 45

  66. <thinks> 46

  67. if: 47

  68. Integration testing if: 47

  69. Integration testing if: Independent deployment 47

  70. Integration testing if: Independent deployment Service versioning / evolution 47

  71. Integration testing if: Independent deployment Service versioning / evolution is hard 47

  72. What about some of our other sacred cows? 48

  73. What about some of our other sacred cows? GRASP YAGNI World of Warcraft SOLID agile DRY BDD emergent design GoF Continuous Delivery TDD XP KISS Refactoring 48

  74. GRASP World of Warcraft SOLID YAGNI agile DRY BDD emergent design GoF Continuous Delivery TDD XP KISS Refactoring 49

  75. 50

  76. http://martinfowler.com/bliki/Yagni.html 50

  77. build out services as you need them minimise holding cost and batch size 51 51

  78. YAGNI World of Warcraft SOLID GRASP agile DRY BDD emergent design GoF Continuous Delivery TDD XP KISS Refactoring 52

  79. Retail Ful fi lment 53

  80. Retail Ful fi lment 54

  81. Retail Ful fi lment 55

  82. High cohesion Retail Ful fi lment Low coupling 56

  83. GRASP YAGNI World of Warcraft SOLID DRY agile BDD emergent design GoF Continuous Delivery TDD XP KISS Refactoring 57

  84. “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” Andrew Hunt, Dave Thomas: The Pragmatic Programmer. 1999-10-01. ISBN: 978-0-2016-1622-4 https://pragprog.com/book/tpp/the-pragmatic-programmer 58

  85. DRY holds across services 59

  86. GRASP YAGNI World of Warcraft SOLID TDD agile DRY BDD emergent design GoF Continuous Delivery XP KISS Refactoring 60

  87. “The London school of Test Driven Development” Mike Feathers 61

  88. should we bother with test driving our code if we are going to throw it away? 62

  89. http://moleseyhill.com/blog/2009/08/27/dreyfus-model/ 63

  90. All rules are contextual 64

  91. Start 65

  92. Start Am I Kent Beck? 65

  93. Start Yes Am I Kent Do what I Beck? think is best 65

  94. Start Yes Am I Kent Do what I Beck? think is best No Am I Dan North? 65

  95. Start Yes Am I Kent Do what I Beck? think is best No Yes Am I Dan Do what I North? think is best 65

  96. Start Yes Am I Kent Do what I Beck? think is best No Yes Am I Dan Do what I North? think is best No 65

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend