Everything as Code

A talk to the Integrated Enterprise Architecture conference about the influence of software eating the world, and the changing role of architecture as a discipline.

Transcript

1. Everything as Code Puppet Labs Gareth Rushgrove Examples, practices and issues with all that software
2. Gareth Rushgrove @garethr
3. Gareth Rushgrove
4. Context Whether you’re in product development or enterprise IT
5. Shadow IT Gareth Rushgrove Control VS
6. Self-service Gareth Rushgrove Control VS
7. VS Rapid software development Gareth Rushgrove Control
8. VS Continuous deployment Gareth Rushgrove Control
9. VS New tools and technologies Gareth Rushgrove Control
10. If Amazon release to production every 11.6 seconds, how often does the Change Approval Board meet? Gareth Rushgrove http://assets.en.oreilly.com/1/event/60/Velocity%20Culture%20Presentation.pdf
11. The gap between the leading edge and every-one-else is growing Gareth Rushgrove
12. 30x Gareth Rushgrove More frequent deployments Faster lead times than their peers 200x 2015 State of DevOps Report
13. 60x Gareth Rushgrove Change success rate Faster mean time to recover 168x 2015 State of DevOps Report
14. “We went from all-hands-on- deck, war-room sort of deployments to non-events” Gareth Rushgrove Jez Miller, Heartland Payment Systems
15. Siloed teams Long cycle times Poor visibility Manual processes Gareth Rushgrove
16. Siloed teams Long cycle times Poor visibility Manual processes Gareth Rushgrove Cross-functional teams Short cycle times Fast feedback Automated processes
17. Change control And why code has advantages for managing change
18. Change management, configuration management, supplier management, capacity management, request fulfilment, problem management, access management. Gareth Rushgrove
19. Avoiding spreadsheets as the source of truth Gareth Rushgrove
20. Going faster, without losing confidence or increasing risk Gareth Rushgrove
21. Gareth Rushgrove Then Move fast and break things
22. Move fast with stable infra Gareth Rushgrove Now
23. Gareth Rushgrove Regular releases reduce risk
24. Applying software development practices to change management Gareth Rushgrove
25. Source code can be checked into version control, so clear understanding of who changed what and when Gareth Rushgrove
26. Strong controls around a central code repository Gareth Rushgrove
27. Single artefacts representing change. Can be signed along with accompanying metadata Gareth Rushgrove
28. Changes can be made through a pipeline, everything is visible and nothing is adhoc Gareth Rushgrove
29. Gareth Rushgrove Login to a computer Make change
30. Gareth Rushgrove Write the code Check syntax Check style Unit tests Acceptance tests Deploy
31. Gareth Rushgrove Write the code Check syntax Check style Unit tests Acceptance tests Deploy Deploy to staging Preflight checks
32. Gareth Rushgrove Write the code Check syntax Check style Unit tests Acceptance tests Deploy Security tests
33. Automate where possible, so manual effort is focused on high risk work Gareth Rushgrove
34. Gareth Rushgrove Acceptance tests Deploy Security tests Manual review by security Automated security tests Automated security tests Is this a high risk change?
35. What is a high risk change? - Change to firewall policy? - Change to authentication code? - Out of hours change? - New user added? Gareth Rushgrove
36. The important thing is the discussion with colleagues in development, operations, etc. Gareth Rushgrove
37. Where is code eating the world Examples of code in use today
38. Infrastructure as code
39. Gareth Rushgrove The architecture docs Your mental model Reality The developers mental model = = = =
40. Gareth Rushgrove The architecture docs Your mental model Reality The developers mental model = = = =
41. If you don’t know the state of your system how can you trust a given change will work? Gareth Rushgrove
42. Gareth Rushgrove
43. Gareth Rushgrove
44. Gareth Rushgrove
46. Gareth Rushgrove
47. - Cut down provisioning time - Single way of changing all systems - Detect and remediate config drift Gareth Rushgrove
48. Acceptance testing
49. From manual runbooks to executable specifications Gareth Rushgrove
50. describe 'azure_vm_classic when creating a machine' do include_context 'with certificate copied to system under test' include_context 'with a known name and storage account name' include_context 'with known network' it_behaves_like 'an idempotent resource' include_context 'destroy left-over created resources after use' it 'should have the correct size' do expect(@machine.role_size).to eq(@config[:optional][:size]) end it 'should have the correct deployment name' do expect(@machine.deployment_name).to eq(@config[:optional][:deployment]) end it 'should have the correct cloud service name' do expect(@machine.cloud_service_name).to eq(@config[:optional] [:cloud_service]) end Reusing unit testing frameworks to automate manual checks
51. Higher-level tools exist with more human language interfaces Scenario: The application should not contain SQL injection vulnerabilities Meta: @id scan_sql_injection @cwe-89 Given a scanner with all policies disabled And the SQL-Injection policy is enabled And the attack strength is set to High And the alert threshold is set to Low When the scanner is run And the XML report is written to the file sql_injection.xml Then no Medium or higher risk vulnerabilities should be present
52. Gareth Rushgrove GOV.UK CDN Acceptance tests
53. - Reduce cost and time per release - Make testing repeatable - Make running tests accessible Gareth Rushgrove
54. Confirming network state
55. Discovered open port 22/tcp on 45.56.74.113 Completed Connect Scan at 07:09, 3.31s elapsed (12 total ports) Nmap scan report for www.puppetlabs.com (45.56.74.113) Host is up (0.082s latency). rDNS record for 45.56.74.113: li924-113.members.linode.com PORT STATE SERVICE 20/tcp filtered ftp-data 21/tcp filtered ftp 22/tcp open ssh 23/tcp filtered telnet 25/tcp filtered smtp 80/tcp open http 110/tcp filtered pop3 443/tcp open https 512/tcp filtered exec 522/tcp filtered ulp 1080/tcp filtered socks 8080/tcp open http-proxy Standard nmap output requires manual analysis
56. it 'has only a limited number of open ports' do expect(@open_ports.count).to eq(3) end it 'exposes a web server' do expect(@open_ports).to include('80/tcp') expect(@open_ports).to include('443/tcp') end it 'exposes an SSH server' do expect(@open_ports).to include('22/tcp') end it 'rejects email traffic' do expect(@closed_ports).to include('25/tcp') end Using a unit testing framework we can make explicit assertions
57. www.puppetlabs.com from 192.168.1.10 has only a limited number of open ports (FAILED - 3) exposes a web server exposes an SSH server rejects accept email traffic (FAILED - 4) Anyone can run the tests and understand what is expected and what is currently broken
58. Code allows for more than just using tools Gareth Rushgrove
59. Answering common questions
60. (expect running-on-all-clients? "selinux") Because people seem to like to disable SELinux
61. (expect (every? redhat? (facts "operatingsystem"))) A one line test to check all machines are using the permitted Operating System
62. (expect latest-on-all-clients? "openssh") A one line test to check we’re running the latest version of Open SSH
63. SELECT uid, name FROM listening_ports l, processes p WHERE l.pid=p.pid; Different tools and interfaces exist. OSquery for example uses SQL to query infrastructure state
64. Creating your own domain specific language Gareth Rushgrove
65. Should architects write code? A relevant tangent
66. Gareth Rushgrove IEEE Why architects should code
67. Developers have more difficulty implementing the architectural choices (e.g. patterns/tactics) than functional features. Gareth Rushgrove
68. Non-architecture savvy developers introduce more defects into architecturally- significant code snippets than architecture-savvy developers. Gareth Rushgrove
69. The answers isn’t to architect harder Gareth Rushgrove
70. More powerpoint will not fix the problem Gareth Rushgrove
71. When software architects write code, the number of defects in the tactical fragments of the systems will be reduced. Gareth Rushgrove
72. The doesn’t mean you should have written more code. Software and architecture are changing Gareth Rushgrove
73. Sharp edges Problems to avoid when introducing code everywhere
74. Speed kills too
75. How to lose $177,222 a second for 45 minutes Gareth Rushgrove
76. Gareth Rushgrove Knight Capital Americas LLC
77. Failure cases are hard. Controls need to operate at the speed of software. Gareth Rushgrove
78. Exacerbating risk
79. The empowered developer problem Gareth Rushgrove
80. The empowered developer systems administrator problem Gareth Rushgrove
81. The importance of teams over individuals Gareth Rushgrove
82. The importance of friction Gareth Rushgrove
83. As people outside the control loop architects are well positioned to introduce the right level of friction Gareth Rushgrove
84. Hiring and skills
85. Skilled developers are expensive Gareth Rushgrove
86. Skilled developers are in demand Gareth Rushgrove
87. Choosing technology to attract developers might be a valid strategy, but has a cost Gareth Rushgrove
88. Gareth Rushgrove Choose boring technology
89. Realise that architecture has a direct influence on hiring and retention Gareth Rushgrove
90. Conclusions Things to ponder later
91. Gareth Rushgrove Software is eating the world
92. Gareth Rushgrove Developers as the new kingmakers
93. Architect as influencer of what code gets written Gareth Rushgrove
94. Architect as custodian of code safety Gareth Rushgrove
95. Architect as cultural change agent Gareth Rushgrove
96. Questions? And thanks for listening