- [Instructor] In the end,
both enterprise IT and cloud-native devops shops
have the same end in mind,
delivering fast time to value
with quality and continuous improvement.
While the particular conditions
typically found in enterprise IT
and cloud-native shops differ,
primarily along the lines of the level of physical
versus digital workflow,
and accordingly the means employed
to achieve this north star objective may differ,
there should be no dispute that both kinds of shops
are aiming for the same overall result.
ITIL-driven and devops shops
share the same two core challenges
to achieving fast time to value
with quality and continuous improvement.
The first is unnecessary variation
and the second is unnecessary dependencies.
Both enterprise IT and cloud-native devops shops
must root out unnecessary variation and dependencies
to achieve fast time to value
with quality and continuous improvement.
An example may help illustrate.
Back in the day, there was a network protocol called X.25.
It was great for using in places
where you couldn't count on nice clean circuits to ride.
It was great because it had super high
error-correcting overhead.
You knew those packets were going to get through eventually.
Along comes fiber
and suddenly you can count on nice clean circuits
and you don't need all of that overhead.
Here's the point.
Just as the amount of protocol overhead required
is a function of how messy or clean the circuits used are,
the amount of overhead you will have
in reaching your outcome of faster time to value
with quality and continuous improvement
will be a function of how messy
or clean the target you're managing is.
Think about it.
Why do we have to meet to discuss a change
or a release or a risk or a project
or just about anything?
Well, at root,
it's dependencies and variation that we must sort out
or we'll end up shooting ourselves and others
in the proverbial foot.
Reduce the tractable portion
of your dependencies and variation
and you reduce your overhead and missteps and rework.
I say tractable portion
because there are both necessary and rational
and unnecessary and irrational variations and dependencies.
Devops practitioners have a metaphor
for irrational variations.
They call it pets versus cattle.
Pets are all unique.
We give them names, et cetera.
It's what we do with traditional servers too.
Each has a name.
This one has a utility drive.
This one does not.
This one is running this version of software.
This one is not.
How cute.
Well, not really
because wherever we have these snowflake entities,
meaning each one is unique in some way like snowflakes,
where we have snowflake servers,
snowflake switches and the like,
we have to meet and talk about stuff
when we have a change or when we have a release
and it takes longer to figure out problems and incidents.
It adds overhead all the way up and down the stack.
Besides creating an enormous time drain and overhead
by requiring discussion and remediation,
unnecessary variations erode the quality
of a product and service
when you allow them to creep into your services,
your processes, your technology,
and the tooling to manage it,
and the skills, knowledge, and mindsets of your people.
So do yourself a favor and move to vanilla
or whatever flavor is your favorite whenever you can
to the extent that you can.
Our other shared enemy is unnecessary dependencies.
Think about it.
Why do groups need to meet at all to discuss a change?
Why do we have to resort to large monolithic releases
on infrequent cycles?
It's dependencies.
Here's an example.
A client of mine started with a two-year release cycle
with lots of people in the room discussing,
you got it, dependencies.
And afterwards, having lots of stuff blow up in the release.
And they went from that to a release every year,
to every quarter, to now releasing every few minutes.
How did they do that?
They did it by relentlessly rooting out dependencies.
They eliminated breaking changes
by using for example data contracts with web services
instead of accessing the schema directly.
They began using versioned APIs
to allow others to move ahead when they were ready
and not be broken in the meantime.
They instituted a lot of improvements like these
resulting in less breaking changes,
lower process overhead, and faster time to value.
Rooting out unnecessary variation and dependencies
lowers the height of obstacles we must jump over
to achieve faster time to value
with quality and continual improvement
in both cloud-native devops and enterprise devops shops.
So there you have it.
We've discussed what cloud-native devops
and enterprise IT shops have in common.
Let's have a quick look at where they differ.
The key inflection points where enterprise IT
and cloud-native devops shops differ
are in their typical IT environment, deployment mechanism,
work organization and orchestration,
scale and operational model.
The typical environment in enterprise IT shops
is a hybrid of traditional and cloud.
In a cloud-native shop, it's all cloud.
Deployment in enterprise IT shops tends to be ops driven
with ITIL-driven change and release gates
where in cloud-native shops it's dev driven
with on demand self-service deployments.
Work is typically orchestrated across disparate siloed teams
in enterprise IT shops
where in cloud-native shops it tends to be single teams
by service with shared objectives, mindsets,
knowledge, tools, and visibility.
And lastly, the operational model in enterprise IT shops
is typically ITIL-driven practices
where in cloud-native it's devops.
What else is different?
Well, in both cloud-native devops and enterprise IT shops,
achieving objectives is a function of resources,
capabilities and constraints
which are typically very different between them.
Let me explain.
Resources are what you have to work with,
things like money, your tooling chain, applications,
your people, et cetera.
You can think of these as factors of productions.
Capabilities are how well-managed and organized you are,
the practices you use, what you know,
and your people managing things.
It's your ability to transform
a given set of resources into value.
With all other things being equal,
a higher capability organization, given the same resources,
can achieve faster time to value
with better quality and continuous improvement
than a lower capability organization can.
Your constraints are just that,
the limits of your capabilities and resources
and other factors like time.