Devel-ops: Bringing development practices to operations tasks

A presentation at The IT Crewe October 2018 in October 2018 in Crewe, UK by Jonathan Relf

Slide 1

Slide 1

9th October 2018 Jonathan Relf DEVEL-OPS

Slide 2

Slide 2

BRINGING DEVELOPMENT PRACTICES TO OPERATIONS TASKS DEVEL-OPS

Slide 3

Slide 3

THIS TALK IS NOT: Devs Vs Ops

Slide 4

Slide 4

THIS TALK IS MORE: embracing the chance to work together more. To be collaborative.

Slide 5

Slide 5

Big Sales Pitch

Slide 6

Slide 6

DEVEL-OPS “THE DEFINITION OF INSANITY IS REPEATING THE SAME MISTAKES OVER AND OVER AGAIN AND EXPECTING DIFFERENT RESULTS” Unknown

Slide 7

Slide 7

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

Slide 8

Slide 8

A short journey through I.T.

Slide 9

Slide 9

THE IRON AGE OF I.T.

Slide 10

Slide 10

THE CLOUD AGE OF I.T.

Slide 11

Slide 11

DEVEL-OPS “UNRELIABLE SOFTWARE DEPENDING ON RELIABLE HARDWARE TO RELIABLE SOFTWARE RUNNING ON UNRELIABLE HARDWARE” Infrastructure As Code

Slide 12

Slide 12

The Cloud Native Landscape - 2017

2017

Slide 13

Slide 13

The Cloud Native Landscape - 2018

Slide 14

Slide 14

Cloud providers

Slide 15

Slide 15

Continuous Integration & Delivery

Slide 16

Slide 16

Observability and Analysis

Slide 17

Slide 17

Slide 18

Slide 18

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

Slide 19

Slide 19

WHY BOTHER DEFINING YOUR OWN INFRASTRUCTURE IN CODE?

May have regulatory or data sovereignty limitations ▸ Unsure of what you are getting using 3rd party solutions ▸ Allowing you to ‘harden’ application hosting ▸ Reducing the risk of ‘vendor lock’

Slide 20

Slide 20

MAINTAINING SERVERS OVER TIME

OWN SOFTWARE CONFIGURATION UPDATES 3RD PARTY SOFTWARE CONFIGURATION UPDATES OPERATING SYSTEM FEATURES CONFIGURATION HYPERVISOR CONFIGURATION UPDATES PHYSICAL SERVER CONFIGURATION UPDATES UPDATES

Slide 21

Slide 21

THE FOUR STAGES OF INFRASTRUCTURE

PROVISIONING CONFIGURING MAINTENANCE TERMINATION

Slide 22

Slide 22

PROVISIONING

▸ Since virtualisation, one of the easiest of the phases ▸ Traditionally based off ISO images ▸ Out of date, unpatched images

Slide 23

Slide 23

CONFIGURATION

▸ Can be where most configuration drift is added if not done through automation ▸ It may involve ‘tinkering’ to get a server working ▸ Can end up with ‘Snowflake servers’ ▸ Configuration Management software like Puppet & Chef

Slide 24

Slide 24

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

Slide 25

Slide 25

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

Slide 26

Slide 26

Taking the leap

Slide 27

Slide 27

GOALS OF INFRASTRUCTURE AS CODE - MORRIS

▸ IT infrastructure supports & enables change ▸ Changes to the system are routine, without drama or stress ▸ IT staff spend their time on valuable things.. not repetitive tasks ▸ Users are able to define, provision, and manage the resources they need, without needing IT staff to do it for them

Slide 28

Slide 28

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’

Slide 29

Slide 29

Learning from Development Practices

Slide 30

Slide 30

DEVELOPMENT PRACTICES

▸ Version Control ▸ Continuous Integration ▸ Build Pipelines ▸ Automated Testing ▸ Continuous Delivery ▸ Code Analysis

Slide 31

Slide 31

VERSION CONTROL

▸ Natural part of development workflow ▸ branching, rollbacks, ownership ▸ Single point of truth ▸ Living documentation

Slide 32

Slide 32

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

Slide 33

Slide 33

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

Slide 34

Slide 34

AUTOMATED TESTING

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

Slide 35

Slide 35

CONTINUOUS DELIVERY

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

Slide 36

Slide 36

CODE ANALYSIS

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

Slide 37

Slide 37

Netflix Quote

“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

Slide 38

Slide 38

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

Slide 39

Slide 39

What have we learned?

Slide 40

Slide 40

QUESTIONS?

Slide 41

Slide 41

ABOUT ME

▸ Jonathan Relf ▸ Solutions Architect @ Commify ▸ https://about.me/jbjon @jbjon