Your SlideShare is downloading. ×
Agile Infra @AgileRoots 2009
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Agile Infra @AgileRoots 2009

1,636
views

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.

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,636
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
43
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. AGILE INFRASTRUCTURE
  • 2. ANDREW CLAY SHAFER
  • 3. ANDREW CLAY SHAFER Developer Once Upon A Time
  • 4. Agile Team member ANDREW CLAY SHAFER Developer Once Upon A Time
  • 5. Agile Team member Tolerated at Salt Lake Agile Roundtable ANDREW CLAY SHAFER Developer Once Upon A Time
  • 6. Agile Team member Tolerated at Salt Lake Agile Roundtable ANDREW CLAY SHAFER Developer Once Upon A Time Mostly Worked For Start Ups
  • 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. 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. 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. O H Y E A H , T H E R E I S A LWAY S A D U C K . . .
  • 11. WHAT IS AGILE?
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. BUT WHAT IS AGILE???
  • 23. BUT WHAT IS AGILE??? PLANNING
  • 24. BUT WHAT IS AGILE??? PLANNING ENGINEERING
  • 25. BUT WHAT IS AGILE??? PLANNING ENGINEERING DEVELOPERS
  • 26. BUT WHAT IS AGILE??? PLANNING ENGINEERING DEVELOPERS PRODUCT OWNERS
  • 27. BUT WHAT IS AGILE??? PLANNING ENGINEERING DEVELOPERS PRODUCT OWNERS TESTERS
  • 28. BUT WHAT IS AGILE??? PLANNING ENGINEERING EXECUTIVES DEVELOPERS PRODUCT OWNERS TESTERS
  • 29. BUT WHAT IS AGILE??? PLANNING ENGINEERING EXECUTIVES DEVELOPERS SYSTEM ADMINISTRATORS PRODUCT OWNERS TESTERS
  • 30. BUT WHAT IS AGILE??? PLANNING ENGINEERING EXECUTIVES DEVELOPERS SYSTEM ADMINISTRATORS PRODUCT OWNERS DATABASE ADMINISTRATORS TESTERS
  • 31. BUT WHAT IS AGILE??? PLANNING ENGINEERING EXECUTIVES DEVELOPERS SYSTEM ADMINISTRATORS PRODUCT OWNERS DATABASE ADMINISTRATORS TESTERS NETWORK ENGINEERS
  • 32. BUT WHAT IS AGILE??? PLANNING ENGINEERING EXECUTIVES DEVELOPERS SYSTEM ADMINISTRATORS PRODUCT OWNERS DATABASE ADMINISTRATORS TESTERS NETWORK ENGINEERS DESIGNERS
  • 33. BUT WHAT IS AGILE??? PLANNING ENGINEERING EXECUTIVES DEVELOPERS SYSTEM ADMINISTRATORS PRODUCT OWNERS DATABASE ADMINISTRATORS TESTERS NETWORK ENGINEERS DESIGNERS USABILITY EXPERTS
  • 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. BUT WHAT IS AGILE??? PLANNING ENGINEERING CIRCLE OF HAPPINESS EXECUTIVES DEVELOPERS SYSTEM ADMINISTRATORS PRODUCT OWNERS DATABASE ADMINISTRATORS TESTERS NETWORK ENGINEERS DESIGNERS USABILITY EXPERTS
  • 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. BUT THE WAY SOFTWARE GETS DELIVERED HAS CHANGED A LOT...
  • 38. BUT THE WAY SOFTWARE GETS DELIVERED HAS CHANGED A LOT... ...AND THINGS ARE CHANGING FAST RIGHT NOW .
  • 39. WHO IS WORKING ON A WEB APP?
  • 40. END OF SHRINK WRAP
  • 41. END OF SHRINK WRAP
  • 42. END OF SHRINK WRAP Clouds Are Rising
  • 43. WHO IS WORKING ON A WEB APP?
  • 44. WHO IS WORKING ON A WEB APP? WHERE DOES THAT WEB APP RUN?
  • 45. WHO IS WORKING ON A WEB APP? WHERE DOES THAT WEB APP RUN? WHO TAKES CARE OF THOSE SERVERS?
  • 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. 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. ENGINEERING Version Control Build From Source
  • 49. WHO USES VERSION CONTROL FOR SYSTEM CONFIGURATIONS?
  • 50. WHO USES VERSION CONTROL FOR SYSTEM CONFIGURATIONS? WHO CAN AUTOMATICALLY REBUILD SYSTEMS?
  • 51. Infrastructure is Code!!!
  • 52. Infrastructure is Code!!! SEMANTICS
  • 53. Infrastructure is Code!!! SEMANTICS REPRODUCIBLE
  • 54. Infrastructure is Code!!! SEMANTICS REPRODUCIBLE MAINTAINABLE
  • 55. Infrastructure is Code!!! SEMANTICS REPRODUCIBLE MAINTAINABLE EXTENSIBLE
  • 56. Infrastructure is Code!!! SEMANTICS REPRODUCIBLE MAINTAINABLE EXTENSIBLE SHAREABLE
  • 57. WHO IS USING PUPPET?
  • 58. Infrastructure is Code!!! SEMANTICS REPRODUCIBLE MAINTAINABLE EXTENSIBLE SHAREABLE Open Source Software!
  • 59. HELP ME TO SEE IT...
  • 60. HELP ME TO SEE IT... USING TRADITIONAL TECHNIQUES CONFIGURATIONS TEND TO DRIFT
  • 61. BUT WHY?
  • 62. BUT WHY? BACKLOG OF REQUESTS
  • 63. BUT WHY? BACKLOG OF REQUESTS CONFIGURATION OF CRITICAL SERVICES ARE OFTEN NOT DOCUMENTED AND MUST BE RECREATED
  • 64. BUT WHY? BACKLOG OF REQUESTS CONFIGURATION OF CRITICAL SERVICES ARE OFTEN NOT DOCUMENTED AND MUST BE RECREATED INCONSISTENCIES CAUSE CONFUSION AND MISTAKES
  • 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. 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. Dear Diary,
  • 68. Dear Diary, Today I was on fire for 12 hours...
  • 69. Dear Diary, Today I was on fire for 12 hours... It wasn’t as pleasant as it sounds.
  • 70. Dear Diary, Today I was on fire for 12 hours... It wasn’t as pleasant as it sounds. --Eben Brinson Smith III
  • 71. Dear Diary, Today I was on fire for 12 hours... It wasn’t as pleasant as it sounds. --Eben Brinson Smith III
  • 72. WHAT DOES THAT REALLY MEAN?
  • 73. WHAT DOES THAT REALLY MEAN? DEPLOYMENTS AND UPGRADES ARE EXPENSIVE, TEDIOUS AND ERROR PRONE
  • 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. 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. 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. 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. VIRTUAL MACHINES
  • 79. VIRTUAL MACHINES A NEW ‘MACHINE’ API
  • 80. VIRTUAL MACHINES A NEW ‘MACHINE’ API MORE MACHINES TO CONFIGURE
  • 81. VIRTUAL MACHINES A NEW ‘MACHINE’ API MORE MACHINES TO CONFIGURE DO NOT MAKE GOLDEN IMAGES
  • 82. VIRTUAL MACHINES A NEW ‘MACHINE’ API MORE MACHINES TO CONFIGURE DO NOT MAKE GOLDEN IMAGES REALLY FOIL BALLS
  • 83. VIRTUAL MACHINES A NEW ‘MACHINE’ API MORE MACHINES TO CONFIGURE DO NOT MAKE GOLDEN IMAGES REALLY FOIL BALLS WTF?
  • 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. INFRASTRUCTURE IS CODE!
  • 86. INFRASTRUCTURE IS CODE! AUTOMATE EVERYTHING
  • 87. INFRASTRUCTURE IS CODE! AUTOMATE EVERYTHING GET MORE DONE SPEND LESS TIME DOING IT
  • 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. 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. 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. MORE AND MORE SERVERS TO MANAGE
  • 92. MORE AND MORE SERVERS TO MANAGE BRING IT ON!!!
  • 93. PLANNING Communication Collaboration Estimation Prioritization
  • 94. NON-FUNCTIONAL REQUIREMENTS
  • 95. NON-FUNCTIONAL REQUIREMENTS REQUIREMENTS THAT WILL RENDER THE APPLICATION NON-FUNCTIONAL IF NOT FULFILLED
  • 96. NON-FUNCTIONAL REQUIREMENTS REQUIREMENTS THAT WILL RENDER THE APPLICATION NON-FUNCTIONAL IF NOT FULFILLED WTD?
  • 97. NON-FUNCTIONAL REQUIREMENTS REQUIREMENTS THAT WILL RENDER THE APPLICATION NON-FUNCTIONAL IF NOT FULFILLED WTD? STOP THINKING LIKE THAT
  • 98. REQUIREMENTS ARE REQUIREMENTS
  • 99. REQUIREMENTS ARE REQUIREMENTS A WEB APP IS THE INFRASTRUCTURE
  • 100. REQUIREMENTS ARE REQUIREMENTS A WEB APP IS THE INFRASTRUCTURE WITHOUT INFRASTRUCTURE THERE IS NO APP
  • 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. 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. DEVELOPERS OPERATIONS
  • 104. DEVELOPERS OPERATIONS
  • 105. DEVELOPERS OPERATIONS
  • 106. DEVELOPERS OPERATIONS
  • 107. DEVELOPERS OPERATIONS
  • 108. DEVELOPERS OPERATIONS
  • 109. DEVELOPERS OPERATIONS
  • 110. BOUNDARY OBJECTS DEVELOPERS OPERATIONS
  • 111. BOUNDARY OBJECTS DEVELOPERS OPERATIONS COMMUNITY OF INTEREST
  • 112. BOUNDARY OBJECTS DEVELOPERS OPERATIONS COMMUNITY OF INTEREST
  • 113. BOUNDARY OBJECTS DEVELOPERS OPERATIONS COMMUNITY OF INTEREST WWW .VISIBLEWORKINGS.COM/ANALOGYFEST/MARICK-BOUNDARY-OBJECTS.PDF
  • 114. INFRASTRUCTURE IS CODE!
  • 115. INFRASTRUCTURE IS CODE! PLAN FOR INFRASTRUCTURE REQUIREMENTS
  • 116. INFRASTRUCTURE IS CODE! PLAN FOR INFRASTRUCTURE REQUIREMENTS ...BUT BE WILLING AND ABLE TO CHANGE THEM
  • 117. INFRASTRUCTURE IS CODE! PLAN FOR INFRASTRUCTURE REQUIREMENTS ...BUT BE WILLING AND ABLE TO CHANGE THEM OPERATIONS’ CUSTOMER IS THE APP
  • 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. 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. 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. 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. 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. THE MOST IMPORTANT STATEMENT FROM THE MANIFESTO...
  • 124. THE MOST IMPORTANT STATEMENT FROM THE MANIFESTO... ...MIGHT NOT BE THE VALUES...
  • 125. THE MOST IMPORTANT STATEMENT FROM THE MANIFESTO... ...MIGHT NOT BE THE VALUES... ...OR THE PRINCIPLES...
  • 126. ‘We are uncovering better ways of developing software by doing it and helping others do it.’
  • 127. ‘We are uncovering better ways of developing software by doing it and helping others do it.’
  • 128. KEEP UNCOVERING
  • 129. KEEP UNCOVERING
  • 130. andrew@reductivelabs twitter.com/littleidea
  • 131. QUESTIONS? andrew@reductivelabs twitter.com/littleidea