1
00:00:07,360 --> 00:00:12,240
After watching this video, you will be able to
differentiate between traditional Ops and DevOps,

2
00:00:12,800 --> 00:00:17,360
describe ways Dev and Ops view each other, and
list required DevOps behaviors.

3
00:00:18,480 --> 00:00:23,520
DevOps presents diametrically opposed
views to how traditional enterprises think.

4
00:00:23,520 --> 00:00:28,560
Enterprises are built around end-to-end
processes that see "new" as complex,

5
00:00:28,560 --> 00:00:33,920
high risk, and expensive, and time-consuming.
They approach anything new as a one-time

6
00:00:33,920 --> 00:00:38,000
project to be completed in a fixed
time frame for a fixed budget and then

7
00:00:38,000 --> 00:00:43,040
move the people on to the next project.
DevOps seeks to turn this on its head,

8
00:00:43,040 --> 00:00:48,240
breaking big projects down to deliver a continual
series of small changes that are more manageable.

9
00:00:48,800 --> 00:00:54,000
Smaller changes can be completed with less risk,
so DevOps reduces the risk of large projects.

10
00:00:54,720 --> 00:00:59,920
The catch is that small changes cannot
survive the traditional overhead that

11
00:00:59,920 --> 00:01:05,200
enterprises add to everything you want to do.
Processes like change review boards don't

12
00:01:05,200 --> 00:01:09,600
work in DevOps because they cannot move
at the speed of need for small changes.

13
00:01:10,160 --> 00:01:14,080
We have a clash of work cultures
between traditional Ops and DevOps.

14
00:01:15,040 --> 00:01:20,400
In traditional Ops, we make manual configuration
changes to critical infrastructure.

15
00:01:21,360 --> 00:01:25,120
In DevOps, we automate
deployment to all environments.

16
00:01:25,120 --> 00:01:27,920
This is why traditional Ops
needs change review boards.

17
00:01:27,920 --> 00:01:33,600
Everything is done manually, and humans are
fallible and even if the change is approved,

18
00:01:33,600 --> 00:01:36,480
there is no guarantee that it
will be implemented correctly.

19
00:01:38,080 --> 00:01:42,560
In traditional Ops, application
architectures are defined by the network design.

20
00:01:42,560 --> 00:01:45,200
In DevOps, it is the other
way around. Network design

21
00:01:45,200 --> 00:01:47,520
is defined by the application architectures.

22
00:01:47,520 --> 00:01:51,680
We have software-defined networks that
conform to whatever the architecture needs.

23
00:01:53,600 --> 00:01:59,360
In traditional Ops, bespoke infrastructure
is built once and then maintained forever.

24
00:02:00,240 --> 00:02:03,920
In DevOps, ephemeral infrastructure
is created for new deployments.

25
00:02:04,480 --> 00:02:09,600
We don't maintain the infrastructure.
We tear it down and replace it entirely.

26
00:02:09,600 --> 00:02:14,800
You can't do this unless everything is automated.
The manual overhead would slow you down too much.

27
00:02:16,160 --> 00:02:19,840
In traditional Ops, risk is
managed through change windows.

28
00:02:19,840 --> 00:02:24,400
Changes are only made at certain
times, predesignated as change windows.

29
00:02:24,400 --> 00:02:27,600
That is, no change can happen
outside those change windows.

30
00:02:28,160 --> 00:02:31,680
In DevOps, risk is managed
through progressive activation.

31
00:02:31,680 --> 00:02:36,960
We can make a change to the system at any time.
We use deployment techniques to activate or

32
00:02:36,960 --> 00:02:41,920
deactivate the change as needed.
Finally, traditional Ops

33
00:02:41,920 --> 00:02:47,280
has a process biased toward “build once.”
Traditional Ops builds everything manually and

34
00:02:47,280 --> 00:02:52,960
maintains it forever, or at least until it's not
needed anymore, which is usually several years.

35
00:02:52,960 --> 00:02:56,320
Sometimes they build it once and can't
figure out how to build it again the

36
00:02:56,320 --> 00:03:02,512
same way because the build wasn't documented.
In DevOps, processes are re-engineered for high

37
00:03:02,512 --> 00:03:08,720
volume, rapid throughput of changes, making builds
repeatable, leveraging Infrastructure as Code to

38
00:03:08,720 --> 00:03:16,240
ensure that anything we do can be built again.
When cultures clash, it's a no-win scenario.

39
00:03:16,240 --> 00:03:20,080
Development is measured by how much
innovation developers can produce.

40
00:03:20,080 --> 00:03:24,080
They keep up with the changing needs of
the users by developing and deploying

41
00:03:24,080 --> 00:03:28,720
new enhanced capabilities.
Operations wants stability.

42
00:03:29,280 --> 00:03:32,960
They want to ensure that users can
use those services and applications

43
00:03:32,960 --> 00:03:39,120
and that their data and information are kept safe.
These two goals are in opposition.

44
00:03:39,760 --> 00:03:45,520
You can't have both! Andrew Clay Shafer
called this the "wall of confusion"

45
00:03:45,520 --> 00:03:49,760
that exists between Dev and Ops.
What we need to do is break down that wall.

46
00:03:49,760 --> 00:03:53,280
The first step is to change the way
development and operations view each other.

47
00:03:55,113 --> 00:03:56,720
Ops? Well...

48
00:03:56,720 --> 00:04:00,000
the Ops view of development is that development
is throwing dead cats over the wall.

49
00:04:00,000 --> 00:04:04,000
They manually implement changes.
They lack back-out plans and lack testing.

50
00:04:04,000 --> 00:04:06,640
Their environments do not look
like the production environments.

51
00:04:07,617 --> 00:04:13,040
The Devs thinks Ops makes these all-or-nothing
changes in the dead of night during these

52
00:04:13,040 --> 00:04:17,760
change windows. They are furthest from
code, so they don't understand it.

53
00:04:17,760 --> 00:04:20,880
Ops is using cut and paste from
runbooks, or Word documents.

54
00:04:22,800 --> 00:04:27,360
Silos breed apathy.
You cannot have people working in two silos

55
00:04:27,360 --> 00:04:31,840
with diametrically opposed metrics.
It is never going to work. You

56
00:04:31,840 --> 00:04:35,600
must bring these people together.
You must give them one set of metrics

57
00:04:35,600 --> 00:04:39,200
that add value to the customer.
The website

58
00:04:39,200 --> 00:04:43,840
works, the developers get the praise.
The website is down, Ops gets the blame.

59
00:04:44,480 --> 00:04:49,360
Did I mention the no-win scenario?
This is not a healthy working environment.

60
00:04:50,080 --> 00:04:55,040
Here are some required DevOps behavior.
DevOps turns a number of these things

61
00:04:55,040 --> 00:04:57,920
on their head.
You need to break down

62
00:04:57,920 --> 00:05:02,880
the organizational silos and the handoffs
that they cause and move to a culture of

63
00:05:02,880 --> 00:05:08,000
shared ownership and high collaboration.
There is no hole on your side of the boat.

64
00:05:08,000 --> 00:05:11,600
Everyone must see themselves as in
this together for a common goal.

65
00:05:12,720 --> 00:05:17,760
You must go from fear of change to
managing risk by embracing change,

66
00:05:17,760 --> 00:05:22,640
managing changes that are small.
Big changes are always scary to everyone.

67
00:05:22,640 --> 00:05:25,280
Make the changes small and manage the change.

68
00:05:26,640 --> 00:05:31,280
Go from building something once, these
hand-crafted, snowflake servers where,

69
00:05:31,280 --> 00:05:35,840
each one is unique, and you can never find
another one just like it, to using ephemeral

70
00:05:35,840 --> 00:05:41,600
infrastructure deployed using Infrastructure
as Code techniques so that they are repeatable.

71
00:05:41,600 --> 00:05:45,440
Every time you build a docker container,
every time you build a virtual machine,

72
00:05:45,440 --> 00:05:50,000
build it exactly the same. If you did
not change the code, it will be built

73
00:05:50,000 --> 00:05:56,320
exactly the same, and get the same results.
Change from manual fulfillment (ticket queues,

74
00:05:56,320 --> 00:06:01,200
people manually doing things) to
enabling automated self-service.

75
00:06:01,200 --> 00:06:06,160
I've seen companies adopt the cloud and then put
a ticket queue in front of it so that only IT

76
00:06:06,160 --> 00:06:09,440
people can provision from the cloud.
That defeats the whole purpose

77
00:06:09,440 --> 00:06:14,400
of having self-service cloud.
Self-service is the way to move quickly.

78
00:06:15,360 --> 00:06:18,960
Finally, you must change from
alarms, and callbacks, and escalations

79
00:06:18,960 --> 00:06:24,000
to fast feedback loops that are data-driven.
Make sure you can get that information

80
00:06:24,000 --> 00:06:27,680
about what is going wrong in production
and then react to it when you need to.

81
00:06:28,240 --> 00:06:34,329
These are the behaviors that must change in order
for you to fully become a DevOps organization.

82
00:06:35,280 --> 00:06:39,840
In this video, you learned that enterprises
see change as complex and time-consuming.

83
00:06:39,840 --> 00:06:43,520
DevOps breaks big projects into a
series of small, manageable changes.

84
00:06:44,240 --> 00:06:47,760
Traditional Ops builds once
and maintains. In DevOps,

85
00:06:47,760 --> 00:06:50,560
ephemeral infrastructure is
created for each new deployment.

86
00:06:51,440 --> 00:06:57,920
Dev wants innovation, while Ops wants stability.
Required DevOps behaviors include shared

87
00:06:57,920 --> 00:07:03,000
ownership, collaboration, embracing
change, and data-driven responses.