After watching this video, you will be able to differentiate between traditional Ops and DevOps,
describe ways Dev and Ops view each other, and list required DevOps behaviors.
DevOps presents diametrically opposed views to how traditional enterprises think.
Enterprises are built around end-to-end processes that see "new" as complex,
high risk, and expensive, and time-consuming. They approach anything new as a one-time
project to be completed in a fixed time frame for a fixed budget and then
move the people on to the next project. DevOps seeks to turn this on its head,
breaking big projects down to deliver a continual series of small changes that are more manageable.
Smaller changes can be completed with less risk, so DevOps reduces the risk of large projects.
The catch is that small changes cannot survive the traditional overhead that
enterprises add to everything you want to do. Processes like change review boards don't
work in DevOps because they cannot move at the speed of need for small changes.
We have a clash of work cultures between traditional Ops and DevOps.
In traditional Ops, we make manual configuration changes to critical infrastructure.
In DevOps, we automate deployment to all environments.
This is why traditional Ops needs change review boards.
Everything is done manually, and humans are fallible and even if the change is approved,
there is no guarantee that it will be implemented correctly.
In traditional Ops, application architectures are defined by the network design.
In DevOps, it is the other way around. Network design
is defined by the application architectures.
We have software-defined networks that conform to whatever the architecture needs.
In traditional Ops, bespoke infrastructure is built once and then maintained forever.
In DevOps, ephemeral infrastructure is created for new deployments.
We don't maintain the infrastructure. We tear it down and replace it entirely.
You can't do this unless everything is automated. The manual overhead would slow you down too much.
In traditional Ops, risk is managed through change windows.
Changes are only made at certain times, predesignated as change windows.
That is, no change can happen outside those change windows.
In DevOps, risk is managed through progressive activation.
We can make a change to the system at any time. We use deployment techniques to activate or
deactivate the change as needed. Finally, traditional Ops
has a process biased toward “build once.” Traditional Ops builds everything manually and
maintains it forever, or at least until it's not needed anymore, which is usually several years.
Sometimes they build it once and can't figure out how to build it again the
same way because the build wasn't documented. In DevOps, processes are re-engineered for high
volume, rapid throughput of changes, making builds repeatable, leveraging Infrastructure as Code to
ensure that anything we do can be built again. When cultures clash, it's a no-win scenario.
Development is measured by how much innovation developers can produce.
They keep up with the changing needs of the users by developing and deploying
new enhanced capabilities. Operations wants stability.
They want to ensure that users can use those services and applications
and that their data and information are kept safe. These two goals are in opposition.
You can't have both! Andrew Clay Shafer called this the "wall of confusion"
that exists between Dev and Ops. What we need to do is break down that wall.
The first step is to change the way development and operations view each other.
Ops? Well...
the Ops view of development is that development is throwing dead cats over the wall.
They manually implement changes. They lack back-out plans and lack testing.
Their environments do not look like the production environments.
The Devs thinks Ops makes these all-or-nothing changes in the dead of night during these
change windows. They are furthest from code, so they don't understand it.
Ops is using cut and paste from runbooks, or Word documents.
Silos breed apathy. You cannot have people working in two silos
with diametrically opposed metrics. It is never going to work. You
must bring these people together. You must give them one set of metrics
that add value to the customer. The website
works, the developers get the praise. The website is down, Ops gets the blame.
Did I mention the no-win scenario? This is not a healthy working environment.
Here are some required DevOps behavior. DevOps turns a number of these things
on their head. You need to break down
the organizational silos and the handoffs that they cause and move to a culture of
shared ownership and high collaboration. There is no hole on your side of the boat.
Everyone must see themselves as in this together for a common goal.
You must go from fear of change to managing risk by embracing change,
managing changes that are small. Big changes are always scary to everyone.
Make the changes small and manage the change.
Go from building something once, these hand-crafted, snowflake servers where,
each one is unique, and you can never find another one just like it, to using ephemeral
infrastructure deployed using Infrastructure as Code techniques so that they are repeatable.
Every time you build a docker container, every time you build a virtual machine,
build it exactly the same. If you did not change the code, it will be built
exactly the same, and get the same results. Change from manual fulfillment (ticket queues,
people manually doing things) to enabling automated self-service.
I've seen companies adopt the cloud and then put a ticket queue in front of it so that only IT
people can provision from the cloud. That defeats the whole purpose
of having self-service cloud. Self-service is the way to move quickly.
Finally, you must change from alarms, and callbacks, and escalations
to fast feedback loops that are data-driven. Make sure you can get that information
about what is going wrong in production and then react to it when you need to.
These are the behaviors that must change in order for you to fully become a DevOps organization.
In this video, you learned that enterprises see change as complex and time-consuming.
DevOps breaks big projects into a series of small, manageable changes.
Traditional Ops builds once and maintains. In DevOps,
ephemeral infrastructure is created for each new deployment.
Dev wants innovation, while Ops wants stability. Required DevOps behaviors include shared
ownership, collaboration, embracing change, and data-driven responses.