what is devops? demystifying devops€¦ · the 3 ways of devops? devops working patterns are all...

0 Copyright 2018 FUJITSU@SteNadinFJ

What is DevOps?

Demystifying DevOps

Ste Nadin@SteNadinFJ


Disclaimer

This might not be the presentation you are expecting….

It will not talk about tools and platforms……(much)

Its not even overly techie.

There is a lot of stuff I will not talk about.


Why Listen to Ste

Chief Architect Fujitsu Business and Application Services.

• Owning DevOps strategy

Fujitsu Distinguished Engineer

President of SEMAT.inc

Open Group Board Member

Member of the BCS.


State of the Audience

This book will not

change your life

Who has read?What’s your understanding of

DevOps?

(a) Never heard of it.

(b) Aware but no more.

(c) Taking first steps to use.

(d) Some usage.

(e) DevOps Ninja.


State of the Audience

What is your role?DEV

Ops Sec


Issues in a non DevOps World


Typical problems today

Desires Change Wants Stability

Releases



Security Says NO



Dev Test Prod



Hero Culture is a way of life!



Release Business Need

Note: Amazon make a release every 11.7 seconds


Changing World

Everything is becoming software


So What is DevOps


DevOps – What is it

Many different views

Depends on the context most people

are looking at it from.

Its not just tools!!!

Its not just for techies!!!


DevOps – Where has it come from

Most of DevOps is not new.

Some of the working practices have been

around along time

Its just about putting some of this together.


DevOps Concepts: “Doers” and “Enablers”

Its people who solve

problems!!

Its people who

think!!

Its people who

innovate!!It’s people who see

opportunities!!

Tools and processes enable and

enhance

... and are important!

People

Technology Process

DevOps

It is not only Tools; but Culture with

Automation enabled by Tooling….


The 3 Ways of DevOps?

DevOps working patterns are all derived from the 3 ways

Dev OpsDev Ops

Dev Ops

The first way:

Systems thinking

The second way:

Amplify feedback loops

The third way:

Culture of continual

experimentation and learning

• Performance of the entire

system vs. single silo

• Focus on all business value

streams

• Never pass a known defect

downstream

• Create right to left feedback

loops

• Shorten and amplify

feedback loops

• Foster continual

experimentation, taking risk

& learning from failure

• Allocating time for the

improvements of daily work


DevOps Principles

PRINCIPLE 2:

Create with End in Mind

PRINCIPLE 5:

Continuous Improvement

PRINCIPLE 1:

Customer-centric action

PRINCIPLE 4:

Cross-Functional

Autonomous Teams

PRINCIPLE 3:

End-to-End Responsibility

PRINCIPLE 6:

Automate Everything you

can

Source: https://www.devopsagileskills.org/dasa-devops-principles/


SIMULATION


Workstation 1 Workstation 2 Workstation 3


Workstation 1


Workstation 2

+


Workstation 3


First way and Value Streams

Dev Ops

The first way:

Systems thinking

• Performance of the entire

system vs. single silo

• Focus on all business value

streams

• Never pass a known defect

downstream

1. Attack the wait time

2. Optimise the work activity

3. Never pass bugs on


Value Streams

Simple way of showing the end to end stream of an activity

Example: Ste going to London Office

Drive from Home

to StationTrain into London Walk to LON22

Tube to Baker

Street

20 mins 120 mins 8 mins 7 mins

Total Time: 155 mins

Wait 15 Wait 5 Wait 1

Total Time: 176 mins


Utilisation

Empty pint pot

0% Utilised

Short measured beer

80% Utilised

Full pint

100% Utilised


Flow

So the road is 100% utilised so therefore its working perfectly…..

That’s because its about flow not utilisation


How do you work best?

Empty vassal to be utilised? Road where work flows?

Or


Wait time control

As utilisation

increases the ability to

respond to change

and priority

decreases.


Work Stations Optimised

Adhoc Guidelines Documented AutomatedIdentified

Ways of working need to be optimised per “Work Activity” to increase quality and consistency


Work Stations Optimised

Activity 2 Activity 3Activity 1

Look to bring standard blocks together to make more efficient

Combined Activity


Document Everything

DevOps does not mean you don’t document.

It fact you do more documentation…!!!

But

Documents don’t have to mean word. It can be just Wiki

entries.

Tools like Confluence are great for this.


Business Driven Development

Business Outcomes need to be

focused on at all times.

The move up the value chain from

traditional requirement gathering and

testing removed hard testing to

Test Driven Development (TDD)

ensuring that all dev is defined by

ensuring the tests are passed

Business Driven Development (BDD)

has constant checkpoints on

business value deliver.


Automate the release chain

Aim is to automate as much as possible. This should be right across the release chain

Removal of manual steps increases accuracy, consistency and time to release.

Check

in

Auto

unit

test

You can put

in a safety

stop


Third way improvements

1. Team Empowerment

2. Retrospectives

Dev Ops

The third way:

Culture of continual

experimentation and learning

• Foster continual

experimentation, taking risk

& learning from failure

• Allocating time for the

improvements of daily work


Team is responsible for its own way of working

Toyota Kata and Agile both foster the empowerment of the team

Did everything work

successfully last time

Why did it not work?

What can be changed to

make it better

Make change into standard

way of working

39 Copyright 2018 FUJITSU

Team is responsible for its own way of working

Each Iteration is time boxedUsually 2 – 4 Weeks

Requirement

Slice

Use Cases

Requirement

ElaborationDaily Stand-ups

Stakeholder

Demo

Requirements

Backlog

Requirement

Change

Retrospective

Way of

Working

Change?

Each iteration follows a set of key tasks to ensure that priorities are delivered, evaluated and working method tuned


Second way

1. Create a looping process

2. Shorten and Amplify Feedback

3. Remove the line from Dev, Ops and Sec

Dev Ops

The second way:

Amplify feedback loops

• Create right to left feedback

loops

• Shorten and amplify

feedback loops


Teams must be multi-skilled

Team members still have specialities but all work together supporting

each other across the whole life cycle.


Teams must be empowered

• The team must be empowered to make its own decisions

• If they identify something that can be improved this can make this

change

• They are not managed but enabled by Servant Leadership

Support

ManageX


Create Consistency in Environments

Configuration Library

Configuration Management needs to own “servers” not just “code”

Dev 1 Dev 2 Test Pre-Prod Production

Build Engine

All server instances

start from a new build


Many activities…

Plan Production metrics (including: SLAs/service-level

objectives [SLOs]) and feedback

Requirements definition (use case, prototyping)

Business metrics (e.g., shopping cart performance,

resolution times, customer satisfaction)

Update release metrics

New feature/function priorities and fixes

Release plan (timing, business case)

Security policy, adherence and requirements

Create

Design (software, configuration)

Code, code merge, code quality and

performance

Build and build performance

Functional test

Release candidate

Verify

Acceptance test

Regression test

Static analysis (quality and compliance)

Security analysis (vulnerability)

Performance test

Defect status

Configuration test

Release test

PreProd

Autorelease (e.g., application

release is automatically pushed)

Triggered release (e.g., upon a

"ready state" being met)

Release staging/holding

Release approval/preapproval

Release package configuration

(if required)

Release

Scheduled/timed release

Release coordination

Deploy application

Deployment status

Change controls

Fallback/recovery

Configure

Infrastructure provisioning and

configuration (including storage, database

and network)

Application provisioning and configuration

Monitor

Performance and availability of the IT

infrastructure, network and application

End-user response and experience

Production load metrics gathering

And back to Plan……….


Even more possible tools…

(Source:

Gartner)

And this is just a subset…


DevOps Challenges

1. Organisational Structure Teams need to be multi-skilled and not cross charged across capability units / business lines.

2. Who does the support? A DevOps team own the tools they use as well as the whole end to end process

You don’t have separate support teams

3. Why can’t we do DevOps to a customer? You can only do DevOps with a customer not to them

4. Commercial Constructs But this means we don’t get to charge the customer for a project and for a support contract!!


Takeaways

1. Look to optimise the whole end to end process not silo’s of work.

2. Monitor and Attack areas of delay “wait time”.

3. Look where processes can be documented, repeated and automated.

4. Focus on the end business benefits not pockets of work

5. Tools are there to enable. Without culture change they will not deliver DevOps alone.

6. Don’t drink and DevOps