What Is DevOps? (And How To Set Your Organization up for DevOps Success)

We’ve seen DevOps progress from renegade movement, to trendy buzzword, to mass adoption. We’re now almost full circle: with some thought pieces and naysayers suggesting it might be time for Dev and Ops to part ways once more. We’re here to make the case for DevOps, and help you find your way to DevOps success—whatever that means for your organization.  

In this guide, we’ll take a look at the origins of DevOps, including its predecessors, and explore what DevOps actually means in practice: from the cultural practices to the technical elements and a typical DevOps toolchain. Then we’ll examine some of the reasons why DevOps implementation fails, and share some best practices to help you set your organization up for DevOps success.

Software delivery before DevOps

Whether you’re new to tech or have only worked in organizations practicing Waterfall or Agile instead, DevOps can sound intimidating to start with. Whatever your background, to understand this methodology it’s best to start with how software application development worked before the DevOps approach to software delivery. 

In the Beginning: Waterfall Methodology

Early on in software development, the waterfall approach was commonly used in getting software from idea to production. In waterfall, there is a linear, clearly-defined timeline of phases, from planning through to launch. Waterfall is orderly, without the need to coordinate among different groups, as each passes the baton forward at the end of their phase without much overlap. The drawback to waterfall is that a delay in any phase of development creates a blocker which can slow down the entire project. End users are also left out of the loop until the grand release, making it impossible to gather early feedback and iterate on the product or feature in real time. 

Enter: Agile Project Management

Agile software development methodology takes an iterative approach instead: breaking a project down into manageable chunks that create multiple opportunities to gather feedback and make adjustments to improve on the product or feature. Instead of one, big launch at the end of the project, you might ship a series of small releases that make gradual improvements with each iteration. Customers don’t have to wait as long to get access to highly requested features, and you can adapt to changing market conditions more nimbly. Another advantage of Agile is that you can identify problems and blockers earlier on. Agile is a collection of methodologies, bringing together Scrum, Extreme Programming (XP), and other practices. 

Agile does, however, stop short: the operations team is not traditionally included in an Agile cycle. Under Agile, developers write software, they might run some tests on it, then toss it over the fence to an IT operations team or system administrators, and hope for the best. Because the software engineers have very little exposure to or understanding of the production environment in which their code runs, releases are prone to errors, and the sysadmins on the other side of the fence lack insight into the code they are responsible for deploying, making debugging challenging. Development and operations are functionally and organizationally separate. Cue: delays, downtime, and poor user experience. 

Now: DevOps

DevOps builds on Agile. DevOps practices aim to address the inefficiencies and frustration that stem from a coordination between the development and operations lifecycle. Improved collaboration between development and operations teams enables speedier innovation and execution, an even tighter feedback loop between customers and the business, reduced operational costs and outages, better security posture, and a host of other benefits. If this sounds lofty and possibly too good to be true, you’re not alone. There are hundreds of resources championing the benefits of DevOps, but it can be challenging to implement and there’s no one definition or one-size-fits-all approach to DevOps at every company. So what exactly is it?

What is DevOps?

DevOps is a set of practices that: 

• Bridge the divide between software development (dev) and operations (ops).
• Streamline the software delivery lifecycle.
• Improve collaboration.
• Reduce the disconnect between the application code and the environment where it's deployed. 

DevOps principles emerged as early as 2006, in an interview with Amazon CTO Werner Vogels:

"Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service."

“You build it, you run it.” It’s a core principle of DevOps, which started to coalesce and solidify in 2007-2008, when more development and IT operations professionals called for a cultural shift to address the inefficiencies and dysfunction in the software development lifecycle. While Agile methodology improved on Waterfall software development by making it easier for teams to break down work into smaller, more manageable tasks and work iteratively, DevOps goes a step further. DevOps takes a cross-functional approach to building and releasing applications in shorter cycles and puts an emphasis on automation. There are two facets to the DevOps model: technical practices and culture.

DevOps technical practices

An overarching theme of the technical practices associated with DevOps is automation: reducing time spent on repetitive tasks and minimizing room for error. All together, these practices should simplify your processes and configuration, and unlock repeatability and scalability. 

These practices and the tools that enable them also help to improve visibility across teams and gather feedback on performance and user acceptance as you go along. 

DevOps practices and tools

We’ve outlined the key technical DevOps implementation elements below, roughly in the order they occur in the DevOps workflow:

While we’ve put these roughly in order, a key to understanding DevOps is knowing that none of these processes is truly linear. You will often see the DevOps lifecycle illustrated as an infinity loop: all stages flowing from one into another and looping back around again, demonstrating continuous improvement as you learn and apply feedback with each iteration. Some tools are vying to provide all these capabilities in one platform (for example GitLab and GitHub), but many companies will have a variety that make up their DevOps toolchain. 

A note on microservices

Moving to a microservices architecture is another key technical component of DevOps, even though it doesn’t fit neatly into the DevOps lifecycle outlined above. 
Monoliths vs microservices: It used to be common to build software applications in one, complex piece (a monolith). This meant that any small change to one part of the application required redeployment of the entire application. In a microservices architecture, the application is broken down into a collection of smaller, independent services that communicate with one another via APIs. Each service fulfills a specific business purpose. If you need to deploy a change that affects one microservice, you can do so independently of the rest of the application. 

Microservices add complexity to your architecture, but overall this approach enables flexibility and quicker innovation, which is why it’s closely associated with DevOps. Below are some of the benefits of a microservices architecture:

• Teams are free to choose the tools, libraries, and programming languages that suit the needs of the microservice for which they are responsible. 
• Your application is more fault tolerant because one microservice going down doesn’t necessarily impact the rest. 
• Horizontal scaling is possible as microservices can be scaled up or down independently of one another. 
• More frequent releases are unlocked, as teams are able to experiment with new features and roll back easily, since the change is limited to their microservice.  

Deconstructing a monolithic application into microservices is a hefty undertaking that requires careful planning to ensure your migrations don’t break anything and functionality is maintained for your users throughout the process. Monoliths to microservices is a substantial topic on its own; if you’re not sure where to begin, check out our blog post on Microservices: How to Know If You're Ready. 

DevOps culture

"It’s much easier to implement automation than it is to address issues with organizational dynamics that involve different teams, different managerial chains, and almost certainly require modifying processes that impact an even larger number of teams." —2021 State of DevOps

While automation is undoubtedly a hallmark of highly-evolved organizations practicing DevOps (the State of DevOps reported that 90% of such teams have automated most repetitive tasks), automation and other technical practices are just one side of the coin. 

Communication and collaboration between teams that traditionally worked in silos is a key tenet of DevOps. Some companies take inspiration from how open source projects operate, where small groups of volunteer contributors and maintainers work together, sharing information freely across different roles and domains. 

In a DevOps lifecycle, development teams no longer wash their hands of code once it goes into production, and in some organizations they may even own their product end to end. There is a lot more overlap between the capabilities and responsibilities of dev and ops team members. Developers might be on call and required to understand the IT infrastructure and provisioning for their code; site reliability engineers (SREs) need to know how to code. There is no room for territorialism:

"Gatekeeping is the mother of all anti-patterns in DevOps work and frankly in software in general … The fief-builder gets burned out because they get paged non-stop because Only They Know The Thing, and team members who aren't getting a variety of work will start looking for other places to be within or outside the company." —WN_Todd, r/devops 

DevOps encourages shared goals and a keen focus on the needs of the end user. This helps to prevent team members from retreating into silos and avoiding collaboration.

The benefits of DevOps

Done well, adopting DevOps processes could bring the following benefits to your organization:

Respond faster

Tighter feedback loops enable you to respond more quickly to incidents, vulnerabilities, and industry shifts. You’re also able to improve user satisfaction by delivering improvements and new features more quickly: by moving to a continuous delivery model, organizations can respond to roadmap requests and user feedback faster, in shorter iteration cycles.  

Better performance and reliability

With better collaboration between development and ops resulting in fewer things breaking in production, reduced downtime is another benefit of DevOps. Adopting continuous integration and continuous delivery practices ensures that changes are relatively minor and can be tested for functionality and safety before merging and deploying. Once the code is in production, monitoring and observability solutions help you to stay ahead of performance issues. 

Scale

With DevOps’ emphasis on automation practices, scaling is more achievable. For example,  Infrastructure as Code enables repeatable provisioning across teams. Moving to a microservices architecture enables horizontal scaling of each independent service. 

Improved security posture

With security integrated earlier in the software development lifecycle, and testing taking place as part of your CI/CD pipelines, security is no longer an afterthought. You may have heard of “shift left security” or “DevSecOps” in reference to this approach. Not only are you able to catch security issues earlier on, it’s less time consuming and disruptive to address them as they arise.

Why do companies struggle to implement DevOps?

For all its promises, DevOps hasn’t always delivered. Some organizations have been surprised to find the cultural shift harder than imagined, while others find that it’s challenging to put something into practice when the industry itself isn’t wholly aligned on what DevOps means or what it looks like in reality. Some leadership teams expect DevOps to be a panacea that will magically address all their poor policies and disorganization, resulting in happier employees and customers, without having to make any real, uncomfortable change to their workflows or development process.

Many software development professionals are disillusioned with DevOps, writing it off as a marketing ploy: something everyone says they do so they don’t seem left behind. We have to imagine that people start out on their DevOps journey with good intentions. Where does DevOps adoption go wrong?

Hiring a DevOps team, creating yet another silo

"If the goal is to remove those barriers between development and operations, make them really work together, one way or another, then creating a DevOps team is completely contradictory with that. It’s just another department."—Viktor Farcic, DevOps Paradox

This has been the approach for many companies: creating a whole new team to bring DevOps to the rest of the org. Unfortunately this usually goes one of a few ways:

• The DevOps team struggles to gain a foothold for their practices, effectively swimming upstream as the rest of the company continues with their old habits.
• The DevOps team becomes an intermediary between development and operations, facilitating handoffs.
• Your DevOps engineers spend the bulk of their time fielding internal support requests from development teams.

To gain traction and make a real difference, DevOps methodology shouldn’t be practiced by a single team, but rather woven into the practices of the organization as a whole. This is not to dismiss the idea of having a DevOps team altogether. Many companies find success by starting out with a single team (more on that below). What’s critical is that you don’t place the whole burden of implementing a DevOps culture on a single team forever.

Putting “DevOps” in front of job titles and changing nothing else

Similarly, rebranding your existing organization with DevOps titles (e.g. sysadmin → “DevOps engineer”) without making any other, tangible organizational or workflow changes does not facilitate improved collaboration between dev and ops. There’s no shortcut for it:

"Some of the original resistance to “DevOps team” or “DevOps engineer” was a reaction to the fact that many organizations believed that renaming an operations team or title was a shortcut to doing the hard work around collaboration, empathy for partner teams, and changing the way work happens. Perform a rename and voilà! Hang a “Mission Accomplished” banner."—2021 State of DevOps 

The State of DevOps report suggested that we may be past the peak of DevOps job titles and team names, and the authors strongly recommended retiring DevOps titles in favor of clearer team names with more clearly-defined responsibilities, to reduce confusion.

Thinking that DevOps is a tool you can buy

Which brings us to the next error. While there are definitely tools that make up a DevOps toolchain which help to facilitate version control, infrastructure as code, CI/CD, observability, and other DevOps elements (as discussed above), there is no single tool that guarantees DevOps success if your company is using it. From a discussion on the subreddit r/devops:

[inevitably] … some company makes a tool to productize a small part of the good idea to make it easier, and suddenly buzzword == tool. Then it no longer matters what the original idea is. If you are using tool you must be doing buzzword.—anatacj, r/DevOps 

If you’re using Kubernetes, or Terraform, or CircleCI, there’s a chance you are “doing DevOps” but using the tool is not enough on its own. DevOps is a set of practices, more than just what’s in your stack. 

Your team is resistant to DevOps

People may be skeptical for a number of reasons that make them reluctant to adopt a DevOps approach. 

Doubts about whether DevOps is right for your company

"The advocates—the people who were doing this kind of work and were talking about it—were all the digital darlings, were all the cloud-first, your Netflix, your Facebook, your whatever. So how many times, I can’t tell you, I’ve heard, 'Well that’s great, but we’re a bank.'”—Matt Stratton, Staff Developer Advocate, Pulumi, Arrested DevOps

People are jaded by unrealized promises

Your team members might have seen DevOps applied poorly or given lip service in previous roles, so they’re doubtful that they’ll see any meaningful change (“We’ve heard it all before”). 

Devs don’t want to do ops

Team members might just be reluctant to take on additional responsibilities that take away from what they see as their real work. 

"I do like to learn new things, I swear. But at work I want to focus on what I do best: feature development."—lmarcos, Hacker News

At smaller startups, team members are probably used to wearing many hats, but if yours is a larger org, it might be a challenge to get them on board. Bigger companies tend to see people in more specialized roles so you might have SREs who’ve never been exposed to Git, or developers with no networking experience. Asking them to suddenly own the product from end to end is a big leap which could be intimidating or just unappealing. 

"I hate DevOps. Mainly because I don’t want to do it. I liked it better when there was a dedicated infrastructure team instead of pushing it down to developers and giving it a new name."—irrational, Hacker News

This doesn’t mean DevOps is impossible or not valuable, but you may have greater success by implementing DevOps incrementally and focusing on empowering developers rather than burdening them (we’ll dive into this in How To Set Your Organization Up for DevOps Success below).  

Expecting DevOps to fix all organizational issues

Lastly, DevOps can do a lot, but it can’t magic away organizational issues such as poor planning, disorganized leadership, making the wrong hires, or disempowered team members. If the root of these problems isn’t addressed, DevOps can’t succeed and you risk having stakeholders write off DevOps altogether when it doesn’t fix everything. 

The conversation has circled all the way back to “Is it time for development and operations to be separated once again?” Trends are cyclical, so this isn’t surprising, but companies interested in the benefits of DevOps should not be discouraged. The reality is that DevOps is hard, but it can be done. 

"It’s hard to do it right ... By default you screw up. It’s how many times you screw up before you get it right. It’s a journey."—Sacha Labourey, Co-Founder & Chief Strategy Officer at Cloudbees, DevOps Radio 

Let’s dive into that journey. 

How to set your organization up for DevOps success

Whether you’re just starting out or starting over with DevOps, you have the benefit of others’ experiences to learn from. With more than a decade of DevOps successes, false starts, and failures to examine, other companies have paved the way or shown what DevOps antipatterns look like. Below are some best practices you can employ on your own DevOps journey. 

The key to all of the below guidance is to start small. DevOps has its roots in Agile, and for good reason: you can iterate your way to success far more smoothly and reliably than by ripping and replacing entire workflows. 

Get inspired by what others are doing

If anyone at your company falls into the camp of “Sure, DevOps sounds great but won’t work for us,” it can be helpful to see how similar organizations are adopting DevOps practices. If you’re a legacy bank, for example, and you see HSBC sharing their experiences at DevOps Enterprise Summit, it’s easier to imagine for yourself, and to sell it to your teams.

Try DevOps with one team first

This doesn’t mean creating one “DevOps team” that “does DevOps” for your whole company. Instead, consider running a pilot program with one team experimenting with DevOps practices so that you can learn, adjust, and optimize processes before rolling out to more teams. Make sure you establish metrics at the outset that will tell you if the team is getting the desired results. That way you will also have tangible wins to share when championing DevOps to other teams.

Shared goals over shared responsibilities

Many companies have tried DevOps by blending the roles of developers and operations professionals. We recommend an approach that focuses on improved collaboration and visibility between developers and operators, without merging the roles. 

My typical analogy is that DevOps should be removing the wall to replace it with a chain link fence and a gate. IMO, Devs and Ops should work closely while having differentiated roles. The empathy between teams is the real point—Andrew Gracey, Lead Product Manager, Cloud Native Edge on Twitter

DevOps is exemplified through that empathy between teams, and a shared focus on the needs of the end user. Everyone leverages near real-time feedback and iteration to inch closer to better performance, new features, and capabilities that meet those needs.   

Focus on empowering your teams with information

It’s clear that many developers are feeling that DevOps has just spelled greater workloads for them without feeling any real benefits. Instead of giving your devs full responsibility not only over their code but the production environment it runs in as well, prioritize giving devs access to the information they need. 

"They don’t want to configure everything, but they do want the information from those systems at the right time to allow operations and security and infrastructure teams to work appropriately. Devs shouldn’t care unless something breaks."—Nick Durkin, Field CTO, Harness, quoted in InfoWorld

In the event that something breaks in production, you don’t want a situation where the person who wrote the code knows nothing about the environment in which it runs. You also don’t want the person responsible for the production environment to have to know all the intricacies of whatever programming language the app was written in. The happy medium is where, in the event that something goes wrong, the person who can fix it knows enough to be able to ask the right questions and has access to the information that will answer those questions. This leads us to the next piece:

Invest in self-service

Platform engineering has emerged recently as a popular choice for replacing or evolving DevOps. A platform engineering team is dedicated to designing, building, and integrating the tools and workflows that enable self-service in your engineering org, particularly with respect to cloud computing services such as Kubernetes and Infrastructure as Code tools like Terraform. The result of platform engineering efforts is often referred to as an “internal developer platform.” 

Platform engineering can unlock DevOps implementation with less friction. 

"Rather than letting everybody operate everything and having to understand the entire toolchain to do so, platform engineers provide the glue to bind everything into a consistent self-service experience."—Luca Galante, platformengineering.org

What might this look like in practice? Your platform engineering team might set up and maintain your infrastructure provisioning, continuous integration pipelines, container orchestration, logging, or any other elements that make up your building, deployment, and operations processes. If this all sounds familiar, it’s because the outcome of successful platform engineering is the same outcome of successful DevOps adoption. Other teams are still responsible for their applications, but they can self-serve these operations via the platform. The benefits: automation of repetitive tasks and streamlining of workflows across teams, making it easier for all teams to build and deploy in a consistent manner. 

Spotify, an early proponent of platform engineering, shares how this practice has enabled self-service through their “Golden Paths,” their ideal and supported methods of building or doing something. They have tutorials that thoroughly document how to do something using the supported workflow and tools, effectively walking new team members through it, step by step.  

Platform engineering is one example of where a dedicated DevOps team can be useful: if they spend their time enabling self-service. In some companies, the “DevOps team” may actually be functioning as a platform team: creating and maintaining the tools and processes that enable developers to manage their systems in production. In some organizations this team might be called “Developer Experience.” Matthew Skelton and Manuel Pais of DevOps Topologies have words of caution, though:

"Although the outcomes of this dedicated team can be beneficial in terms of an improved tool chain, its impact is limited. The fundamental problem of lack of early Ops involvement and collaboration in the application development lifecycle remains unchanged."—DevOps Anti-Types

The takeaway: Investing in platform engineering can be hugely beneficial, but it doesn’t mean you can engineer your way out of cultural and organizational changes with an in-house developer platform. Platform engineering can only support DevOps success if you invest in the higher-level changes that support DevOps too.

Document technical and cultural best practices

In the example from Spotify above, technical documentation is a critical, impactful part of enabling team members. Whether the audience is internal developers or your end users, documentation of your processes or how a tool works needs to be woven into your DevOps lifecycle rather than tacked on at the end. Because of the short cycles and quick iteration in Agile and DevOps, documentation should be a living document, not something you polish after software releases. Streamlining your processes via an internal developer platform can help to reduce the amount of documentation needed, as there are fewer tools and unsupported paths to cover.

The 2021 State of DevOps report found a strong correlation between a business’s stage of DevOps evolution and to what extent they have a culture of knowledge sharing: 

"Like their high-evolution counterparts, at the higher end of mid-evolution overwhelming majorities report teams who share common tooling, language or methodologies actively share best practices with one another (85 percent high-evolution, 80 percent high-mid evolution), their organization’s IT infrastructure landscape is well understood by their team (85 percent high evolution, 79 percent high-mid evolution), and change management procedures ensure knowledge and information is shared with appropriate stakeholders (82 percent high-evolution, 73 percent high-mid evolution)." — 2021 State of DevOps

Equally important is documentation of your cultural practices, or how you work. This aspect of documentation is often overlooked but makes a big difference when it comes to onboarding new team members, scaling your DevOps practices, and expanding to other teams. New hires can be particularly helpful for pointing out processes that aren’t captured, often finding it easier to spot omissions than the rest of the team (who may be too close to tell).

Encourage questions

Doing things differently can be intimidating. It might be tempting to revert to old, familiar ways. Making a space for people to ask questions can help. Consider setting up pairing sessions for people to learn from each other: this could be between new hires and existing team members, or between people from different teams at different stages of DevOps adoption. Ensuring that people know who they can go to with questions can help to prevent teams getting discouraged and giving up.

Set inflection points to check in

We’ve said it before, but DevOps and Agile are closely related. Implementing DevOps is an iterative process, so you’ll want to set up checkpoints to review metrics, reflect on what’s working and what needs refinement, and document any lessons before kicking off your next sprint. 

Instead of thinking of your DevOps journey as a linear progression towards the finish line, you might think of it in terms of the DevOps infinity loop, iterating your way to DevOps success and continuously redefining what that success looks like, based on feedback and reflection. 

DevOps is not a goal, but a never-ending process of continual improvement.—Jez Humble, Founder and CTO, DevOps Research & Assessment

In conclusion

If it’s disappointing to learn that there’s no one right way to “do DevOps,” take some comfort in this: your DevOps success will inevitably look different than others’, but it is still a success. This is freeing, because while we’ve offered some guidance on the best way to get there, you get to define what success means to you. There’s a wealth of resources at your disposal to learn from others’ journeys, so you aren’t alone. Start small, iterate, repeat.