VictorOps is now Splunk On-Call! Learn More.

The Fallacies and Truths of DevOps

Dan Holloran September 19, 2018

DevOps Collaboration
DevOps Fallacies, Misconceptions, and Truths Blog Banner

At its core, DevOps simply refers to an Agile, collaborative relationship between development and IT operations teams. But, the term DevOps and many of its core principles tend to be thrown around loosely and become misconstrued. It’s important that people understand the misconceptions associated with DevOps in order to realize the true value of it when implementing it on your own teams.

So, we’re laying out all the facts, debunking common DevOps fallacies, and focusing on the truly transformative tenets of DevOps. Here we’ll identify common truths and misconceptions of DevOps to help you guide business transformation, build faster, drive system reliability, and achieve success.

Top 5 DevOps Truths

A meaningful implementation of DevOps isn’t just one thing, it’s an aggregation of actions and principles. If there’s only one key truth you take away from this article, it’s that DevOps is ever-evolving.

People need a willingness to continuously learn, develop new processes and tools, and adjust their teams as new information comes to light–leading us quite nicely into our first DevOps truth:

A Desire to Continuously Improve

DevOps teams should always be focused on constant experimentation and improvement. There are a large number of areas for improvement throughout the entire software delivery lifecycle (SDLC). Software developers, IT professionals, QA engineers, and operations support teams all have a vested interest in an improved SDLC. From planning to deployment, including upkeep and maintenance, you’d be naive to assume there’s no way to improve.

Both CI/CD (continuous integration/continuous delivery) and incident management become easier as you iterate and improve processes, tooling, and workflows.

As long as everyone on the team remains open to new ideas, expresses interest in learning new programming languages, tries different QA techniques, or is willing to change team structures, then your team will continue to improve. DevOps is all about learning a lot, applying those learnings quickly, and continuously iterating.

Collaborate Better and More Often

Collaboration is a huge component of DevOps. Collaboration is helpful in any capacity, whether it’s about maintaining a CI/CD pipeline or it’s in reference to speeding up incident response and remediation.

Cross-functional teams need to have deep communication before, during, and after a feature release or incident. Successful DevOps teams will improve collaboration via real-time ChatOps tools, deep post-incident review reporting, and visibility into monitoring, alerting, and software delivery information.

DevOps Needs Organizational Buy-In and Support

In order to effectively implement DevOps at your company, you need to get buy-in and support from leadership. DevOps is typically implemented for developers and IT operations teams, but many of the DevOps truths can be applied across sales, marketing, and operations support teams. When teams adhere to DevOps principles and you get support from leadership, cross-functional teams collaborate better and you can get the personnel and financial backing necessary for business success. DevOps can’t be a siloed interest, it needs to apply across teams.

Automation, Automation, Automation

Anything from IT alert automation to automated software delivery needs to drive efficiency and make human workflow easier. Automation can be applied at nearly any stage of the SDLC. The key to effective automation is finding pain points in your incident management or software delivery process and baking automation in where you can.

Once you’ve identified SDLC or incident management pain points, you can focus on areas where you can automate deployments, alert payloads, alert routing, on-call rotations, or escalation policies. But in the end, automation always needs to be reliable and improve quality of life for your people.

Accountability, Code Ownership, and Transparency

Before the term DevOps was officially coined, many teams passed tasks and projects over a wall from person to person throughout the SDLC. This meant that product managers, front-end developers, platform engineers, IT professionals, QA engineers, etc. became siloed into their specific tasks within the delivery lifecycle and had little understanding of anything else.

A DevOps team will involve every necessary person, in every step of a project, from planning to deployment. This creates transparency into every step of the SDLC. As you work in smaller, collaborative DevOps teams, everyone takes ownership of the code they write. While working cross-functionally, engineers can see how the code they write fits into the entire system. Then, when engineers are given the responsibility to help maintain the code they write, they feel more inclined to focus on the overall reliability of the services they build.

DevOps teams that take responsibility for the development and maintenance of their systems gain a deeper understanding of the system, baking reliability into everything they build.

Creating a Culture of Reliability

Top 5 DevOps Fallacies

Now that we’ve covered a number of DevOps truths, let’s cover many of the common fallacies or misconceptions about DevOps:

DevOps is an Implementation of a Process or Tool

DevOps is not a tool, it is not a process. DevOps is a belief–it is the belief in the idea that collaboration, experimentation, and continuous improvement drives success. There is no singular tool or process that will make your team a DevOps team. Every team is structured differently, and there is no one-size-fits-all approach to building reliable software quickly. A person’s understanding and implementation of the core values of DevOps is the only tool that can create a DevOps culture.

Everyone Needs to Be a System Administrator and Developer

There’s a common misconception in DevOps that every single person on the team needs to act as a developer and IT professional. No single person can do everything. This idea that everyone needs to be able to code and rack servers is not accurate–especially in the era of cloud-based applications.

But, the team as a whole needs to have this experience. Even if you’re running cloud-based applications, having system administration experience on the team can help you handle any issues that may come up with your AWS or GCP infrastructure. Diverse expertise in your DevOps team can help you set up proper monitoring tools, backups, runbooks, and security policies. In a DevOps team, both SysAdmins and IT professionals can easily collaborate with developers to identify any potential issues in the code or infrastructure.

Over time, everyone on the team becomes more knowledgeable about writing code and maintaining infrastructure. With this diversity of collaborative skill sets built into one DevOps team, incident management and software delivery suddenly becomes much faster–feeding a reliable CI/CD pipeline.

DevOps is a Specific Role

Some organizations have engineers with titles like “DevOps engineer”. But DevOps isn’t a specific role. Similar to our previous point, you can’t expect every person to have deep expertise in every single area of the SDLC.

In a previous post about hiring for DevOps, we discussed the concept of hiring a T-shaped person. Developers and IT engineers in a DevOps team need to have a wide breadth of knowledge, but also be highly skilled in a few specific areas. By building small teams of people with complementary skills, you can cultivate a culture of reliability and collaboration in the SDLC.

DevOps is only for Smaller Organizations

It’s a misconception to think that DevOps is more difficult to implement in larger, enterprise organizations. For some reason, people have this belief that it can’t be applied, or that it’s ineffective in larger companies. But, organizations large and small can always find innovative, unique ways to adopt DevOps.

Every company grows differently and organizational structure changes. Identifying weak points in workflows and processes can help you start to address how DevOps should be implemented in your team. For a great example of DevOps being used in a larger organization, check out Spotify’s Squad Framework.

There’s One Specific Process for DevOps

As with many of our other DevOps fallacies, there isn’t a one-size-fits all process for implementing DevOps. There are so many variables when implementing tools, building teams, and establishing processes that you can’t assign one way to do it.

Whatever process you determine for cultivating DevOps, make sure it focuses on continuous improvement, collaboration, accountability, and automation.

DevOps plays well in both the SDLC and the incident lifecycle. Learn more about DevOps and the incident lifecycle by downloading our free eBook, How DevOps Plays Into the Incident Lifecycle.

Or, if you’d rather go at it yourself, sign up for a 14-day free trial of VictorOps to start building DevOps into your own incident management workflow.

Let us help you make on-call suck less.

Get Started Now