VIDEO: DevOps 101 (with transcript)

The simplest explanation of what DevOps is all about is detailed in the video. The video runs a little over eight minutes, and it provides a basis for building your DevOps career.

Transcript of the DevOps 101 Video

The transcript is not in verbatim but provides the essence of the message conveyed in the video.

Today, I am going to provide the simplest explanation on what DevOps is all about. I call this session as DevOps 101. This is the first video of the series, and I am going to focus on that part of DevOps that delves into the ITIL side of things.

OK. What is DevOps? It’s common knowledge that DevOps is made of two words – development and operations. In IT, either we are in development or in operations. With DevOps, the effort is to bring the development part of IT with the operations part of IT, which is unheard of so far.

Is it really unheard of is my question?

Say about twenty years back, we had IT teams that was small. The people in IT did development as well as operations. They did both. As IT grew, these two set of activities were ripped apart from that IT person. The development was given to one set of IT and the operations to the other. As the saying goes, what goes around, comes around. And that’s exactly what’s happening today. We are bringing development and operations together and calling it as a new methodology as a breakthrough to collaborate to help our customers derive value.

So, yes, DevOps’  methodology stems from the result that development and operations work together.

I said result and the reason for DevOps. DevOps is not so simplistic that you bring the two teams together and bingo, you get a new methodology. No, it’s not that simple. DevOps is all about the culture. It starts with the culture that IT staff doing their own things in their own little worlds are able to come on a common platform and work hand in hand for the value that is delivered. It is like democrats and republicans in the US and BJP and Congress in India coming together to pass a new revolutionary law. This will never happen in politics but in IT, yes, we have hope. DevOps brings the two streams together and the output, which is value for the customer, is way better than what it was earlier.

Let’s take a scenario where a release has gone horribly wrong when it is put into production. Let’s say that you are the project manager for the delivery of this piece of software. What is the first thing that comes to your mind? If you are thinking about rollback, type of defect, business impact if it is not rolled back etc, then I know that you are not being honest. The first that comes to your mind is who is this bugger who has developed this piece of code? Who is the tester who has signed-off on it? Why do we think subjectively and not objectively? Why do we think about the person and not what is needed to be done?

Its because of our culture. Our culture is such that we point fingers at people. We blame people for failures. We don’t look at the failures in the context of teams and getting out of a situation.

So how does DevOps change this culture?

In DevOps we don’t blame people. We believe in shared responsibility where the entire team is responsible for success of failure. So we don’t have individual champions who get crowned at the day but the entire team gets the glory. Well, in DevOps, we don’t blame people. The reason is that we build a system where in even if people make mistakes, it gets identified and rectified before it goes into production. So in DevOps, we create an environment where experimentation is rampant. We want people to express themselves and not fear repercussions. Even if they fail, no problem. We would have created this system of layers of insurances that allows defects to be identified much earlier in the process. To build this system, we need to make changes to the processes and also introduce and utilize a lot of automation.

So, in summary, DevOps is made of three parts: people, process and technology. The generic IT crowd think about technology and automation as DevOps which is not entirely true. So just your expertise over the DevOps toolset is not going to make you a DevOps coach or a DevOps architect. You need to know all three aspects: people, process and technology.