Deconstructing the DevOps Hype

Daniel Brown // October 13, 2021


I’ve worn the DevOps hat for a couple of years now. So, I’m obviously a big fan and a true believer. But I’m very put off by how organizations compliantly jump on the DevOps bandwagon without truly knowing what it is or how it’s beneficial. When .NET hit, some of my peers mercilessly mocked Microsoft for ripping off Java. When Agile became a thing, I saw resistance to it. Have things changed so much in software development? What happened to all the obstinate naysayers that I know and love? Ideas aren’t meant to be mindlessly celebrated. Ideas should be fired in the crucible of skepticism. Only after this refinement process will we see the prime, most accurate, and tried ideas emerge as best practice. 

What is DevOps?   


Photo by Antonio Janeski on Unsplash

Why don’t I see more pushback against DevOps as a concept? Do organizations really believe in DevOps, or is it lip service to the prevailing philosophy? If they really believe, why are so many organizations still lagging in the adoption of DevOps? Maybe companies aren’t adopting DevOps because they don’t really believe. Maybe they don’t really believe because they don’t understand what DevOps is. Let’s dive deep into what DevOps is. Is it a methodology, a role filled by a person or team, or a set of tools or products? Is it a combination of best practices or a culture? I believe it could be several of these if looked at through different lenses. Let’s look at each way DevOps can be approached and added to organizations. 

DevOps as a Culture (The Holistic Approach)  

Maybe DevOps is a culture, doctrine, philosophy—a way of believing. Everyone in IT including development, testing, and operations comprises one entity. At its core, DevOps is about collaboration. The term “DevOps” is an amalgamation of Development and Operations. Pushing those two words together drives home the point that team silos no longer exist. All teams work closely together in perfect alignment. Us vs. them does not exist anymore. Every team member is responsible for the success of the whole process. Many of the philosophies of Agile and DevOps, such as rapid deployment, overlap making them perfect companions. 

DevOps as a Role (The Champion Approach) 


Photo by Leon on Unsplash

Many organizations see DevOps as a role that’s filled by a person or team of people. This approach positions DevOps team members as the champion of the philosophy. While members of the development and operations team need to work together, they are not responsible for instituting DevOps principles or filling the gap. The DevOps person or team tackles the transition to the new process. This approach mirrors the way many companies institute quality assurance and testing. If they want their code tested, they hire QA testers. If they want DevOps, they hire DevOps engineers. This approach can implicitly absolve other team members from responsibility for the success of DevOps.  

DevOps as a Tool (The Companion Approach) 

Companies that sell products, tools, or cloud services like to stress that DevOps is a set of tools or a companion to the development process. It’s easy for them to emphasize the need for tools because of the financial incentive for making a sale. Microsoft’s Azure DevOps doesn’t make money by encouraging teams to communicate. They make money by selling user licenses, test plans, build pipeline minutes, and artifact storage. These tools can be invaluable companions in a team’s DevOps journey. In fact, the explosion of cloud computing like AWS and Azure has made DevOps possible. By simplifying the setup of networks, servers, security, and monitoring, it’s eliminated some of the operations tasks like running network cable or agonizing over hardware purchases just to name a few. 

DevOps as a Practice (The Process Approach) 

Many organizations measure their DevOps progress with a process approach. They make sure they are doing enough things from the DevOps checklist. The organizations may not know why they are doing these things, but they are considered good practices, so they do them. Some of these practices may include:  

  • Agile Software Development  
  • Version Control  
  • Automated Testing  
  • Continuous Integration/Continuous Delivery (CI/CD)  
  • Microservices  
  • Infrastructure as Code (IaC)  
  • Configuration Management  
  • Monitoring and Logging  

Which approach is the correct approach?   

If I had to choose ONE, it would be DevOps as a Culture. Just like adopting Agile software development, the adoption of DevOps is a full mindset change for the whole organization. This adoption must have buy-in from the top and bottom of the team.    

But let’s be real. To be successful, DevOps needs to incorporate all these approaches into a complete solution. Creating a DevOps culture that doesn’t include DevOps practices would be a bunch of IT folks talking, but not doing anything. An executive can buy DevOps tools and hire DevOps, but this will achieve limited results without changing the way development creates and operations builds. DevOps without good tools might be a gnarly library of PowerShell or Bash scripts that are terrible to maintain and impossible to manage. DevOps practices can be implemented, but unless the team understands how they fit into an overall strategy, can these practices be expected to transform software delivery?    

Golden Ticket Fallacy 


Photo by

The lack of understanding about DevOps leads many to put it on a pedestal of ethereal greatness. Many managers, VP’s, directors, and C-levels executives see the DevOps paradigm as a golden automated ticket. Adopt DevOps, and productivity goes through the roof. Practicing DevOps will enable the rapid delivery of quality applications with fewer people. Here’s the plan for those jumping on the DevOps bandwagon without understanding what it is and the commitment necessary:     

STEP 1: DevOps  

STEP 2: ???  


But, here’s the truth: DevOps is hard. Automation might mean fewer people in the long haul, but it will probably mean more skilled and talented people in the short term. Despite claims by the countless DevOps product charlatans, no tool is going to magically fix the countless problems in a cluttered codebase and disorganized development team.    

Time must be allocated to teaching the team. Time must be allocated to realigning and building the new process. The continuous improvement idea entailed in the Japanese term kaizen should be an organization’s guiding star in implementing DevOps. Small iterative changes over time work better than completely replacing the current process in one quick move. The organization must trust the refinement process enough to watch it burn up man-hours and fail early on.   

Definition of Done 


Photo by Eden Constantino on Unsplash

How does one determine a definition of done for DevOps? When can an organization say, “We’re doing DevOps”? This is a tricky question. A software development process is not a static definition but a living thing. It’s a river that flows and continually changes as it winds through the landscape. There’s no arrival; it’s a journey where an IT Team must constantly adjust to changing conditions. However, just like a river, there’s a point of maturity in any process where the whitewater rapids and waterfalls upstream give way to a smooth, easy flow. This smooth part of the river could constitute a definition of done. I posed this question of “done” to some of my colleagues. I liked the answer that my esteemed colleague John Ruzick gave me. “Success in DevOps means that you have almost no human interaction in building, upgrading, maintaining, monitoring/alerting, and fixing your software environments.”  

  • If an army of Ops professionals needs to constantly stare at a dashboard to monitor the health of your servers, you’re not doing DevOps.  
  • If you’re manually testing, building, and deploying code, you’re not doing DevOps.  
  • If you don’t have environments that can be built, torn down, rebuilt, scaled up, scaled out, scaled-down based on changing conditions, you may not be doing DevOps.  

Make the team familiar with DevOps as a discipline. The book The Phoenix Project by Gene Kim is a good place to start. The team needs to really understand the principles to make it happen. Once they do, they can identify repetitive tasks, slow or tedious processes, single points of failure, and areas where automated auditing needs to happen. No quick fix exists for adopting DevOps. Don’t believe the hype; it’s not going to be easy! The adoption of DevOps means investing in hard work upfront to reap rich rewards later.  

To get help implementing DevOps in your organization, reach out to us.

Most Recent Thoughts

How can we help on your next project?

Let's Talk

Like what you see?

Join Us