Devel-ops: Bringing development practices to operations tasks

A presentation at Dot Net Notts - July 2019 in July 2019 in Nottingham, UK by Jonathan Relf

Slide 1

Slide 1

29th July 2019 Jonathan Relf DEVEL-OPS

Slide 2

Slide 2

Commify is the team behind a global portfolio of business messaging brands. We work with more than 45,000 companies, helping them transform their mobile communications with their customers and staff.

Slide 3

Slide 3

We provide SMS, voice, web, IP/OTT, email and intelligent multichannel messaging services both on a self-serve basis (through an online platform or API), and as tailored solutions to more complex needs. www.commify.com

Slide 4

Slide 4

BRINGING DEVELOPMENT PRACTICES TO OPERATIONS TASKS DEVEL-OPS

Slide 5

Slide 5

Slide 6

Slide 6

THE IRON AGE OF I.T.

Slide 7

Slide 7

THE CLOUD AGE OF I.T.

Slide 8

Slide 8

Infrastructure As Code @jbjon

Slide 9

Slide 9

“UNRELIABLE SOFTWARE DEPENDING ON RELIABLE HARDWARE TO RELIABLE SOFTWARE RUNNING ON UNRELIABLE HARDWARE” Infrastructure As Code @jbjon

Slide 10

Slide 10

https://www.slideshare.net/bgracely/enterprise-devops-emc-world-2015-jez-humble-spotlight-session

Slide 11

Slide 11

https://www.slideshare.net/bgracely/enterprise-devops-emc-world-2015-jez-humble-spotlight-session

Slide 12

Slide 12

https://www.slideshare.net/bgracely/enterprise-devops-emc-world-2015-jez-humble-spotlight-session

Slide 13

Slide 13

https://www.slideshare.net/bgracely/enterprise-devops-emc-world-2015-jez-humble-spotlight-session

Slide 14

Slide 14

Martin Fowler, DevOpsCulture, 2015 @jbjon

Slide 15

Slide 15

“ONE COMMON ANTI-PATTERN WHEN INTRODUCING DEVOPS TO AN ORGANIZATION IS TO ASSIGN SOMEONE THE ROLE OF ‘DEVOPS’ OR TO CALL A TEAM A ‘DEVOPS TEAM’. DOING SO PERPETUATES THE KINDS OF SILOS THAT DEVOPS AIMS TO BREAK DOWN…” Martin Fowler, DevOpsCulture, 2015 @jbjon

Slide 16

Slide 16

Slide 17

Slide 17

DEVOPS SHOULD NOT BE VS Devs Ops

Slide 18

Slide 18

Slide 19

Slide 19

DEVOPS SHOULD BE MORE:

Slide 20

Slide 20

Jez Humble @jbjon

Slide 21

Slide 21

DEVOPS IS “A CROSS-DISCIPLINARY COMMUNITY OF PRACTICE DEDICATED TO THE STUDY OF BUILDING, EVOLVING AND OPERATING RAPIDLYCHANGING RESILIENT SYSTEMS AT SCALE.” Jez Humble @jbjon

Slide 22

Slide 22

@jbjon

Slide 23

Slide 23

Unknown @jbjon

Slide 24

Slide 24

“THE DEFINITION OF INSANITY IS REPEATING THE SAME MISTAKES OVER AND OVER AGAIN AND EXPECTING DIFFERENT RESULTS” Unknown @jbjon

Slide 25

Slide 25

Jonathan Relf @jbjon

Slide 26

Slide 26

“THE DEFINITION OF INSANITY IN I.T. OPERATIONS IS MANUALLY REPEATING A TASK OVER AND OVER AGAIN AND EXPECTING THE SAME RESULTS” Jonathan Relf @jbjon

Slide 27

Slide 27

Jeff Sussna, author of “Designing Delivery” @jbjon

Slide 28

Slide 28

“DEVOPS HAS BECOME MORE ABOUT THOSE DETAILS (CONTAINERS, SERVERLESS, SRE, OBSERVABILITY, ETC.) AND LESS ABOUT THE BIG PICTURE. AND, TO SOME DEGREE THE CULTURAL ASPECTS OF DEVOPS HAVE TAKEN A BACK SEAT TO A FOCUS ON FAST LINEAR DELIVERY. THIS PENDULUM WILL NEED TO SWING BACK AT SOME POINT.” Jeff Sussna, author of “Designing Delivery” @jbjon

Slide 29

Slide 29

2017

Slide 30

Slide 30

2018

Slide 31

Slide 31

Slide 32

Slide 32

Slide 33

Slide 33

Slide 34

Slide 34

Slide 35

Slide 35

Slide 36

Slide 36

Slide 37

Slide 37

Slide 38

Slide 38

Slide 39

Slide 39

Slide 40

Slide 40

Slide 41

Slide 41

https://landscape.cncf.io/

Slide 42

Slide 42

THOUGHTWORKS RADAR @jbjon https://www.thoughtworks.com/radar/tools

Slide 43

Slide 43

https://blogs.technet.microsoft.com/xdot509/2013/07/24/getting-started-with-windows-azure-part-2-what-are-cloud-services/

Slide 44

Slide 44

https://blogs.technet.microsoft.com/xdot509/2013/07/24/getting-started-with-windows-azure-part-2-what-are-cloud-services/

Slide 45

Slide 45

https://blogs.technet.microsoft.com/xdot509/2013/07/24/getting-started-with-windows-azure-part-2-what-are-cloud-services/

Slide 46

Slide 46

https://blogs.technet.microsoft.com/xdot509/2013/07/24/getting-started-with-windows-azure-part-2-what-are-cloud-services/

Slide 47

Slide 47

WHY BOTHER DEFINING YOUR OWN INFRASTRUCTURE IN CODE? @jbjon

Slide 48

Slide 48

REGULATORY REQUIREMENTS

Slide 49

Slide 49

3RD PARTY SOLUTION UNCERTAINTY

Slide 50

Slide 50

HARDEN APPLICATION HOSTING

Slide 51

Slide 51

AVOID VENDOR LOCK-IN

Slide 52

Slide 52

Slide 53

Slide 53

THE FOUR STAGES OF INFRASTRUCTURE PROVISIONING CONFIGURING MAINTENANCE TERMINATION @jbjon

Slide 54

Slide 54

PROVISIONING @jbjon

Slide 55

Slide 55

PROVISIONING ▸ Easier since virtualisation @jbjon

Slide 56

Slide 56

PROVISIONING ▸ Easier since virtualisation ▸ Started using ISO images @jbjon

Slide 57

Slide 57

PROVISIONING ▸ Easier since virtualisation ▸ Started using ISO images ▸ Risk of out of date, unpatched VMs @jbjon

Slide 58

Slide 58

CONFIGURATION @jbjon

Slide 59

Slide 59

CONFIGURATION ▸ Can be where most configuration drift is added if not automated @jbjon

Slide 60

Slide 60

CONFIGURATION ▸ Can be where most configuration drift is added if not automated ▸ ‘Tinkering’ @jbjon

Slide 61

Slide 61

CONFIGURATION ▸ Can be where most configuration drift is added if not automated ▸ ‘Tinkering’ ▸ ‘Snowflake servers’ @jbjon

Slide 62

Slide 62

CONFIGURATION ▸ Can be where most configuration drift is added if not automated ▸ ‘Tinkering’ ▸ ‘Snowflake servers’ ▸ Configuration Management software like Puppet & Chef @jbjon

Slide 63

Slide 63

MAINTENANCE @jbjon

Slide 64

Slide 64

MAINTENANCE ▸ Updates or upgrades of software components @jbjon

Slide 65

Slide 65

MAINTENANCE ▸ Updates or upgrades of software components ▸ From security patches to in-place upgrades of O.S. @jbjon

Slide 66

Slide 66

MAINTENANCE ▸ Updates or upgrades of software components ▸ From security patches to in-place upgrades of O.S. ▸ Ordering of patches may affect outcome @jbjon

Slide 67

Slide 67

MAINTENANCE ▸ Updates or upgrades of software components ▸ From security patches to in-place upgrades of O.S. ▸ Ordering of patches may affect outcome ▸ Scripting can help ensure consistency @jbjon

Slide 68

Slide 68

TERMINATION @jbjon

Slide 69

Slide 69

TERMINATION ▸ Fear of shutting off servers @jbjon

Slide 70

Slide 70

TERMINATION ▸ Fear of shutting off servers ▸ Treating servers like “pets, not cattle” @jbjon

Slide 71

Slide 71

TERMINATION ▸ Fear of shutting off servers ▸ Treating servers like “pets, not cattle” ▸ Anti-pattern: Celebrating up-time @jbjon

Slide 72

Slide 72

TERMINATION ▸ Fear of shutting off servers ▸ Treating servers like “pets, not cattle” ▸ Anti-pattern: Celebrating up-time ▸ Plan for the fact an instance could disappear @jbjon

Slide 73

Slide 73

Slide 74

Slide 74

4 GOALS OF INFRASTRUCTURE AS CODE @jbjon

Slide 75

Slide 75

4 GOALS OF INFRASTRUCTURE AS CODE Kief Morris @jbjon

Slide 76

Slide 76

4 GOALS OF INFRASTRUCTURE AS CODE I.T. INFRASTRUCTURE SUPPORTS & ENABLES CHANGE Kief Morris @jbjon

Slide 77

Slide 77

4 GOALS OF INFRASTRUCTURE AS CODE Kief Morris @jbjon

Slide 78

Slide 78

4 GOALS OF INFRASTRUCTURE AS CODE CHANGES TO THE SYSTEM ARE ROUTINE WITHOUT DRAMA OR STRESS Kief Morris @jbjon

Slide 79

Slide 79

4 GOALS OF INFRASTRUCTURE AS CODE Kief Morris @jbjon

Slide 80

Slide 80

4 GOALS OF INFRASTRUCTURE AS CODE I.T. STAFF SPEND THEIR TIME ON VALUABLE THINGS… NOT REPETITIVE TASKS Kief Morris @jbjon

Slide 81

Slide 81

4 GOALS OF INFRASTRUCTURE AS CODE Kief Morris @jbjon

Slide 82

Slide 82

4 GOALS OF INFRASTRUCTURE AS CODE USERS ARE ABLE TO DEFINE, PROVISION, AND MANAGE THE RESOURCES THEY NEED WITHOUT I.T. STAFF TO DO IT FOR THEM Kief Morris @jbjon

Slide 83

Slide 83

Slide 84

Slide 84

DEFINITION TOOLS @jbjon

Slide 85

Slide 85

DEFINITION TOOLS ▸ Good Infrastructure As Code tools @jbjon

Slide 86

Slide 86

DEFINITION TOOLS ▸ Good Infrastructure As Code tools ▸ have scriptable interfaces @jbjon

Slide 87

Slide 87

DEFINITION TOOLS ▸ Good Infrastructure As Code tools ▸ have scriptable interfaces ▸ can be run unattended @jbjon

Slide 88

Slide 88

DEFINITION TOOLS ▸ Good Infrastructure As Code tools ▸ have scriptable interfaces ▸ can be run unattended ▸ can be tailored through config @jbjon

Slide 89

Slide 89

DEFINITION TOOLS ▸ Good Infrastructure As Code tools ▸ have scriptable interfaces ▸ can be run unattended ▸ can be tailored through config ▸ allow tasks to be defined in code @jbjon

Slide 90

Slide 90

DEFINITION TOOLS ▸ Good Infrastructure As Code tools ▸ have scriptable interfaces ▸ can be run unattended ▸ can be tailored through config ▸ allow tasks to be defined in code ▸ the definition files become ‘living documentation’ @jbjon

Slide 91

Slide 91

VERSION CONTROL @jbjon

Slide 92

Slide 92

VERSION CONTROL ▸ Natural part of development workflow @jbjon

Slide 93

Slide 93

VERSION CONTROL ▸ Natural part of development workflow ▸ branching, rollbacks, ownership @jbjon

Slide 94

Slide 94

VERSION CONTROL ▸ Natural part of development workflow ▸ branching, rollbacks, ownership ▸ Single point of truth @jbjon

Slide 95

Slide 95

VERSION CONTROL ▸ Natural part of development workflow ▸ branching, rollbacks, ownership ▸ Single point of truth ▸ Living documentation @jbjon

Slide 96

Slide 96

CONTINUOUS INTEGRATION @jbjon

Slide 97

Slide 97

CONTINUOUS INTEGRATION ▸ Early feedback about potentially breaking changes @jbjon

Slide 98

Slide 98

CONTINUOUS INTEGRATION ▸ Early feedback about potentially breaking changes ▸ Changes tested in isolation from production @jbjon

Slide 99

Slide 99

CONTINUOUS INTEGRATION ▸ Early feedback about potentially breaking changes ▸ Changes tested in isolation from production ▸ Can apply to infrastructure, server, and configuration changes @jbjon

Slide 100

Slide 100

CONTINUOUS INTEGRATION ▸ Early feedback about potentially breaking changes ▸ Changes tested in isolation from production ▸ Can apply to infrastructure, server, and configuration changes ▸ “Does this produce the instance I expect?” @jbjon

Slide 101

Slide 101

CONTINUOUS INTEGRATION ▸ Early feedback about potentially breaking changes ▸ Changes tested in isolation from production ▸ Can apply to infrastructure, server, and configuration changes ▸ “Does this produce the instance I expect?” ▸ “Does this instance have all the features I expect?” @jbjon

Slide 102

Slide 102

CONTINUOUS INTEGRATION ▸ Early feedback about potentially breaking changes ▸ Changes tested in isolation from production ▸ Can apply to infrastructure, server, and configuration changes ▸ “Does this produce the instance I expect?” ▸ “Does this instance have all the features I expect?” ▸ “Is this instance configured for its role correctly?” @jbjon

Slide 103

Slide 103

BUILD PIPELINES @jbjon

Slide 104

Slide 104

BUILD PIPELINES ▸ Avoid ‘automation fear’ @jbjon

Slide 105

Slide 105

BUILD PIPELINES ▸ Avoid ‘automation fear’ ▸ Build regularly as well as on changes @jbjon

Slide 106

Slide 106

BUILD PIPELINES ▸ Avoid ‘automation fear’ ▸ Build regularly as well as on changes ▸ Pipelines maintaining templates ensures up-to-date images @jbjon

Slide 107

Slide 107

BUILD PIPELINES ▸ Avoid ‘automation fear’ ▸ Build regularly as well as on changes ▸ Pipelines maintaining templates ensures up-to-date images ▸ Reduces manual knowledge fading @jbjon

Slide 108

Slide 108

BUILD PIPELINES ▸ Avoid ‘automation fear’ ▸ Build regularly as well as on changes ▸ Pipelines maintaining templates ensures up-to-date images ▸ Reduces manual knowledge fading ▸ Services used to build can be provisioned temporarily @jbjon

Slide 109

Slide 109

BUILD PIPELINES ▸ Avoid ‘automation fear’ ▸ Build regularly as well as on changes ▸ Pipelines maintaining templates ensures up-to-date images ▸ Reduces manual knowledge fading ▸ Services used to build can be provisioned temporarily ▸ Packer supports building machine images @jbjon

Slide 110

Slide 110

AUTOMATED TESTING @jbjon

Slide 111

Slide 111

AUTOMATED TESTING ▸ One of the best practices to borrow from Development @jbjon

Slide 112

Slide 112

AUTOMATED TESTING ▸ One of the best practices to borrow from Development ▸ Not relying on ‘Green builds’ @jbjon

Slide 113

Slide 113

AUTOMATED TESTING ▸ One of the best practices to borrow from Development ▸ Not relying on ‘Green builds’ ▸ Frameworks like ServerSpec (http://serverspec.org) @jbjon

Slide 114

Slide 114

AUTOMATED TESTING ▸ One of the best practices to borrow from Development ▸ Not relying on ‘Green builds’ ▸ Frameworks like ServerSpec (http://serverspec.org) @jbjon

Slide 115

Slide 115

CONTINUOUS DELIVERY @jbjon

Slide 116

Slide 116

CONTINUOUS DELIVERY ▸ Not ‘Continuous Deployment’ @jbjon

Slide 117

Slide 117

CONTINUOUS DELIVERY ▸ Not ‘Continuous Deployment’ ▸ Being able to update Test / Lab environments regularly @jbjon

Slide 118

Slide 118

CONTINUOUS DELIVERY ▸ Not ‘Continuous Deployment’ ▸ Being able to update Test / Lab environments regularly ▸ Risk increases with ‘Time Since Last Success’ @jbjon

Slide 119

Slide 119

CODE ANALYSIS @jbjon

Slide 120

Slide 120

CODE ANALYSIS ▸ Emerging area drawing from Dev practices @jbjon

Slide 121

Slide 121

CODE ANALYSIS ▸ Emerging area drawing from Dev practices ▸ Config management declarative languages have ‘lint’ tools @jbjon

Slide 122

Slide 122

CODE ANALYSIS ▸ Emerging area drawing from Dev practices ▸ Config management declarative languages have ‘lint’ tools @jbjon

Slide 123

Slide 123

Kief Morris @jbjon

Slide 124

Slide 124

“A NETFLIX TEAM KNEW THAT A PERCENTAGE OF AWS INSTANCES, WHEN PROVISIONED, WILL PERFORM MUCH WORSE THAN THE AVERAGE INSTANCE SO THEY WROTE THEIR PROVISIONING SCRIPTS TO IMMEDIATELY TEST THE PERFORMANCE OF EACH NEW INSTANCE. IF IT DOESN’T MEET THEIR STANDARDS, THE SCRIPT DESTROYS THE INSTANCE AND TRIES AGAIN WITH A NEW INSTANCE.” Kief Morris @jbjon

Slide 125

Slide 125

HIGH PERFORMING ORGANISATIONS @jbjon

Slide 126

Slide 126

HIGH PERFORMING ORGANISATIONS ▸ deploy 200x more frequently @jbjon

Slide 127

Slide 127

HIGH PERFORMING ORGANISATIONS ▸ deploy 200x more frequently ▸ with 2,555x faster lead times @jbjon

Slide 128

Slide 128

HIGH PERFORMING ORGANISATIONS ▸ deploy 200x more frequently ▸ with 2,555x faster lead times ▸ recover 24x faster @jbjon

Slide 129

Slide 129

HIGH PERFORMING ORGANISATIONS ▸ deploy 200x more frequently ▸ with 2,555x faster lead times ▸ recover 24x faster ▸ and have 3x lower change failure rates @jbjon

Slide 130

Slide 130

HIGH PERFORMING ORGANISATIONS ▸ deploy 200x more frequently ▸ with 2,555x faster lead times ▸ recover 24x faster ▸ and have 3x lower change failure rates ▸ have better employee loyalty @jbjon

Slide 131

Slide 131

HIGH PERFORMING ORGANISATIONS ▸ deploy 200x more frequently ▸ with 2,555x faster lead times ▸ recover 24x faster ▸ and have 3x lower change failure rates ▸ have better employee loyalty ▸ spend 22% less time on unplanned work and rework @jbjon

Slide 132

Slide 132

5 STAGES OF DEVOPS EVOLUTION @jbjon

Slide 133

Slide 133

5 STAGES OF DEVOPS EVOLUTION @jbjon

Slide 134

Slide 134

5 STAGES OF DEVOPS EVOLUTION @jbjon

Slide 135

Slide 135

5 STAGES OF DEVOPS EVOLUTION @jbjon

Slide 136

Slide 136

5 STAGES OF DEVOPS EVOLUTION @jbjon

Slide 137

Slide 137

5 STAGES OF DEVOPS EVOLUTION @jbjon

Slide 138

Slide 138

WAYS TO START INTRODUCING THIS @jbjon

Slide 139

Slide 139

WAYS TO START INTRODUCING THIS ▸ Start small @jbjon

Slide 140

Slide 140

WAYS TO START INTRODUCING THIS ▸ Start small ▸ Script everything @jbjon

Slide 141

Slide 141

WAYS TO START INTRODUCING THIS ▸ Start small ▸ Script everything ▸ Automate the process @jbjon

Slide 142

Slide 142

WAYS TO START INTRODUCING THIS ▸ Start small ▸ Script everything ▸ Automate the process ▸ Run it regularly @jbjon

Slide 143

Slide 143

WAYS TO START INTRODUCING THIS ▸ Start small ▸ Script everything ▸ Automate the process ▸ Run it regularly ▸ Test the changes in a safe environment @jbjon

Slide 144

Slide 144

WAYS TO START INTRODUCING THIS ▸ Start small ▸ Script everything ▸ Automate the process ▸ Run it regularly ▸ Test the changes in a safe environment ▸ Monitor all the things @jbjon

Slide 145

Slide 145

Slide 146

Slide 146

AGILE ENGINEERING WORKS WHEN WE SHARE WHAT WORKS, INTRODUCE CONSISTENCY AND COLLABORATE

Slide 147

Slide 147

Slide 148

Slide 148

QUESTIONS?

Slide 149

Slide 149

ABOUT ME ▸ Jonathan Relf ▸ Solutions Architect @ Commify ▸ about.me/jbjon @jbjon