5 Problems with DevOps

DevOps has exerted a great deal of positive influence on the IT ecosystem since the DevOps concept was introduced more than a decade ago. Yet, despite all of the good DevOps has done, DevOps remains subject to a variety of problems. I don't mean problems with DevOps tools or technologies. Those exist, but they're not the main challenge facing DevOps today. Instead, I'm thinking about issues that afflict DevOps in a conceptual sense--problems that undercut or complicate the purpose of DevOps, and consequently make it difficult to translate DevOps philosophy into practice.

Here are the five main problems with DevOps as most organizations approach it today.

1. DevOps lacks a clear definition.

One of the main problems with DevOps is that the model remains somewhat ambiguous. Different companies and analysts have different definitions of DevOps.

Most DevOps definitions center on the idea that development work and IT operations work should be closely coordinated with each other. But there are important exceptions. Amazon's definition, for example, makes no mention of collaboration between developers and IT engineers. Instead, it defines DevOps as "the combination of cultural philosophies, practices and tools that increases an organization’s ability to deliver applications and services at high velocity."

Related:GitHub Universe 2020 Delivers New DevOps Features

I'd note, too, that few definitions of DevOps specify exactly how the collaboration between developers and IT operations teams is supposed to take place.

Does "doing DevOps" mean hiring a distinct team of "DevOps engineers" whose skillsets bridge development and operations? Or is it instead about teaching developers how to do IT work and teaching IT engineers how to program? Or maybe you're supposed to appoint "DevOps liaisons" who, although their primary responsibilities lie in either programming or IT operations, take the lead in connecting with the opposite team to foster a spirit of collaboration between developers and IT engineers.

Granted, you could argue that DevOps is ultimately just a philosophy, not a set practice, so it's up to organizations to implement the DevOps philosophy in whichever ways make most sense for them. That's reasonable enough. But it still leaves the meaning and purpose of DevOps somewhat ambiguous.

2. DevOps creates a false dichotomy.

Another problem with DevOps is that--to the extent that DevOps can be defined as a philosophy that encourages collaboration between developers and IT teams--it sets up a false dichotomy. The concept presupposes that developers know little or nothing about what IT engineers do, and vice versa, unless DevOps steps in and saves the day.

Related:Shift to Self-Service Platforms Highlights State of DevOps in 2020

This is a patronizing and simplistic view of the relationship between development and IT operations work. I've yet to meet an IT engineer who didn't know anything about coding. In fact, many IT pros I know who deploy and maintain applications are quite skilled at developing software, not least because they write, manage and update a lot of custom scripts to help with their workflows.

Likewise, I'm pretty sure most developers would be a bit offended if you told them they are totally ignorant of what IT work entails. They know what application deployment means, and which pain points IT engineers commonly face when deploying applications. They also know about logging and monitoring, which are important processes not just for managing applications, but also for troubleshooting problems that arise within applications.

Is software delivery better when developers communicate more efficiently with IT engineers, and vice versa? It surely is. But that doesn’t mean that, before DevOps, no sort of communication or mutual understanding between these groups existed.

3. DevOps lacks clear guidelines.

DevOps also faces the problem of a lack of clear and specific guidelines for determining how well you’re doing. It prescribes high-level concepts without specifying what they mean.

Take continuous delivery, for instance. “Continuous” is an ambiguous and problematic term. Does it count as continuous delivery if you deploy one new application release each week? Or do you have to be like Netflix or Google and deploy thousands of times per day? (Obviously, these companies aren’t achieving those numbers with a single CI/CD pipeline; they have lots of pipelines. But that’s beside the point.)

You could make a similar point about almost any other DevOps-related process. How many automated tests do you need to be running before you can claim to be doing QAOps? How many code commits add up to continuous integration, versus just plain-old integration?

Here again, you could object that DevOps doesn’t define specific guidelines or metrics because it’s a philosophy and not a rigid set of practices. That’s a fair argument, but it’s also one of the problems with DevOps because it can be taken too far. You need to draw the line somewhere between DevOps and not-DevOps, and most DevOps proponents don’t do a great job of that.

4. DevOps claims ownership over things it didn’t invent.

Even though DevOps doesn’t prescribe specific methodologies, the DevOps community as a whole has nonetheless closely associated itself with certain technologies. Microservices, which some deem “a natural progression of DevOps,” are one example. Another is containers and serverless functions, which are “built on DevOps principles,” or so we’re told.

The problem with arguments like this is that containers existed many years before anyone was talking about DevOps. So did serverless functions, if you place platforms like Zimki within that category. As for microservices, I tend to view them as the next stage in the evolution of the closely related--and much older--concept of service-oriented architecture, or SOA, rather than the technological offspring of DevOps. I suspect we’d have microservices even if DevOps had never happened.

From this perspective, DevOps can seem kind of haughty, which is a problem. It’s fine to point out how technologies like microservices and containers reinforce DevOps goals (however you choose to define those goals), but to say DevOps actually engendered those technologies is a pretty big stretch.

5. DevOps adoption is low.

One of the biggest problems with DevOps problem today is that, despite all the hype surrounding DevOps, the rate at which organizations are actually adopting it is low. That has been true year after year after year. Different studies find that, although a majority of organizations say they’d like to take advantage of DevOps as a way to speed software delivery, usually only half or fewer report success in implementing DevOps practices. The rate of DevOps adoption seems to be higher within smaller organizations, but that is counterbalanced by enterprises, which report lower adoption rates.

Maybe the day will eventually come when DevOps achieves truly widespread adoption. But we’re now more than 10 years into the DevOps age, and the adoption numbers are not quite impressive. This problem is rarely discussed within DevOps communities, probably because the DevOps world is something of an echo chamber, with companies that are already doing DevOps loudly singing its praises and paying little attention to those that haven’t yet made the switch.

Conclusion

Let me reiterate that DevOps is a powerful concept that has brought real improvement to the way some organizations deliver software. But as a concept, DevOps also faces some real challenges. It’s not very well defined, it makes caricatures of developers and IT engineers, it claims responsibility for technologies it didn’t invent, and it’s less widely practiced than many tech blogs would have you believe.

None of this is to say that DevOps is a failure, or should go away. Instead, DevOps proponents should have a more open conversation about the problems with DevOps described above. They are all possible to address, but not if the DevOps community continues to pretend they don’t exist.