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".

Transcript

1. But Does It Actually Work? AutomaCon 2015, Portland Fletcher Nichol @fnichol
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