Why DevOps is just a buzzword

 January 5, 2018

I found myself multiple times in situations where people were trying to explain to me how much they are (or would like to be) DevOps and how awesome DevOps is and how productive their teams had become since when they merged the Dev team and the Ops team, and they don’t have any team which is not DevOps and application-centric. I usually stare at them thinking that they have no idea what they are talking about, or they have just outsourced all the non-application-centric side of their IT and have not realized it.

Also, in the last 14 years I’ve been working in IT consulting and no matter where I was at that moment, everyone was saying it was doing DevOps, but I did not see any DevOps dynamics in their teams. I think the reason is that DevOps started in companies with the right culture for it and then it became mandatory for companies to “be DevOps” if they wanted to attract talented developers and therefore every company rushed to implement DevOps bits in their non-DevOps culture ending up with something that is not DevOps.

To better clarify my points, let’s start with the Wikipedia definition of DevOps:

DevOps (a clipped compound of “development” and “operations”) is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, and more dependable releases, in close alignment with business objectives.

There are some things in this definition that are implemented in companies, for instance, the idea of testing. I’m saying the idea because very often the number of tests is suboptimal, but - at least - they are putting some effort into it. Another part that surely is starting to be widely adopted by companies is the idea of bringing development practices to infrastructure (from versioning, to build repeatability, to automation).

On the other hand, there are still many things done in a non-DevOps fashion within companies. An example of this is the idea of shortening release cycles. Yes, we did saw a reduction of length of release cycles in the last few years, but there are many companies which are well above the one month per release cycle, which is not very DevOpsy from my point of view.

Another big part that is still missing is the holistic part of DevOps. My understanding of DevOps is that you have all the advantages only if your whole process is structured in DevOps way, and not if you have “DevOps islands in an ocean of legacy behaviors”.

I think there are two common problems in how DevOps is introduced in companies:

Forgetting that there are people in companies
Try to keep everything “as is” but DevOps

The first problem often occurs in companies with heavily technical culture, where the management decides that they need to become DevOps, they change tools and teams but forget to explain to the people how they are expected to behave in this new environment.

The second problem is prevalent in banks and other high-regulated organizations. Being so used to be full of complex processes, they don’t acknowledge that the procedures are often the problem and that processes can often be rethought from the ground up to guarantee the same level of security without being considerable obstacles to productivities. For instance, I’ve seen a bank where they had forms to be completed for the promotion of applications from one environment to the other (which had to be repeated for every single new version of the already-approved applications) which needed to be printed, compiled, signed and delivered to a dedicated team which would have approved it. I’m sure that they could have adopted some form of electronic forms which would have granted the same level of security, without forcing a process that was several days longer than it needed to be.

Another thing that I think is problematic in the way many companies have implemented DevOps bits is that they are applying it to just high-level applications (usually business applications and customer-facing applications) while they should consider also Site Reliability Engineering (SRE) teams to be DevOps. On a fun note, I think that very often SRE teams are usually more DevOps than their application counter-part, probably due to the complexity of modern architectures.

I think that at the end of the day is good that companies are moving closer to the DevOps way of doing things, even if today many companies are claiming they do DevOps while they don’t.

 Linux, Programming

 DevOps, Marketing

Say something

Comments

Victor Volkman on 2021-09-13 13:29:32 UTC said:

My opinion is that DevOps refers to the business of cloud computing as opposed to on-prem in terms of high-availability of sites, services, and APIs. It isn’t a methodology as far as I’m concerned. All that other stuff is basic Agile.

Fabio Alessandro Locati on 2021-09-13 17:04:21 UTC said:

Hi Victor, I agree with you point that nowadays, in many realities, the idea of DevOps is completely mixed with Cloud Computing. I still feel like this is the wrong way of addressing it, but I guess that if everyone uses a word with a certain meaning there is no much point for me to disagree, since words have no intrinsic meaning, but just the meaning that the majority of the analyzed population assign to them.