What is DevOps? Demystifying DevOps€¦ · The 3 Ways of DevOps? DevOps working patterns are all derived from the 3 ways Dev Ops Dev Ops Dev Ops The first way: Systems thinking The
Post on 28-May-2020
33 Views
Preview:
Transcript
0 Copyright 2018 FUJITSU@SteNadinFJ
What is DevOps?
Demystifying DevOps
Ste Nadin@SteNadinFJ
1 Copyright 2018 FUJITSU@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.
2 Copyright 2018 FUJITSU@SteNadinFJ
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.
3 Copyright 2018 FUJITSU@SteNadinFJ
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.
4 Copyright 2018 FUJITSU@SteNadinFJ
State of the Audience
What is your role?DEV
Ops Sec
5 Copyright 2018 FUJITSU@SteNadinFJ
6 Copyright 2018 FUJITSU@SteNadinFJ
7 Copyright 2018 FUJITSU@SteNadinFJ
Issues in a non DevOps World
8 Copyright 2018 FUJITSU@SteNadinFJ
9 Copyright 2018 FUJITSU@SteNadinFJ
Typical problems today
Desires Change Wants Stability
Releases
10 Copyright 2018 FUJITSU@SteNadinFJ
Typical problems today
Security Says NO
11 Copyright 2018 FUJITSU@SteNadinFJ
Typical problems today
Dev Test Prod
12 Copyright 2018 FUJITSU@SteNadinFJ
Typical problems today
Hero Culture is a way of life!
13 Copyright 2018 FUJITSU@SteNadinFJ
Typical problems today
Release Business Need
Note: Amazon make a release every 11.7 seconds
14 Copyright 2018 FUJITSU@SteNadinFJ
Changing World
Everything is becoming software
15 Copyright 2018 FUJITSU@SteNadinFJ
So What is DevOps
16 Copyright 2018 FUJITSU@SteNadinFJ
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!!!
17 Copyright 2018 FUJITSU@SteNadinFJ
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.
18 Copyright 2018 FUJITSU@SteNadinFJ
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….
19 Copyright 2018 FUJITSU@SteNadinFJ
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
20 Copyright 2018 FUJITSU@SteNadinFJ
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/
21 Copyright 2018 FUJITSU@SteNadinFJ
SIMULATION
22 Copyright 2018 FUJITSU@SteNadinFJ
Workstation 1 Workstation 2 Workstation 3
23 Copyright 2018 FUJITSU@SteNadinFJ
Workstation 1
24 Copyright 2018 FUJITSU@SteNadinFJ
Workstation 2
+
25 Copyright 2018 FUJITSU@SteNadinFJ
Workstation 3
26 Copyright 2018 FUJITSU@SteNadinFJ
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
27 Copyright 2018 FUJITSU@SteNadinFJ
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
28 Copyright 2018 FUJITSU@SteNadinFJ
Utilisation
Empty pint pot
0% Utilised
Short measured beer
80% Utilised
Full pint
100% Utilised
29 Copyright 2018 FUJITSU@SteNadinFJ
Flow
So the road is 100% utilised so therefore its working perfectly…..
That’s because its about flow not utilisation
30 Copyright 2018 FUJITSU@SteNadinFJ
How do you work best?
Empty vassal to be utilised? Road where work flows?
Or
31 Copyright 2018 FUJITSU@SteNadinFJ
Wait time control
As utilisation
increases the ability to
respond to change
and priority
decreases.
32 Copyright 2018 FUJITSU@SteNadinFJ
Work Stations Optimised
Adhoc Guidelines Documented AutomatedIdentified
Ways of working need to be optimised per “Work Activity” to increase quality and consistency
33 Copyright 2018 FUJITSU@SteNadinFJ
Work Stations Optimised
Activity 2 Activity 3Activity 1
Look to bring standard blocks together to make more efficient
Combined Activity
34 Copyright 2018 FUJITSU@SteNadinFJ
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.
35 Copyright 2018 FUJITSU@SteNadinFJ
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.
36 Copyright 2018 FUJITSU@SteNadinFJ
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
37 Copyright 2018 FUJITSU@SteNadinFJ
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
38 Copyright 2018 FUJITSU@SteNadinFJ
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
40 Copyright 2018 FUJITSU@SteNadinFJ
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
41 Copyright 2018 FUJITSU@SteNadinFJ
Teams must be multi-skilled
Team members still have specialities but all work together supporting
each other across the whole life cycle.
42 Copyright 2018 FUJITSU@SteNadinFJ
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
43 Copyright 2018 FUJITSU@SteNadinFJ
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
44 Copyright 2018 FUJITSU@SteNadinFJ
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……….
45 Copyright 2018 FUJITSU@SteNadinFJ
Even more possible tools…
(Source:
Gartner)
And this is just a subset…
46 Copyright 2018 FUJITSU@SteNadinFJ
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!!
47 Copyright 2018 FUJITSU@SteNadinFJ
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
48 Copyright 2018 FUJITSU@SteNadinFJ
top related