What is DevOps really? An explanation in layman's terms.

18 Oct 2017

Many people believe the concept of DevOps can be captured in a simple definition. I tend to disagree. I’m not saying the concept of DevOps is hard to grasp or anything, I just think there hasn’t been any definition which is absolutely on point and understandable for anyone not directly working in IT. In this blogpost I’ll describe how I look at DevOps as a concept and how I try to help customers move forward.

Okay so let’s face it, there are already so many established authorities who came up with their own definition of DevOps, that we don’t need yet another. It reminds me of that one XKCD we all know, right? Ok, cool.

Everyone knows (maybe after some Googling) DevOps has something to do with bringing people working in Development closer to people working in Operations to overcome clear issues like responsibility in case an application is not responding appropriately. In my opinion DevOps simply has to do with three things: People, Processes, and Technology. If you accept these three areas as individual axis, we get a simple XYZ-space with an origin (let’s forget about negatives here). I’ll return to that analogy in a second. First, let’s concentrate on the areas alone. If you would look at each of these areas as individual maturity levels, with zero maturity in the origin, and extremely mature in .. well, infinity, we would be able to map some real life situation mapped onto that axis. If we would isolate the technology axis for instance, then the origin would mean we would make no use of technology at all. Going forward on the axis, we would come across all kinds of technology or tools we could use. Stuff like IDEs (Visual Studio, Netbeans, Eclipse, JDev, …), Source Code Management (SVN, Git, Mercurial, TFS, …), Continuous Integration tools (Jenkins, Travis CI, Gitlab-CI, …), and so on and so forth. The same could be done with the people and processes axis. Moving along each axis should bring you in some kind of situation in which Development teams are working more closely to Operations teams.

Coming back to the combination of the three areas, then each combination is a real life situation in the DevOps operating domain. Every business concerned with building its own software is situated somewhere in that DevOps domain. Some had their focus historically set on technology (or tools), others might have focused some more on processes or people, it really doesn’t matter.

Now think of the origin in our XYZ-space, a place where a lot can be done to improve one’s software building capabilities. Next, think of some large company (say Amazon for instance) which has multiple deployments per day. This is clearly a situation that lies far from the origin. People are well trained in following properly designed processes and they use some kind of technology or tools. Is this the ultimate DevOps way of doing things? Not necessarily. I like to think of this situation as a bicycle chain. There are no loose chain links (at least in plain sight), and the company is able to quickly have a change deployed on their servers in reasonable time. Is this the end goal then? Again, not necessarily. The company might want to make things more efficient, or they would like to add features (more logging, more or better monitoring). It all depends.

Having said that, I think most of us have had customers asking questions like

I would like to do DevOps, because that’s trending everywhere in technology-land, can you help me with that?

Of course we first have to explain what DevOps is, but none of the known definitions will help our customer understand what it exactly means since it’s not necessarily their area of expertise. I usually explain the analogy described above, after which I suggest to make up the status quo; where in the XYZ-space are they situated now, or which chain links do they already have (with or without some linked to one another already), and what kind of chain links they feel they are missing to complete the bicycle chain? So when would they like to be where having spent how much resources? All these questions should be answered in light of one underlying question; Will this help to build and maintain a software application in a more efficient way than we are doing now?