- [Instructor] So what are DevOps and enterprise DevOps?
What objectives and challenges do they share?
What's different about them?
Let's have a look.
In traditional IT shops,
Dev and Ops are separated along a number of dimensions.
Separated into different teams,
organizational units or departments
with completely or mostly separate objectives
and responsibilities.
Values and principles,
methods and practices,
cultures and mindsets,
incentives and rewards,
knowledge and tools
and environments and invisibility.
Also, Dev tends to have primary responsibility
for what ITIL calls utility.
The functional requirements or features
and Ops tends to have primary responsibility for warranty.
The non functional requirements,
the keep it up and running part.
This was a source of friction.
There wasn't yet a strong notion of design
for our operation
let alone operation for design.
In this traditional scenario,
Dev's primary circle of concern is innovation
and making changes happen
and Ops' concern is stability.
Minimizing risk and efficiency of operations.
From an ITIL point of view
in this scenario Dev is concerned with the strategy,
design and transition phases of the life cycle
with the focus for Dev in transition on pitching
verses catching.
Ops is also concerned with transition
so there's some overlap
but Ops' focus is on catching
verses pitching of what gets released into the environment.
Both Dev and Ops are concerned with continual improvement
but typically with the focus
within their respective circles of concern.
In the traditional IT scenario,
Dev and Ops' objectives are not only separate
they're also in tension.
The idea behind tension metrics
is that separate teams with separate incentivized
opposing objectives creates a tension that is
a grain of sand that makes a pearl.
So for example if you and I work for a tractor factory
and you're in sales and just when the ship
builds a hundred tractors you just sold.
And I'm in manufacturing QA
and I want to make sure we check things out
before we ship them.
That's a good thing,
both the push and the push back
and that's the idea behind tension objectives.
Lastly in traditional IT
releases themselves are larger
and more physical in nature.
The frequency of releases is less often
and the level of automation is lower.
That is releases are more manual in nature.
This is fitting for the scenario
where releases are physical
rather than digital in nature.
A general rule of thumb for automation
is that you automate things that are low risk,
repetitive and frequent.
So in this light,
less automation makes sense.
Along with the fact that automation lends itself less
to physical artifacts than to digital ones.
And because the transaction costs
of moving forward
or rolling back releases
are much higher with physical verses digital artifact.
The culture of a focus on reducing risk
makes sense as well in this light.
Traditional IT shops set up these kinds of
separation of duties and large releases
with slow release cycles
and low automation for a good reason.
It worked,
it worked under conditions
where the primary artifacts in the workflow
were physical verses digital.
As workflow was constrained by that physicality
and the higher transaction costs that come with it.
Under these conditions,
traditional IT shops did things like waterfall
project management. Slow release cycles
and mega releases not because they were cave people
but because they were for example shipping physical media.
They couldn't just roll back a mistake
or try something out and pull it back
as you now can.
With things like blue green deployment.
The transaction costs were just oo high.
You can still see something like this
in the methods used for subscription services
verses packet software.
DevOps practices work well
if the thing your developer commits to
is running a service.
If instead you're shipping packet software
the customer downloads and runs.
The ISV model,
some DevOps practices are awkward.
To summarize, when the primary artifacts to be managed
are physical in nature
and the pace of flow of changes and releases
is relatively slow
and the size of changes and releases is relatively large
and the automation level is low.
The benefits of separation and tension objectives
can outweigh the costs.
Think about it,
if you're going to ship a million physical DVDs of software
and the transaction cost to make a mistake
or change is prohibitive.
Having a separate test and quality function makes sense.
You couldn't move that fast before digitization.
So at the pre-digitization phase,
checks and balances didn't get overloaded.
Now we know, with the advent of the cloud
the conditions have changed.
The problem with separation and tension objectives
comes in when you start to march from traditional
more physical IT to hybrid and to the cloud.
As you move from physical to digital artifacts
the pace of work increases dramatically.
Think about it,
as you ratchet up speed faster and faster
at some point the hand offs and checks can't keep up
and get over run.
Turning what had been an enabler
into a barrier into getting things done.
So in a primarily digital environment,
the benefits of separation of duties are lower
than the costs.
In DevOps, the traditional separation of duties
between Dev and Ops is known as the wall of confusion.
Where for example Devs write code and then
throw it over the wall to Ops who are supposed to deploy
and support it.
Please note that it's not like there isn't a place
for separation in enterprise DevOps
or even cloud native DevOps organizations.
For example, in modern IT organizations
identity management is often cored off in its own team
for a number of very good reasons.
The point here is that the traditional places
where separation was institutionalized
are not working and there are new places
where it does make sense.
Some people assume the wall of confusion is caused
by the stereotypical assumption that IT professionals
have poor people skills.
Well this may be the case in some specific instances
it's not the case in general.
The main cause is that part of the separation
is the institutionalization
of incentivized opposing behavior.
Which can be an enabler
when the work target is primarily physical
and becomes a barrier when it's largely digital.
Creating the wall of confusion.
Under increasingly digital conditions,
separation of duties results in warring tribes
of developers, sysadmins, security professionals,
netadmins, DBAs and so on.
They're in conflict with each other
more often than not.
That's the wall of confusion.
Digitization enables high levels of automation
and lowers the transaction cost
of moving forward or reverting back.
Enabling much more frequent smaller releases.
Breaking the utility of separation
and tension objectives.
In a traditional IT shops,
Dev teams are charged with innovation.
Developing new functionality,
making changes fast and moving fast
and Ops teams are charged with maintaining stability,
reducing risk and controlling change.
At a slower pace, separation and tension objectives
can be that grain of sand that creates the pearl
and as pace increases dramatically.
The institutionalization of separation
and incentivized opposing behavior
instead becomes the grain of sand in your shoes
that wears you down.
Something's got to give.
So what's an IT professional to do?