Devel-Ops: Bringing Development practices to Operations tasks

Slide 1

24th September 2019 Jonathan Relf DEVEL-OPS

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

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

BRINGING DEVELOPMENT PRACTICES TO OPERATIONS TASKS DEVEL-OPS

Slide 5

Slide 6

THE IRON AGE OF I.T.

Slide 7

THE CLOUD AGE OF I.T.

Slide 8

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

Slide 9

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

Slide 10

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

Slide 11

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

Slide 12

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

Slide 13

“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 14

DEVOPS SHOULD NOT BE VS Devs Ops

Slide 15

DEVOPS SHOULD BE MORE:

Slide 16

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 17

@jbjon

Slide 18

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

Slide 19

“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 20

“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 21

2017

Slide 22

2018

Slide 23

Slide 24

Slide 25

Slide 26

Slide 27

Slide 28

Slide 29

Slide 30

Slide 31

Slide 32

Slide 33

https://landscape.cncf.io/

Slide 34

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

Slide 35

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

Slide 36

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

Slide 37

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

Slide 38

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

Slide 39

WHY BOTHER DEFINING YOUR OWN INFRASTRUCTURE IN CODE? @jbjon

Slide 40

REGULATORY REQUIREMENTS

Slide 41

3RD PARTY SOLUTION UNCERTAINTY

Slide 42

HARDEN APPLICATION HOSTING

Slide 43

AVOID VENDOR LOCK-IN

Slide 44

Slide 45

THE FOUR STAGES OF INFRASTRUCTURE PROVISIONING CONFIGURING MAINTENANCE TERMINATION @jbjon

Slide 46

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

Slide 47

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

Slide 48

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 49

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 50

Slide 51

4 GOALS OF INFRASTRUCTURE AS CODE @jbjon

Slide 52

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

Slide 53

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

Slide 54

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

Slide 55

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 56

Slide 57

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 58

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

Slide 59

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 60

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 61

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

Slide 62

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

Slide 63

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

Slide 64

“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 65

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