Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AutomaCon 2015 - But Does It Actually Work? Running Your Infrastructure Code For Real

AutomaCon 2015 - But Does It Actually Work? Running Your Infrastructure Code For Real

Unless you want to live in a fantasy world - given the nature of infrastructure code (extremely side effect driven and brittle due to external dependencies) - running this stuff for real is a necessary evil to prove to yourself that it all "still works as advertised".


Fletcher Nichol

September 15, 2015

More Decks by Fletcher Nichol

Other Decks in Technology


  1. But Does It Actually Work? AutomaCon 2015, Portland Fletcher Nichol

  2. None
  3. None
  4. None
  5. @fnichol

  6. –Me, often “Infrastructure code has high entropy”

  7. –Me, also “Infrastructure code must be executed frequently to prevent

    it from degrading over time”
  8. –Devil’s Advocate Me “But, why?”

  9. –Adam Jacob, Web Operations “Enable the reconstruction of the business

    from nothing but a source code repository, an application data backup, and bare metal resources.” Infrastructure as Code
  10. –Fletcher, This Talk “It is software.” Infrastructure as Code

  11. https://flic.kr/p/dp6D4X

  12. Does Code Decay? • Published January, 2001 • Large codebase

    for telephone switches • 100,000,000 LOC (C/C++) • 15-year old codebase • Each release ~20,000,000 LOC
  13. Does Code Decay? Metaphor: software suffering from decay can be

    thought of as diseased
  14. Decayed Code Unit of code is decayed if it is

    harder to change than it should be, measured in terms of effort, interval, and quality
  15. Decayed Code: Measurement 1. Cost of the change, which is

    effectively on the personnel cost for the developers who implemented it 2. Interval to complete the change, the calendar/clock time required 3. Quality of the changed software
  16. Code Decay • Decay is temporal, may be useful to

    add a “more difficult to change than it used to be” to the definition • Code can be ”correct” and still be decayed • Software that is decaying is simultaneously increasing in value
  17. Article Claim “Code decay is the result of previous changes

    to the software”
  18. Decay: Three Classes of Changes 1. Adaptive changes - add

    new functionality to a system 2. Corrective changes - fix faults in the software 3. Perfective changes (“maintenance for the sake of maintenance” or “reengineering”) - are intended to improve the developers’ ability to maintain the software without altering functionality or fixing faults
  19. Symptoms of Code Decay (Selected) 1. Excessively complex (bloated) code

    2. A history of frequent change (a.k.a. code churn) 3. Widely dispersed changes 4. Numerous interfaces (i.e. entry points)
  20. But It Gets Worse • In general, low fault tolerance

    (everyone read Release It!) • Dependency management complexities • Aggressively changing runtimes
  21. Shannon Entropy • From Information theory • Introduced by Claude

    E. Shannon in "A Mathematical Theory of Communication” (1948) • Expected value of the information contained in each message received • Entropy of a message is its amount of uncertainty • Increases when the message is closer to random • Decreases when it is less random
  22. Entropy Example Polling on a political issue

  23. Entropy Example Coin toss

  24. Entropy and Software Systems • Published May, 2011 • Combines

    entropy and testing concepts
  25. Why Do We Test? We test software systems because there

    is uncertainty in its actual behavior.
  26. Why Do We Test? 1. The more we test, the

    more we know about the system under test 2. The more we know about the system under test, the more likely faults can be found
  27. Infrequent Testing 0 22.5 45 67.5 90 Time Entropy

  28. Frequent Testing 0 20 40 60 80 Time Entropy

  29. Frequent Testing 0 20 40 60 80 Time Entropy

  30. Frequent Execution 0 20 40 60 80 Time Entropy

  31. Frequent Execution 0 20 40 60 80 Time Uncertainty Code

    in use Code in decay
  32. –Jez Humble and David Farley, Continuous Delivery “If it hurts,

    do it more frequently, and bring the pain forward.”
  33. –Me, again “Infrastructure code must be executed frequently to prevent

    it from degrading over time”
  34. Thank You! AutomaCon 2015, Portland Fletcher Nichol @fnichol

  35. References Jacob, Adam. “Infrastructure as Code.” Web Operations: Keeping the

    Data on Time. Ed. John Allspaw and Jesse Robbins. Beijing: O’Reilly, 2010. 65-80. Print. Boehm, B.w., and P.n. Papaccio. “Understanding and Controlling Software Costs.” IEEE Transactions on Software Engineering IIEEE Trans. Software Eng. 14.10 (1988): 1462-477. Web. 9 Sept. 2015. Eick, S.g., T.l. Graves, A.f. Karr, J.s. Marron, and A. Mockus. “Does Code Decay? Assessing the Evidence from Change Management Data.” IEEE Transactions on Software Engineering IIEEE Trans. Software Eng. 27.1 (2001): 1-12. Web. 9 Sept. 2015. Yang, Linmin. “Entropy and Software Systems: Towards an Information-theoretic Foundation of Software Testing.” Diss. Washington State U, 2011. Web. 9 Sept. 2015. <https://research.wsulibs.wsu.edu/xmlui/ bitstream/handle/2376/2901/Yang_wsu_0251E_10145.pdf?sequence=1>. “Entropy (information theory).” Wikipedia: The Free Encyclopedia. Wikimedia Foundation, Inc. 7 Sept. 2015. 9 Sept. 2015 <https://en.wikipedia.org/wiki/Entropy_(information_theory)>. Humble, Jez, and David Farley. Continuous Delivery. Upper Saddle River, NJ: Addison-Wesley, 2011. Print.
  36. Image Credits Downtown Portland, OR: https://flic.kr/p/cXAqeb Construction Silhouette: https://flic.kr/p/k1fGAe Bay

    Bridge East Span Under Construction: https://flic.kr/p/wGCczf Lincoln's Inn Library: https://flic.kr/p/dp6D4X Random • Geometry: https://flic.kr/p/6KzZF7 Ballot boxes from the 2008 London elections: https://flic.kr/p/4KBnFw Stock Photography - Canadian Coins: https://flic.kr/p/q6Ufjj Practice. Practice. Practice.: https://flic.kr/p/qSBYah Deserted Beach: https://flic.kr/p/85KM6Q