ted@tedneward.com | Blog: http://blogs.tedneward.com | Twitter: tedneward | Github: tedneward | LinkedIn: tedneward
What are we here to do?
understand "DevOps"
a little history
a few core concepts
demythologize the hype
give you some guidance
In the beginning....
God (in the form of men like Turing and women like Hopper) created astonishingly huge machines that filled rooms. They required months to set up and configure, days to program, and hours to execute even the simplest of calculations. They helped win a war and put a man on the moon, and soon businesses "had to have one".
As business got into the IT game...
the calculations they could provide were pretty general
but could be used to store data and provide insight
the machines were a huge expense
both in terms of capital (CapEx) and operation (OpEx)
very specialized training was necessary to use them effectively
and these people were very rare
Departments were formed around the care of these machines
the original folks in charge were called "operators"
they had very specific skills
they had particular quirks
some of them even got a little "uppity"
a whole subculture emerged
but they were a necessary evil
Enter the microcomputer
also known as the "IBM PC"
suddenly every employee could have a computer on their desktop
each user could have their own processing
each user could have their own storage
each user could even have their own programs to run
PCs required care, but with lower costs
outages were individual, not company-wide
Enter the development department
as micros grew more prominent the need for custom software grew
off-the-shelf software was useful, but...
developers had different skills than operators/sysadmins
equally valuable, equally squirrelly
so departments began to separate the two groups
Enter the network
we discovered how to connect them to one another
eventually TCP/IP emerged as the winning standard
and we needed programs to run in a central location
in order to help these groups connect more effectively
that meant a new programming style
new development skills
new operations skills
... and introduced new problems
server goes down, and now everybody is on hold
deploying the programs simultaneously is... tricky
keeping everybody organized worldwide even trickier
Enter the server room
"let's put all the servers into a single room"
"let's get the Ops guys to take care of them"
because how different could it be from a mainframe?
Enter deployment scripts
custom bespoke software required precise installation
Dev guys knew how to do it
but weren't allowed in the server room
Ops guys were allowed into the server room
but didn't know how to do it
Solution: We do these as formal ceremonies
...and we do them as rarely as possible
Problem: it's a major cat-fight every time
and the two groups snarl and hiss the whole time
Enter the Web
the Web permits companies to project their internal/enterprise systems out to their customers
this means user usage is measured in thousands or ten-thousands or more
instead of dozens or hundreds
this also means server counts go up
way, way up
but the complexity of server management is not linear
it's exponential
This is the state of most IT departments today
huge projects with "Big Bang" rollouts
massive integration issues
astonishing QA efforts
stupendous losses
bug fixes
installation failures
missed opportunities
So.... what now?
What is "DevOps"?
in one sense, the union of "Development" and "Operations"
fundamentally, a change in how IT projects are
developed
deployed
administered
practically, nothing less than an IT culture change
which should be simple, right?
The key concepts to any DevOps effort
it's an effort
it's never going to be "done"
it's a culture
it's not just a matter of using some tools
it's a process
you can't just "sprinkle DevOps" somewhere
The Three Ways of DevOps
Flow
Feedback
Kai-zen
continuous learning, expirimentation and enhancement
Flow: making the process faster
the core concept in Lean thinking is the value stream
the sequence of activities an organization undertakes to deliver upon a customer request
the sequence of activities required to design, produce and deliver a good or service to a customer, including the dual flows of information and material
flow is in software as well
the process required to convert a business hypothesis into a technology-enabled service that delivers value to the customer
goal: create fast flow
part of that means deployments without chaos or outages
Flow: making the process faster
make work visible
reduce our batch sizes and intervals of work
build in quality by preventing defects from being passed downstream
constantly optimize for global goals
these practices include (but are not limited to):
continuous build, integration, test, deployment processes
creating environments on demand
limiting work-in-progress
building systems and orgs that are safe to change
Feedback: creating effective production telemetry
information flow coming from "the other direction"
must be amplified to
prevent problems from happening again
enable faster detection and recovery
seeing problems as they occur enables us to shorten and amplify feedback loops
Kai-zen: embracing constant improvement
nobody knows how to do this stuff perfectly
so there's no call to stop learning ways to improve
create a high-trust culture that supports dynamic, disciplined, scientific approaches
to experimentation and risk-taking
facilitating the creation of organizational learning
embracing failure and growth mindset
Myth: "DevOps is only for startups"
DevOps is a solution for any company that has:
highly dangerous code releases that tend towards catastrophic failure
inability to release features fast enough
compliance concerns
inability to scale
high levels of distrust between Development and Operations
... then you should be looking to DevOps
Myth: "DevOps replaces agile"
quite the opposite: one feeds the other
in fact, agile often leads to DevOps
Myth: "DevOps is only useful in an agile environment"
agile principles help, but are not required
agile is a continuum anyway
DevOps can help lead to agile
but it is harder
Myth: "DevOps is incompatible with InfoSec"
DevOps tends to shy away from traditional controls
segregation of duty, change approval processes, manual security reviews, etc
but this doesn't mean controls are eliminated entirely
controls are instead integrated into every stage of daily work
and never forget, security is quality is security
Myth: "DevOps means eliminating Ops"
(the term "NoOps" does not help debunk this myth, by the way)
Ops work may change in form and function, but not spirit
they are still responsible for systems' health
Ops and Dev will need to "blend together"
by bringing Ops into the conversation from day 1, for example
this means Ops has a (loud) voice at the table
Myth: "DevOps is just Automation"
lots of the tools involve automation, yes
but automation doesn't happen easily without the rest of DevOps
the cultural shift
the process changes
Myth: "DevOps is only for open-source software"
Myth: it's only for FOSS projects
lots of commercial orgs do it for their internal projects
Myth: it's only doable using FOSS software
it's been used with lots of tool stacks, including mainframes and embedded systems
There is no single path
every organization is different, and has different context
your degree of management/developer/operations "buy-in", for example
many organizations share characteristics
it's why Dilbert so clearly strikes a nerve
Basic heuristics
embrace questions
know where you are starting
"What is our team's primary business goal?"
this is not the time for "mission statements"; be concrete
know why you are changing
look for common measurable goals
Basic heuristics
look for executive sponsorship
this is not the time to be asking forgiveness later
look for technical leadership
somebody will need to be the go-to answer person
Basic heuristics
look for a pilot project
not too big, but not too small
collocation helps to iron out the kinks
clearly-defined requirements
set goals
how do we know we are winning?
Basic heuristics
look for (and be) mentors
people will need guidance
include everyone
developers, QA, operations, all in the same standup
open communications
deal with logistical obstancles to free/easy/clear communication
change your on-call process
developers have to feel the pain of bad software too
Basic heuristics
create checkpoints
feedback, feedback, feedback
declare victory
ceremonies are important to human beings
Wrapping up
DevOps is about shortening the time from inception to deployment
DevOps is about adding feedback loops in every part of the process
DevOps is achievable in your organization
Books
The Phoenix Project, by Kim, Behr, Spafford
The DevOps Handbook, by Kim, Humble, DeBois, Willis
What is DevOps, by Loukides
Building a DevOps Culture
Release It!, by Nygard
Continuous Delivery, by Humble, Farley
Who is this guy?
Architect, Engineering Manager/Leader, "force multiplier"
Co-founder, Solidify US
http://www.solidify.dev
Principal -- Neward & Associates
Author
Professional F# 2.0 (w/Erickson, et al; Wrox, 2010)
Effective Enterprise Java (Addison-Wesley, 2004)
SSCLI Essentials (w/Stutz, et al; OReilly, 2003)
Server-Based Java Programming (Manning, 2000)
See http://www.newardassociates.com