You: "Our infrastructure is failing!" Management: "DevOps can help us! Get DevOps!"

You: "Our time to release is too slow!" IT Consultant: "Get some DevOps! That can really help!"

You: "Our builds are constantly failing!" Developers: "Get us some DevOps! They can automate it!"

You: "The servers aren't resilient!" Vendor: "Man, have you considered DevOps? They can help with resiliency and redundancy!"

We are on the cusp of 2019 and the term "DevOps" was coined nearly 10 years ago. The common definition has solidified over time, and is available to anyone who looks - yet the problem exists that somehow, "DevOps" became a cure-all for technology problems and technical debt.

I harp on this lots. In my travels I commonly encounter senior managers and executives who think that DevOps actually is the cure rather than addressing the problems. I will try and set the record straight:

DevOps will not fix your problems.

Everyone lied. Sort of. The people that are more interested in making money than solving the problem lied. The people that epitomize the peter principle lied to you. Managers that love buzzword bingo lied to you.

So I repeat: DevOps will not fix your problems.

I threw out several easy examples, things that I have actually heard.

"Our infrastructure is failing!" I heard this outside of an Amazon Partner session two years ago at AWS re:Invent while a couple of gents were getting coffee. The response was "DevOps can help us!" I don't disagree that properly enacting DevOps processes could probably help, but it won't solve the problem. Architecture review, investment, and planning for failure would help - but the expectation that if you just "Get DevOps!" the magic will revive the beast is a bit spurious.

"Our time to release is too slow!" I have heard this more times than I can count, but it is almost always from legacy companies that can not figure out that gating massive change serves a purpose. Rapid iteration and release cycles are great if you have single feature releases that can be tested and pushed out with minimal effort, but when management dictates that your release cycle will be three times a year then complains that the cycle is not fast enough, one does not have a problem with getting things out the door, one has a problem with bad management.

"Our builds are constantly failing!" Good. They should be failing from time to time. Everyone should know why. There should be a build report and everything. Changes should be documented. "Get DevOps! They can automate it!" I heard this fun guy at a tech meetup. I do not think I could have rolled my eyes any harder. Let us correct, first: DevOps are not people, they are practices, so DevOps could not automate anything. If you did, however, have some people to automate the build - great! However automating the build process will not likely fix the problem of builds failing. It can just make the process consistent and make sure that every person that needs to know why can get at the appropriate information.

"The servers aren't resilient!" To be honest, I do not even know what this one meant. I guessed that the person with the complaint meant 'redundant' but I did not have a chance to ask. DevOps does not anywhere guarantee redundancy. The process itself is about making sure that things change in a consistent, tested manner and that the results are monitored. Architecture defines redundancy, so if the application and the infrastructure are well architected, then the people applying the practice of DevOps should be able to make sure that such things are tested and deployed properly.

These are not all the things DevOps processes cannot do for you; they can also not slice, dice, make julienne fries, cure cancer (or the common cold), fix everything wrong with politics today, make those kids turn down that music, or finish the yardwork.

The problem in almost all of these cases is twofold. The first issue is a lack of understanding of the problem itself. The second issue is a blind acceptance of a miracle cure.

DevOps is not a cure for failing infrastructure. Updated infrastructure is the cure for that. It might require time and money or a new approach. DevOps is a practice that can help with a new approach, but it does not guarantee more time or money to replace equipment, and DevOps will not cause infrastructure to "un-fail."

DevOps is not a cure for slow release cycles unless the problem revolves around the operational process for releases. If a company does releases once a quarter on a Sunday starting at 7 PM and it takes 40 people on a phone bridge and 6 hours, DevOps might be able to get that 6 hours down to 1 or 2 and remove the need for 40 people on the phone, but it can not fix the release cadence.

DevOps is not a cure for failing builds as I already mentioned. That is a development problem. DevOps as a practice can assist in feedback loops as part of a continuous integration process, but it will not fix failing builds directly.

DevOps does not create resiliency or redundancy. The former is created by a solid deployment pipeline, easy to implement runbooks, and A/B types of releases that prevent significant impact to your product during a release cycle. Redundancy was already touched on previously.

The fact is that after 10 years, DevOps is not the magic bullet that so many want it to be. Strong architecture, solid engineering, good documentation, and a reinvestment in people and technology - that's the magic bullet. Who wants to create a well architected, well implemented, well documented product that has well educated people with a strong commitment to technology behind it anyway?

Everyone lied to you about DevOps. DevOps will not fix your problems.