$30 off During Our Annual Pro Sale. View Details »

Everything as Code

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.

Gareth Rushgrove

March 02, 2016

More Decks by Gareth Rushgrove

Other Decks in Technology


  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

  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

  45. None
  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 Completed Connect Scan at

    07:09, 3.31s elapsed (12 total ports) Nmap scan report for www.puppetlabs.com ( Host is up (0.082s latency). rDNS record for 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 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

  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

  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