DevOps
An Introduction

Robert Sell
IT Operations Manager
AeroInfo – Boeing Canada
@robertesell
https://ca.linkedin.com/in/robertsell

Agenda
Definition
Comparison
Popularity
History
Difference
Next Steps
The Secret
References

Definition

DevOps Defined
A software development method that emphasizes
communication, collaboration, integration,
automation and cooperation between developers and
operations.
This method acknowledges the interdependence of
groups and aims to rapidly produce software products
through improved operational performance.

Goals of DevOps
The goals of a DevOps approach span the entire
delivery pipeline and include:
• Improved deployment frequency
• Lower failure rate of new releases
• Shorten lead time between fixes
• Maximize predictability, efficiency, security
(rugged) and maintainability

Other Definitions
Many DevOps leaders refer to DevOps as a
“revolution or movement.”
“DevOps is a culture or professional movement.”
- Adam Jacob, CTO at Chef
“DevOps is more like a philosophical movement.”
- Gene Kim, Founder of TripWire, CTO, Author

CALMS Model
Culture Changing the way we think nd behave in the
organization. Becoming one. Grassroots.
Cooperation.
Automation Configuration items. Infrastructure as Code.
Lean A focus on value and customer. Reducing
time spent on non-value activities.
Metrics Measure everything all the time. Show
improvement.
Sharing Open sharing. Collaboration. Transparency.

My Definition
I like the definition in the DevOps Cookbook:
We refer to “DevOps” as the outcome of applying
Lean principles to the IT value stream.
Understand the goal (customer), common and shared
KPIs to support that goal, mapped work steams then
improve.
Allows repeatability, consistency and continual
improvement.

Definition
What DevOps is NOT:
DevOps is not a product. You can not buy DevOps.
DevOps is not a title or department.
DevOps isn’t compliance. There is no DevOps
certification.
DevOps doesn’t just mean you mix Dev and Ops

Side Effects
Now we know what it is,
what its goals are and
what it is not.
It’s side effects may include:
• Higher employee engagement
• Improved productivity
• Competitive advantage (includes hiring)
• Happier customers

Comparison

Stages
Traditional Software Delivery Life Cycle (SDLC) treat all
stages equally and often spends too much time on
risk mitigating activities that don’t create value.
DevOps focuses on software creation and customer
feedback while continually seeking to reduce
investment in other stages.

Release Methods
Traditional release methods are huge, costly,
disruptive, complicated, time consuming, stressful,
manual, rare and often don’t work well.
DevOps release methods focus on small, cheap, easy,
automated, instant, frequent and perfect.

Teams
Traditional skill based silos benefit from economies of
scale but don’t transfer work. “Thrown over the
fence.”
DevOps is a dedicated cross functional team focused
on one service or application. No handoffs and
misunderstandings. Responsibility and ownership for
the larger picture.

Scheduling
Traditional software development needs to schedule
resources across multiple projects. Ops and Dev
hardly communicate let alone schedule. Last minute
“urgent” requests are the norm.
DevOps allows collaboration and local team
scheduling. Small batches and automated process
make this much easier.

Experience
Traditional software releases are terrible experiences
full of issues, escalation and fire fighting. War rooms,
pizza and all night fiascos.
DevOps turns software releases into non-events. Code
is through daily (or more) code integration,
automated testing, built in security, and environment
synchronization.

Failure
Traditionally there is a huge focus on risk aversion. To
fail is a bad thing and often results in blame. The fear
of failure and blame cause delays and cost.
DevOps are okay with failure. In fact, “fail early” is
one of the mandates. Instead of investing in failure
elimination, they choose when and how they will fail.
Small, early and fast failure allow fast recovery and
future prevention. Ie Chaos Monkey

KPIs
Traditional measurements have been on uptime, cost
and capacity. Unfortunately, organizations often
ignore the fact that salary is a top cost and employee
time is often spent on non-value work.
DevOps looks at the element of time in the work flow
as an additional metric. This forces us to examine the
flow of work from start to finish. Decrease areas of
waste, increase productive time and focus on value
areas.

Responsibilities
Traditionally we were all responsible for completing
our incoming tasks so we could hand off to the next
team.
DevOps changes the “I did my task” concept to “it is
ready to deploy” with the introduction of cross
functional teams.

Automation
Traditionally there has been a focus on manual task
specialization. Unfortunately this often results in
errors, bottlenecks and poor documentation.
DevOps automates as much as possible. Time doing
routinized behaviors is freed up for creative and
innovative tasks. Instead of outdated documentation
we do commenting.
We never follow documentation to create an
environment!

Comparison
DevOps Culture Matrix
Engaged Employees

Popularity

Google Trends
Started in 2010 and took off from there.
61 points in Jan 2015 and 100 in Sept 2015.

Compared to…

IoT not as Popular
“Internet of Things” isn’t even as popular as DevOps.
90 in Jan 2015 and 100 in Sept 2015

Not Just Unicorns
Unicorns
Non-Unicorns
http://www.slideshare.net/fullscreen/danapylayeva/xp2015-devops-and-continuous-value-delivery-with-chocolate-and-lego-half-day-workshop/20
Gene Kim

Forecast
“DevOps will shift from being a niche approach to application development and deployment
and move into the mainstream over the next 12 months or
so.”
– Gartner
“So appealing will this grassroots philosophy prove that it will be taken up by a quarter
of Global 2000 organizations”
– Computer Weekly

Why so Popular?
Gene Kim

Stats
For people who like stats:
• Traditional Ops are 41% more time-consuming overall
• Traditional Ops spends 21% more time putting out fires
• DevOps spends 33% more time on infrastructure improvements
• DevOps spends 60% less time handling support cases
After DevOps is implemented:
• 63% experience improvement in quality of software deployments
• 63% release new software more frequently
• 55% notice improved cooperation and collaboration
• 38% report a higher quality of code production
https://www.scriptrock.com/blog/devops-success-stats

History

Ops
IT Operations grew up with BOFH (and enjoyed it)
Our KPIs are for stability/uptime. Any change is a risk.
Our role is to protect developers from themselves.
Viewed by Dev as the Evil Empire

Dev
Developers are creative, happy and care free.
If an environment breaks they simply put in a ticket.
Can’t understand why Ops makes such a big deal.

Ops vs Dev
Poor release management, out of sync environments,
different KPIs and cumbersome processes have
caused many years of conflict.

Structure

Traditional
Let’s start with traditional Operations & Development
Chief Information Officer
PMO/BAs Dev DBAs Test InfoSec Release Infra Support
Head of Development Head of Operations

Grassroots
DevOps begins with anyone. Grassroots.
Chief Information Officer
Head of Development Head of Operations
PMO/BAs Dev DBAs Test InfoSec Release Infra Support
Want to
cooperate?
Oh ya!
Coffee?

Product Focus
Sometimes Product Leads are created. Challenging.
Chief Information Officer
Head of Development Head of Operations
Product A Product B Product C Product D InfoSec Release Infra Support

Embedded Ops
Ops embedded into Dev teams for DevOps.
Chief Information Officer
Head of Development Head of Operations
Product A Product B Product C Product D InfoSec Release Infra Support
Operations doing DevOps
Want some
DevOps?

Dedicated DevOps
Sometimes dedicated DevOps team are created.
Chief Information Officer
Head of Development Head of Operations
Product A Product B Product C Product D InfoSec Release Infra Support
DevOps

Total DevOps
One possible DevOps organizational structure:
Chief Information Officer
Management
Product A Product B Product C Product D Product E Product F Product G Product H
I’m focused
on Product
I’m practicing
“Servant
Management”
I’m building
leadership for
scalability

Next Steps

Cross Functional
Create cross functional teams with representatives
from each of the functional areas of the software
delivery process.
Map out the flow of work and look for efficiency
opportunities. Reduce time for each step (especially
non-value steps).
Share the responsibility for building, deploying and
maintaining product. Mix Build and Run teams.

Communications
Develop effective communications that promotes
collaboration.
Remove blame from Post Mortems and Project
Reviews. Fail fast and expect it.
Stop using email in attempt at collaboration.
Treat failure as opportunities. Failure creators own,
publish and teach solutions. Continual improvement.

Share Risk
Collaboration allows error checking and guidance.
Same idea as ITIL CAB.
Quality, availability, reliability, scalability and security
is everyone’s responsibility. Traditional InfoSec does
not work because it is after the fact and left to IT to
enforce. Must be baked in.
Devs responsible for Prod. No “throw over the wall.”

Align Goals
Silos/Empires only exist when leaders are allowed to
have different goals.
Share goals and roll up.
Cross functional teams ensure shared goals.
Include Ops in planning throughout the software dev
lifecycle.

Innovation
We must demand innovation otherwise it doesn’t
occur. Continual improvement now applies to the
individual. Training must now occur on a daily basis.
Time must be allocated to on the job training and idea
exploration. KPIs to measure it.
Internal hack days, lunch & learns, mini conferences,
awards for innovation, collaboration events, etc.

The Secret

The Revolution
I am bias. I see DevOps as a revolution.
Traditional organizations are very inefficient with
layers of bureaucracy, silos, empires, red tape, politics
and other non-value time wasters.
DevOps forces us to not only fix Dev vs Ops but also
fixes the PMO, Quality, Security and others.

Engagement
DevOps is employee engagement and is therefore
scalable. Autonomous streams.
DevOps corrects the culture. Share. Trust. Learn. Own.
DevOps will revolutionize Operations (not just Dev).
Infrastructure as Code is our next evolutionary step.
Combined with monitoring and automation, it is scary
cool.

Chang(ed)
The world has changed. Traditional disciplines are
dead, some people just don’t know that yet.

References

Sources
YouTube (full of good videos)
Start here:
• Docker and DevOps by Gene Kim
• DevOps Demystified by Ben Rockwood
SlideShare
http://www.slideshare.net
Loads of good presentations

Training
In the name of the DevOps spirit, IT is sharing all our training:
S:AeroInfoTraining
Training materials include: GIT, Docker, etc.
Join my local DevOps MeetUp:
http://www.meetup.com/DevOps-Vancouver-BC-Canada

Twitter
John Allspaw -@allspaw
Jesse Robbins - @jesserobbines
Gene Kim - @realgenekim
Patrick DuBuis - @patrickdubois
Andrew Schafer - @littleidea
Jez Humble - @jezhumble
John Willis - @botchagalupe
Damon Edwards - @damonedwards

BooksThe Phoenix Project:
This book by Gene Kim is used by everyone as the modern version of The
Goal and is a good starting point for understanding DevOps and the
problems it solves. If you don’t have it then talk to your manager and get
the audio or written today via Safari, iTunes or Amazon

BooksContinuous Delivery:
This book by Jez Humble is used by Boeing and is the default starting
point for understanding Continuous Delivery. If you don’t have it then
talk to your manager and get the audio or written today via Safari, iTunes
or Amazon

BooksThe Goal:
This book is used to better understand Operations Management and
kaizen. It is normally part of an MBA program. If you don’t have it then
talk to your manager and get the audio or written today via Safari, iTunes
or Amazon

ReferencesReinventing Organizations:
The way we manage organizations seems increasingly out of date. This
book was created after 3 years of research and is a key book in DevOps
when looking at organizational change.