Tech your facts: Five common myths about DevOps

If you’ve been in or around software engineering in the last decade, you're probably at least familiar with the term “DevOps.” The premise promises a leap forward in productivity and development velocity: The merging of “development” and “operations” into a cohesive entity. 

However, the original meaning and objectives have been lost in a cloud of buzzwords, hype, “No True Scotsman” fallacies, and lately even an obituary. Is it really dead, though? In this installment of “Tech your facts,” we examine some of the common DevOps myths and whether it still has some miles left on its tires.

While tools are an important part of the DevOps process, it's important to remember that they’re just part of the equation. The classic way to display the relative importance of different aspects of DevOps is as follows: People > Process > Tools.

It seems simple enough, but what does it actually mean and what are the implications? Does a software organization simply need more staff to successfully build a DevOps culture? Do tools not matter at all? Let's dig in a little bit and see how this concept plays out in real life.

Consider an engineering team (or an entire organization) that goes from right to left in that expression; they go all-in and invest heavily in the latest and greatest tools and platforms, but make no additional investment in people or process. They probably have a pretty capable technology stack now, but no one on staff that knows how to use it effectively, no definable process or procedures, and, most critically, they've done nothing to develop and build a strong DevOps culture.

One of the major philosophies of DevOps is the notion of "continuous improvement," making constant, small, incremental changes to improve software and software delivery. Not just making changes, either, but identifying where changes need to be made and fostering a culture that encourages this kind of dialogue. There isn't a single tool, software, platform, or framework that can be purchased that provides this level of cultural transformation. It requires a consistent, top-down effort from engineering leadership, non-technical stakeholders, and individual contributors to make it a reality, hence the emphasis on "People" over "Process" and "Tools."

Of course, that's not to say that tools should be totally ignored either. Better tools make the underlying objective easier. Using a cloud provider with Terraform will be much easier to scale and hire for than a legacy on-premise rack managed with CFEngine. Modern software development benefits from selecting the best tools for the job, but tools simply aren't the whole picture.

DevOps is often associated with large-scale enterprise environments, but it doesn't have to be for big companies only. Smaller teams can still capture plenty of value from DevOps with an incremental, strategic approach. What does this approach look like? Focusing on small wins with maximum leverage.

A small startup, for instance, is likely to be made up almost entirely of software engineers and product managers. A DevOps or infrastructure hire tends to happen in the later cycles of product/application maturity. So what small wins can a small engineering team have?

• People: Embrace a collaborative, knowledge-sharing approach. Engineers and non-technical stakeholders alike should all feel empowered to reach out across functional teams or organizations to make things happen. Teams having an "About Us/How to Contact" page available internally can go a long way to fostering this type of environment.

• Process: Focus on faster, incremental changes as a general philosophy. Making changes to code, process, or culture should be done with small units of change that are easy to tackle. Huge, sweeping changes are time-consuming and often end with bogged-down, incomplete changes. Teams that get good at implementing small changes quickly will find that will translate to improved DevOps success metrics.

Tools: Not having a DevOps engineer doesn't mean a small team can't take advantage of DevOps-focused tooling. Many cloud-based platforms offer managed services that provide a solid foundation for a more comprehensive DevOps scale-out further down the road. For example, using Docker containers as a build artifact with a hosted image repository like ECR or Container Registry gives an engineering team access to a fully managed artifact repository and lays the groundwork for a container orchestration implementation.

Another common DevOps myth is that it requires ripping everything out and starting from scratch; needless to say, this couldn't be further from the truth. That's not to say implementing DevOps requires no change at all; it is potentially a seismic shift in the culture and team composition, but that should never be an overnight change (remember to focus on incremental changes).

Focusing on people and process first means that massive technical changes can (and should) be sidestepped. The goal is to slowly introduce tooling that supports the ongoing cultural transformation as needed. This approach has the added benefit of making it easier to get buy-in from technical leadership as well; it avoids the massive up-front cost typically associated with doing broad refactoring and introducing lots of new tooling.

A great way to introduce some DevOps culture to software development workflows without being disruptive is with the addition of pre-commit hooks. This of course assumes that developers are committing code to a Git-based version control repository; if they're not, then changing that immediately becomes priority one in changing the development workflow! Git provides a feature called hooks, which fire off specific actions or scripts based on the occurrence of certain events (like a commit). Pre-commit introduces a standardized framework that makes sharing and distributing these hooks much easier. From their site:

"...We built pre-commit to solve our hook issues. It is a multi-language package manager for pre-commit hooks. You specify a list of hooks you want and pre-commit manages the installation and execution of any hook written in any language before every commit. pre-commit is specifically designed to not require root access. If one of your developers doesn’t have node installed but modifies a JavaScript file, pre-commit automatically handles downloading and building node to run eslint without root."

Checking for basic linting or syntax errors to prevent sensitive values from being committed or ensuring dependencies are versioned correctly are just some of the ways you can employ basic pre-commit hooks.

Enforcing these checks prior to code review saves valuable time for code reviewers, allowing them to focus on the actual logic and structure of the proposed change. If reviews are faster and more efficient, guess what: You've just improved deployment velocity and made an incremental change to your development workflow. As the team and system complexity grows, this can transform into a fully featured and automated CI/CD pipeline with testing and staging environments as well.

DevOps is a philosophical approach to software development and operations that seeks to optimize collaboration between what was once considered completely separate knowledge domains and working silos. With that in mind, DevOps should not be interpreted as a replacement for traditional roles like development, operations, or IT.

Having a culture of continuous improvement requires resources and attention across the entire engineering organization. DevOps is a framework that should be seen as complementary and additive to existing roles and responsibilities rather than something that replaces them entirely. Pick a DORA metric to focus on: Deployment frequency, essentially measuring how often a change is successfully deployed or released to a production-SLA environment. Now think about that metric in the context of the idea that DevOps will somehow replace some element of the engineering or operations staff. Does replacing any team directly produce the result of increased deployment frequency or velocity?

It's very unlikely. In fact, reducing staff is likely to result in decreased morale, increased burnout, and a significant increase in outages and other issues. A people-centric emphasis on continuous improvement means that existing teams should be given an opportunity to grow and develop their own technical and soft skills as the larger organization fully adopts the DevOps mindset.

Here we are, the heart of the beast, the numerous narratives that have taken shape lately.

• Developers don't want to "do" DevOps because it's too hard.

• DevOps is a legacy pattern that's getting replaced by the Platform Team.

• Cloud Development Kits (CDK) means developers won't need to work with DevOps engineers anymore.

These are all new and different ideas, but put quite simply: DevOps isn't dead by a long shot. How we think about DevOps and the best ways to achieve maximum developer productivity and happiness changes, but the core goals remain the same. Even if an organization goes all in on the platform engineering concept and developers are fully involved in infrastructure configuration via CDK, that does not mean that "DevOps" has died. The core philosophy and emphasis will always remain the same.

The inherent danger in tying the idea of DevOps to a specific tool or platform becomes obvious: Continuous improvement will always be important to software development, regardless of the tools being used. As evolving platforms continue to shape the landscape during this future of software engineering, DevOps will remain at the forefront of enabling fast deployments, ensuring quality engineering standards, scaling operations globally, improving security processes and more.

DevOps isn’t going anywhere. It's just evolving as software development and distributed systems evolve. The focus on continuous improvement and culture will always be at the center of a good DevOps initiative. Organizations and engineers alike shouldn't worry about DevOps being “dead,” or picking the right tool, or hiring engineers with the exact mix of skills.

The way to start is by making small, focused, purposeful improvements to your software development workflow and culture. Keep continuously improving, and your organization will reap the benefits of a very-much-alive DevOps.