Common DevOps Myths Managers Believe

There is the DevOps handbook, the most authoritative source. It has an entire section dedicated to myths about DevOps. Why write an article? Well, in my opinion, the book not only explains the methodology, but also sells it. This is why the myth section only debunks misconceptions, which the authors picked for the purpose, and not the ones actually popular. Here I’m intending to bust the myths circulating in the real world which I stumbled upon explaining the methodology to my listeners. Let's get started.

1. DevOps Applies to You

No, DevOps is not for everyone. The myth comes first because even some of the founding fathers seem to deliberately encourage it. For example, Gene Kim et al. in The DevOps Handbook somehow forgets to mention that DevOps is not for everyone, but speculates on its universal applicability. Check out the quote (I put the questionable parts in italics): “... there is now an overwhelming weight of evidence that the problems described above happen almost everywhere, and that the solutions associated with DevOps are nearly universally applicable.” Here is more: “In almost every IT organization, there is an inherent conflict between Development and IT Operations which creates a downward spiral ...”.

I beg to differ, there are a whole lot of IT organizations for which it’s not the case at all, or in part, or even is not applicable. Some organizations do not have an IT operations department or a production environment, for example, consulting shops. They often have a customer support department to help with SLAs, but they may not have one at all e.g. companies that customize Wordpress, or consultants who are involved in security testing. There are IT organizations without a software development department. Many hosting companies are such organizations. They might have quite complicated tech arrangements, but all the software can be either someone else's “box”, or “cloud”, or written by external consultants.

John Allspaw, writes more carefully (but John, why do you write this?): “No matter what industry you are in, or what product or service your organization provides, this way of thinking is paramount and necessary for survival for every business and technology leader.”

Sorry to hurt your consulting guys, but it’s not. Do you believe that DevOps as a way of thinking is the paramount in building bridges and tunnels? Then I have a bridge to sell you.

2. DevOps Will Make Your Life Easier

Let’s suppose that DevOps can possibly be implemented for your business function at least to some extent. However, DevOps might be no good for you. There ain't no such thing as a free lunch:

  • implementing DevOps will require restructuring your organization, this might be a long and risky undertaking;

  • it will be necessary to invest resources to rework your technical practices;

  • and, most importantly, continuous delivery will require additional costs for each new feature, every day.

The difference in difficulty of implementing DevOps for different software delivery models is massive. It is not at all difficult to implement DevOps for a web project in a small company, whereas just DevOps technical bits of Chrome browser development ecosystem are huge and monstrously complex.

It may be that the very nature of your business does not imply benefiting from DevOps. For example, you release computer games with hefty marketing budgets. You can quickly release a new version after problems with 1.0.0. Will your users tolerate the problems and keep from uninstalling the game until 1.0.1 arrives? Or maybe you are writing software for a nuclear reactor or a massive industrial system where the cost of error is just too high. Continuous delivery does not make practical sense where it’s not feasible to tolerate an eventual error in production.

To put it short, if such benefits as

  • short time to market (TTM),

  • fast automated low-risk deployments,

  • an up-to-date release candidate available at any given moment,

  • steady and predictable flow of work

are not enough to justify paying the price, then there is no point in implementing DevOps for you.

3. DevOps is for Internet Companies Only

One of the most seminal reports “10 Deploys a Day” by John Allspaw and Paul Hammond indeed was about the needs of Flickr, an online service. The most famous DevOps success stories arguably happened with online companies.

However, if you have a store, you don’t have to switch the entire business to DevOps, you can only do this with the online department. If you have a bank, you do not have to transfer all the business functions to the new methodology, but you will likely get an advantage if you employ DevOps for the web user interfaces development.

Currently, there are lots of success stories of “non-online” companies that have transferred parts of their business functions to DevOps.

4. DevOps is a Technical Thing

There is an opinion that DevOps is something that software developers, admins, and other “technical people” do. Yes, it is difficult to imagine DevOps without the technical part properly implemented, but the gist of DevOps movement is about people.

Even ultra-fast deployment will not dramatically reduce Time to Market without reworking processes into end-to-end streams of tasks, without sharing knowledge and responsibility, and agreements with business and within teams.

In order to solve the problem of building quality in, it’s not enough to just write a lot of tests and collect a bunch of telemetry. All these measures should be deeply understood by each member of the team responsible for the implementation, and, ideally, should come from them. All this should be done understanding why, where and how much you need it.

Without scientific approach to work, measuring results and testing hypotheses, it is difficult to imagine the very efficiency and reliability that DevOps can deliver.

Note that the above is not purely technical, but rather the opposite. And, as in the well-known koan, actions without understanding will give nothing.

5. Implementing DevOps Is Following a Process or Using a Tool

Is it possible to follow some kind of flowchart or install some DevOps Server Ultimate 9000 and just do what the tool says?

For simplicity, I'll start with the tool. Yes, implementing DevOps completely without automation is unrealistic, but in most cases you can do with Linux, git, and bash. Will it be as effective as possible? Often not. Will it work? Yes. From DevOps point of view, same task can be solved in completely different ways. Sometimes you can use Docker, but usually you can solve the same problem with a fixed farm, Puppet and deploying with git, or you can opt to implement the same thing in the cloud using vendor tools. If you prefer, use Jenkins, or Bamboo, or, say, TeamCity, and, in any case, there are GNU Make and shell scripts. On the contrary, purchasing or installing all the tools and waiting for a miracle to happen is the same as buying an expensive tracksuit, the best running shoes in the world and waiting for Olympic gold to be brought to you.

It’s a bit more complex about the process. Let's talk about SCRUM. SCRUM is a rather formalized Agile, which suits some teams and doesn’t suit the others. A number of teams still could use a different version of Agile, taking into account the specifics of the teams and the businesses. In this sense DevOps is more like Agile in a broad sense than specifically SCRUM. This is why there is no single process or even a set of exact requirements for DevOps. In addition, the production model for DevOps is Lean. With Lean, the same thing is true: you can apply a set of approaches, but you don’t have a one-size-fits-all step-by step approach with a common endpoint. Such business, such Lean. The same is true for DevOps.

6. DevOps Specialists are the Only Specialists Required

Even assuming that such “broad specialists” exist, many areas of expertise require years to master and then demand constant practice to stay current: network engineers, programmers, QA specialists, etc.

In addition, some tasks are best done with different mindsets. We all know that testing by developers only and having dedicated testers are completely different things.

Involving different specialists in joint effort to help them deliver as much as possible using their knowledge and experience is what DevOps advocates, and not renaming one of occupation roles, for example, admins, into DevOps engineers.

7. DevOps Replaces Existing Product Management Approaches and Tools

New consultant - new methodology - new life? Not at all necessary. Firstly, maybe DevOps just doesn't suit you. Secondly, DevOps is not something started from scratch. Yes, DevOps is an umbrella term that describes a number of managerial and technical approaches used together. But most of these approaches are not new at all, e.g. they were used in Toyota, GM and Ford factories.

For example, if you already have Lean implemented and use the “end-to-end” Kanban for all tasks, starting with gathering requirements and ending with launching in the production environment, then maybe you already have 50 percent of DevOps If you also have CD, then it’s rather 80 percent.

Development team uses SCRUM with 1 week cycle with great results? No need to break anything. You absolutely can do with a weekly deployment cycle, this is legal. You can have a weekly development cycle and time to market (TTM) of 1 week, or you might be able to deploy in 17.6 seconds, and have the development cycle and TTM of 2 months.

It may seem that continuous delivery has fundamental contradictions with good practices in IT, security and the like. The suspicions are not entirely unfounded, and DevOps definitely has its limits of applicability. However, you can try to partition your systems so that compliance is isolated in parts that are changed rarely. If the compliance is internal, maybe the time has come to stop rubber stamping, and design realistic approval procedures?

In any case, the entirety of the knowledge you have, and not just DevOps, will help you to better organize work.

There Are Others

This concludes my short review of the myths about DevOps that circulate in reality. Next time I will describe the common misconceptions which have some merit to them.