Agile Infra @AgileRoots 2009

1,822
-1

Published on

The prelude to the talks at Velocity and Agile 2009. A few of the same slides and sentiment, but presented in a different way. More mentions of Puppet specifically for one.

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,822
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
47
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Agile Infra @AgileRoots 2009

  1. 1. AGILE INFRASTRUCTURE
  2. 2. ANDREW CLAY SHAFER
  3. 3. ANDREW CLAY SHAFER Developer Once Upon A Time
  4. 4. Agile Team member ANDREW CLAY SHAFER Developer Once Upon A Time
  5. 5. Agile Team member Tolerated at Salt Lake Agile Roundtable ANDREW CLAY SHAFER Developer Once Upon A Time
  6. 6. Agile Team member Tolerated at Salt Lake Agile Roundtable ANDREW CLAY SHAFER Developer Once Upon A Time Mostly Worked For Start Ups
  7. 7. Agile Team member Tolerated at Salt Lake Agile Roundtable ANDREW CLAY SHAFER Developer Once Upon A Time Mostly Worked For Start Ups Founding Partner Reductive Labs Inc.
  8. 8. Agile Team member All Around Trouble Maker Tolerated at Salt Lake Agile Roundtable ANDREW CLAY SHAFER Developer Once Upon A Time Mostly Worked For Start Ups Founding Partner Reductive Labs Inc.
  9. 9. Agile Team member All Around Trouble Maker Tolerated at Salt Lake Agile Roundtable ANDREW CLAY SHAFER Developer Once Upon A Time Mostly Worked For Start Ups Founding Partner Reductive Labs Inc. The Rest is Complicated...
  10. 10. O H Y E A H , T H E R E I S A LWAY S A D U C K . . .
  11. 11. WHAT IS AGILE?
  12. 12. M A N I F E S T O , 4 VA L U E S , 1 2 P R I N C I P L E S . . .
  13. 13. M A N I F E S T O , 4 VA L U E S , 1 2 P R I N C I P L E S . . .
  14. 14. M A N I F E S T O , 4 VA L U E S , 1 2 P R I N C I P L E S . . .
  15. 15. M A N I F E S T O , 4 VA L U E S , 1 2 P R I N C I P L E S . . .
  16. 16. M A N I F E S T O , 4 VA L U E S , 1 2 P R I N C I P L E S . . .
  17. 17. M A N I F E S T O , 4 VA L U E S , 1 2 P R I N C I P L E S . . .
  18. 18. M A N I F E S T O , 4 VA L U E S , 1 2 P R I N C I P L E S . . .
  19. 19. M A N I F E S T O , 4 VA L U E S , 1 2 P R I N C I P L E S . . .
  20. 20. M A N I F E S T O , 4 VA L U E S , 1 2 P R I N C I P L E S . . .
  21. 21. M A N I F E S T O , 4 VA L U E S , 1 2 P R I N C I P L E S . . .
  22. 22. BUT WHAT IS AGILE???
  23. 23. BUT WHAT IS AGILE??? PLANNING
  24. 24. BUT WHAT IS AGILE??? PLANNING ENGINEERING
  25. 25. BUT WHAT IS AGILE??? PLANNING ENGINEERING DEVELOPERS
  26. 26. BUT WHAT IS AGILE??? PLANNING ENGINEERING DEVELOPERS PRODUCT OWNERS
  27. 27. BUT WHAT IS AGILE??? PLANNING ENGINEERING DEVELOPERS PRODUCT OWNERS TESTERS
  28. 28. BUT WHAT IS AGILE??? PLANNING ENGINEERING EXECUTIVES DEVELOPERS PRODUCT OWNERS TESTERS
  29. 29. BUT WHAT IS AGILE??? PLANNING ENGINEERING EXECUTIVES DEVELOPERS SYSTEM ADMINISTRATORS PRODUCT OWNERS TESTERS
  30. 30. BUT WHAT IS AGILE??? PLANNING ENGINEERING EXECUTIVES DEVELOPERS SYSTEM ADMINISTRATORS PRODUCT OWNERS DATABASE ADMINISTRATORS TESTERS
  31. 31. BUT WHAT IS AGILE??? PLANNING ENGINEERING EXECUTIVES DEVELOPERS SYSTEM ADMINISTRATORS PRODUCT OWNERS DATABASE ADMINISTRATORS TESTERS NETWORK ENGINEERS
  32. 32. BUT WHAT IS AGILE??? PLANNING ENGINEERING EXECUTIVES DEVELOPERS SYSTEM ADMINISTRATORS PRODUCT OWNERS DATABASE ADMINISTRATORS TESTERS NETWORK ENGINEERS DESIGNERS
  33. 33. BUT WHAT IS AGILE??? PLANNING ENGINEERING EXECUTIVES DEVELOPERS SYSTEM ADMINISTRATORS PRODUCT OWNERS DATABASE ADMINISTRATORS TESTERS NETWORK ENGINEERS DESIGNERS USABILITY EXPERTS
  34. 34. BUT WHAT IS AGILE??? PLANNING ENGINEERING CIRCLE OF HAPPINESS EXECUTIVES DEVELOPERS SYSTEM ADMINISTRATORS PRODUCT OWNERS DATABASE ADMINISTRATORS TESTERS NETWORK ENGINEERS DESIGNERS USABILITY EXPERTS
  35. 35. BUT WHAT IS AGILE??? PLANNING ENGINEERING CIRCLE OF HAPPINESS EXECUTIVES DEVELOPERS SYSTEM ADMINISTRATORS PRODUCT OWNERS DATABASE ADMINISTRATORS TESTERS NETWORK ENGINEERS DESIGNERS USABILITY EXPERTS
  36. 36. BUT WHAT IS AGILE??? PLANNING ENGINEERING CIRCLE OF HAPPINESS EXECUTIVES DEVELOPERS SYSTEM ADMINISTRATORS PRODUCT OWNERS DATABASE ADMINISTRATORS TESTERS NETWORK ENGINEERS DESIGNERS USABILITY EXPERTS
  37. 37. BUT THE WAY SOFTWARE GETS DELIVERED HAS CHANGED A LOT...
  38. 38. BUT THE WAY SOFTWARE GETS DELIVERED HAS CHANGED A LOT... ...AND THINGS ARE CHANGING FAST RIGHT NOW .
  39. 39. WHO IS WORKING ON A WEB APP?
  40. 40. END OF SHRINK WRAP
  41. 41. END OF SHRINK WRAP
  42. 42. END OF SHRINK WRAP Clouds Are Rising
  43. 43. WHO IS WORKING ON A WEB APP?
  44. 44. WHO IS WORKING ON A WEB APP? WHERE DOES THAT WEB APP RUN?
  45. 45. WHO IS WORKING ON A WEB APP? WHERE DOES THAT WEB APP RUN? WHO TAKES CARE OF THOSE SERVERS?
  46. 46. WHO IS WORKING ON A WEB APP? WHERE DOES THAT WEB APP RUN? WHO TAKES CARE OF THOSE SERVERS? HOW DO YOU INTERACT WITH THEM?
  47. 47. WHO IS WORKING ON A WEB APP? WHERE DOES THAT WEB APP RUN? WHO TAKES CARE OF THOSE SERVERS? HOW DO YOU INTERACT WITH THEM? ‘THEM’ IS PEOPLE OR SERVERS?
  48. 48. ENGINEERING Version Control Build From Source
  49. 49. WHO USES VERSION CONTROL FOR SYSTEM CONFIGURATIONS?
  50. 50. WHO USES VERSION CONTROL FOR SYSTEM CONFIGURATIONS? WHO CAN AUTOMATICALLY REBUILD SYSTEMS?
  51. 51. Infrastructure is Code!!!
  52. 52. Infrastructure is Code!!! SEMANTICS
  53. 53. Infrastructure is Code!!! SEMANTICS REPRODUCIBLE
  54. 54. Infrastructure is Code!!! SEMANTICS REPRODUCIBLE MAINTAINABLE
  55. 55. Infrastructure is Code!!! SEMANTICS REPRODUCIBLE MAINTAINABLE EXTENSIBLE
  56. 56. Infrastructure is Code!!! SEMANTICS REPRODUCIBLE MAINTAINABLE EXTENSIBLE SHAREABLE
  57. 57. WHO IS USING PUPPET?
  58. 58. Infrastructure is Code!!! SEMANTICS REPRODUCIBLE MAINTAINABLE EXTENSIBLE SHAREABLE Open Source Software!
  59. 59. HELP ME TO SEE IT...
  60. 60. HELP ME TO SEE IT... USING TRADITIONAL TECHNIQUES CONFIGURATIONS TEND TO DRIFT
  61. 61. BUT WHY?
  62. 62. BUT WHY? BACKLOG OF REQUESTS
  63. 63. BUT WHY? BACKLOG OF REQUESTS CONFIGURATION OF CRITICAL SERVICES ARE OFTEN NOT DOCUMENTED AND MUST BE RECREATED
  64. 64. BUT WHY? BACKLOG OF REQUESTS CONFIGURATION OF CRITICAL SERVICES ARE OFTEN NOT DOCUMENTED AND MUST BE RECREATED INCONSISTENCIES CAUSE CONFUSION AND MISTAKES
  65. 65. BUT WHY? BACKLOG OF REQUESTS CONFIGURATION OF CRITICAL SERVICES ARE OFTEN NOT DOCUMENTED AND MUST BE RECREATED INCONSISTENCIES CAUSE CONFUSION AND MISTAKES MORE AND MORE SYSTEMS TO MANAGE
  66. 66. BUT WHY? BACKLOG OF REQUESTS CONFIGURATION OF CRITICAL SERVICES ARE OFTEN NOT DOCUMENTED AND MUST BE RECREATED INCONSISTENCIES CAUSE CONFUSION AND MISTAKES MORE AND MORE SYSTEMS TO MANAGE WORK ON THE BIGGEST FIRE
  67. 67. Dear Diary,
  68. 68. Dear Diary, Today I was on fire for 12 hours...
  69. 69. Dear Diary, Today I was on fire for 12 hours... It wasn’t as pleasant as it sounds.
  70. 70. Dear Diary, Today I was on fire for 12 hours... It wasn’t as pleasant as it sounds. --Eben Brinson Smith III
  71. 71. Dear Diary, Today I was on fire for 12 hours... It wasn’t as pleasant as it sounds. --Eben Brinson Smith III
  72. 72. WHAT DOES THAT REALLY MEAN?
  73. 73. WHAT DOES THAT REALLY MEAN? DEPLOYMENTS AND UPGRADES ARE EXPENSIVE, TEDIOUS AND ERROR PRONE
  74. 74. WHAT DOES THAT REALLY MEAN? DEPLOYMENTS AND UPGRADES ARE EXPENSIVE, TEDIOUS AND ERROR PRONE THE CHANCE THAT DEV, TEST AND PROD ARE CONFIGURED THE SAME APPROACHES ZERO
  75. 75. WHAT DOES THAT REALLY MEAN? DEPLOYMENTS AND UPGRADES ARE EXPENSIVE, TEDIOUS AND ERROR PRONE THE CHANCE THAT DEV, TEST AND PROD ARE CONFIGURED THE SAME APPROACHES ZERO HARDWARE FAILURE CAN BE CATASTROPHIC
  76. 76. WHAT DOES THAT REALLY MEAN? DEPLOYMENTS AND UPGRADES ARE EXPENSIVE, TEDIOUS AND ERROR PRONE THE CHANCE THAT DEV, TEST AND PROD ARE CONFIGURED THE SAME APPROACHES ZERO HARDWARE FAILURE CAN BE CATASTROPHIC HEAVY WEIGHT CHANGE CONTROL PROCESSES SEEM LIKE A GOOD IDEA
  77. 77. WHAT DOES THAT REALLY MEAN? DEPLOYMENTS AND UPGRADES ARE EXPENSIVE, TEDIOUS AND ERROR PRONE THE CHANCE THAT DEV, TEST AND PROD ARE CONFIGURED THE SAME APPROACHES ZERO HARDWARE FAILURE CAN BE CATASTROPHIC HEAVY WEIGHT CHANGE CONTROL PROCESSES SEEM LIKE A GOOD IDEA MORE AND MORE SYSTEMS TO MANAGE
  78. 78. VIRTUAL MACHINES
  79. 79. VIRTUAL MACHINES A NEW ‘MACHINE’ API
  80. 80. VIRTUAL MACHINES A NEW ‘MACHINE’ API MORE MACHINES TO CONFIGURE
  81. 81. VIRTUAL MACHINES A NEW ‘MACHINE’ API MORE MACHINES TO CONFIGURE DO NOT MAKE GOLDEN IMAGES
  82. 82. VIRTUAL MACHINES A NEW ‘MACHINE’ API MORE MACHINES TO CONFIGURE DO NOT MAKE GOLDEN IMAGES REALLY FOIL BALLS
  83. 83. VIRTUAL MACHINES A NEW ‘MACHINE’ API MORE MACHINES TO CONFIGURE DO NOT MAKE GOLDEN IMAGES REALLY FOIL BALLS WTF?
  84. 84. VIRTUAL MACHINES A NEW ‘MACHINE’ API MORE MACHINES TO CONFIGURE DO NOT MAKE GOLDEN IMAGES REALLY FOIL BALLS WTF? ...OR SHOULD I SAY WTD?
  85. 85. INFRASTRUCTURE IS CODE!
  86. 86. INFRASTRUCTURE IS CODE! AUTOMATE EVERYTHING
  87. 87. INFRASTRUCTURE IS CODE! AUTOMATE EVERYTHING GET MORE DONE SPEND LESS TIME DOING IT
  88. 88. INFRASTRUCTURE IS CODE! AUTOMATE EVERYTHING GET MORE DONE SPEND LESS TIME DOING IT PEOPLE SPEND TIME MAKING DECISIONS NOT DOING TEDIOUS WORK OVER AND OVER
  89. 89. INFRASTRUCTURE IS CODE! AUTOMATE EVERYTHING GET MORE DONE SPEND LESS TIME DOING IT PEOPLE SPEND TIME MAKING DECISIONS NOT DOING TEDIOUS WORK OVER AND OVER NO LONGER MANAGING SERVERS, MANAGE SERVICES
  90. 90. INFRASTRUCTURE IS CODE! AUTOMATE EVERYTHING GET MORE DONE SPEND LESS TIME DOING IT PEOPLE SPEND TIME MAKING DECISIONS NOT DOING TEDIOUS WORK OVER AND OVER NO LONGER MANAGING SERVERS, MANAGE SERVICES TAKE ADVANTAGE OF THE PROCESSES AND TOOLS WE HAVE FOR SOFTWARE DEVELOPMENT
  91. 91. MORE AND MORE SERVERS TO MANAGE
  92. 92. MORE AND MORE SERVERS TO MANAGE BRING IT ON!!!
  93. 93. PLANNING Communication Collaboration Estimation Prioritization
  94. 94. NON-FUNCTIONAL REQUIREMENTS
  95. 95. NON-FUNCTIONAL REQUIREMENTS REQUIREMENTS THAT WILL RENDER THE APPLICATION NON-FUNCTIONAL IF NOT FULFILLED
  96. 96. NON-FUNCTIONAL REQUIREMENTS REQUIREMENTS THAT WILL RENDER THE APPLICATION NON-FUNCTIONAL IF NOT FULFILLED WTD?
  97. 97. NON-FUNCTIONAL REQUIREMENTS REQUIREMENTS THAT WILL RENDER THE APPLICATION NON-FUNCTIONAL IF NOT FULFILLED WTD? STOP THINKING LIKE THAT
  98. 98. REQUIREMENTS ARE REQUIREMENTS
  99. 99. REQUIREMENTS ARE REQUIREMENTS A WEB APP IS THE INFRASTRUCTURE
  100. 100. REQUIREMENTS ARE REQUIREMENTS A WEB APP IS THE INFRASTRUCTURE WITHOUT INFRASTRUCTURE THERE IS NO APP
  101. 101. REQUIREMENTS ARE REQUIREMENTS A WEB APP IS THE INFRASTRUCTURE WITHOUT INFRASTRUCTURE THERE IS NO APP A CHANGE IN USAGE PATTERNS CAN CRUSH THE INFRASTRUCTURE
  102. 102. REQUIREMENTS ARE REQUIREMENTS A WEB APP IS THE INFRASTRUCTURE WITHOUT INFRASTRUCTURE THERE IS NO APP A CHANGE IN USAGE PATTERNS CAN CRUSH THE INFRASTRUCTURE REQUIRES COLLABORATION BETWEEN DEV AND OPS
  103. 103. DEVELOPERS OPERATIONS
  104. 104. DEVELOPERS OPERATIONS
  105. 105. DEVELOPERS OPERATIONS
  106. 106. DEVELOPERS OPERATIONS
  107. 107. DEVELOPERS OPERATIONS
  108. 108. DEVELOPERS OPERATIONS
  109. 109. DEVELOPERS OPERATIONS
  110. 110. BOUNDARY OBJECTS DEVELOPERS OPERATIONS
  111. 111. BOUNDARY OBJECTS DEVELOPERS OPERATIONS COMMUNITY OF INTEREST
  112. 112. BOUNDARY OBJECTS DEVELOPERS OPERATIONS COMMUNITY OF INTEREST
  113. 113. BOUNDARY OBJECTS DEVELOPERS OPERATIONS COMMUNITY OF INTEREST WWW .VISIBLEWORKINGS.COM/ANALOGYFEST/MARICK-BOUNDARY-OBJECTS.PDF
  114. 114. INFRASTRUCTURE IS CODE!
  115. 115. INFRASTRUCTURE IS CODE! PLAN FOR INFRASTRUCTURE REQUIREMENTS
  116. 116. INFRASTRUCTURE IS CODE! PLAN FOR INFRASTRUCTURE REQUIREMENTS ...BUT BE WILLING AND ABLE TO CHANGE THEM
  117. 117. INFRASTRUCTURE IS CODE! PLAN FOR INFRASTRUCTURE REQUIREMENTS ...BUT BE WILLING AND ABLE TO CHANGE THEM OPERATIONS’ CUSTOMER IS THE APP
  118. 118. INFRASTRUCTURE IS CODE! PLAN FOR INFRASTRUCTURE REQUIREMENTS ...BUT BE WILLING AND ABLE TO CHANGE THEM OPERATIONS’ CUSTOMER IS THE APP IF THE INFRASTRUCTURE ISN’T WORKING NOTHING IS
  119. 119. INFRASTRUCTURE IS CODE! PLAN FOR INFRASTRUCTURE REQUIREMENTS ...BUT BE WILLING AND ABLE TO CHANGE THEM OPERATIONS’ CUSTOMER IS THE APP IF THE INFRASTRUCTURE ISN’T WORKING NOTHING IS CREATE A CULTURE OF COLLABORATION
  120. 120. INFRASTRUCTURE IS CODE! PLAN FOR INFRASTRUCTURE REQUIREMENTS ...BUT BE WILLING AND ABLE TO CHANGE THEM OPERATIONS’ CUSTOMER IS THE APP IF THE INFRASTRUCTURE ISN’T WORKING NOTHING IS CREATE A CULTURE OF COLLABORATION TAKE ADVANTAGE OF THE PROCESSES AND TOOLS WE HAVE FOR SOFTWARE DEVELOPMENT
  121. 121. INFRASTRUCTURE IS CODE! PLAN FOR INFRASTRUCTURE REQUIREMENTS ...BUT BE WILLING AND ABLE TO CHANGE THEM OPERATIONS’ CUSTOMER IS THE APP IF THE INFRASTRUCTURE ISN’T WORKING NOTHING IS CREATE A CULTURE OF COLLABORATION TAKE ADVANTAGE OF THE PROCESSES AND TOOLS WE HAVE FOR SOFTWARE DEVELOPMENT
  122. 122. INFRASTRUCTURE IS CODE! PLAN FOR INFRASTRUCTURE REQUIREMENTS ...BUT BE WILLING AND ABLE TO CHANGE THEM OPERATIONS’ CUSTOMER IS THE APP IF THE INFRASTRUCTURE ISN’T WORKING NOTHING IS CREATE A CULTURE OF COLLABORATION TAKE ADVANTAGE OF THE PROCESSES AND TOOLS WE HAVE FOR SOFTWARE DEVELOPMENT
  123. 123. THE MOST IMPORTANT STATEMENT FROM THE MANIFESTO...
  124. 124. THE MOST IMPORTANT STATEMENT FROM THE MANIFESTO... ...MIGHT NOT BE THE VALUES...
  125. 125. THE MOST IMPORTANT STATEMENT FROM THE MANIFESTO... ...MIGHT NOT BE THE VALUES... ...OR THE PRINCIPLES...
  126. 126. ‘We are uncovering better ways of developing software by doing it and helping others do it.’
  127. 127. ‘We are uncovering better ways of developing software by doing it and helping others do it.’
  128. 128. KEEP UNCOVERING
  129. 129. KEEP UNCOVERING
  130. 130. andrew@reductivelabs twitter.com/littleidea
  131. 131. QUESTIONS? andrew@reductivelabs twitter.com/littleidea

×