What is DevOps?

It seems the term “DevOps” is self explanatory.  Which Means integrate development with operations. Yet ask several people what DevOps is and you will likely get many answers. Some view it as a part of a company’s culture. Others see it as a development methodology. Some might consider it a movement, or even something tp encompass all these things. Regardless of how one tries to define it, there are crosscutting features that make up what we call DevOps.  Let’s have a look.

  • What is DevOps?
  • How did DevOps Come to Be?
  • What Challenges led to DevOps?
  • How do Agile, SRE, and DevOps Relate to Each Other 
  • How Does a Team Implement DevOps?
  • Who Uses DevOps and Why?

What Is DevOps?

Patrick Debois came up with the term DevOps in 2009 by combining the “development” with “operations”. If we consider neither of these combined terms are a technology or standard, it becomes easier to see how DevOps as a culture or movement is a sensible way to understand what it is. The decision to meld development and operations teams is considered a cultural aspect of an organization. When looking at the increase in popularity and rate of adoption of DevOps approaches, it is appropriate to consider it a movement.  At the same time, there are a range of technologies that support DevOps. That combined with the roles of the developers and operators is the DevOps environment.  Any wonder why it is hard to pin down a single definition for DevOps? Still for the purpose of this article, let’s consider the following:

DevOps is a systems-oriented approach that emphasizes communication and collaboration between development and operations teams. It leverages agile/lean development practices and automation technologies to manage the lifecycle of an application and its environment (infrastructure).

While not explicitly stated, the goal of DevOps and a primary reason behind its growth in popularity, is that a DevOps culture/process shortens software development time to value. This is done by using short feedback loops to accelerate to cadence of releases.

How did DevOps Come to be?

While a search for “DevOps” manifesto will come up with company-specific documents or individual proposals. However such a thing does not, in fact, exist. Although Debois coined the term in 2009, there was no one great meeting of minds that created DevOps as a thing. It can be considered to have sprung in large part from Agile development (which does have a manifesto) and the Agile focus on identifying shortcoming of software and rapid iteration to improve or fix it. This “Dev” approach extends to encompass the entire application support system. In this regard, enterprise systems management plays a significant role in the infrastructure/operations side of DevOps. The influence of ESM can be seen in DevOps configuration management, monitoring and automation.

What Challenges led to DevOps?

Developing and running software are strangely at odds with each other. Software users want change. This consists of new features, improved features, fixed bugs and that leads to the need for continuously changing software. Software users also want reliable services. Such as fast access, no outages or crashes. Operations managers traditionally provide this reliability finding a solution that works and then avoid change to provide stability.

On the Dev side, there is an understanding that pushing out code quickly is the target. On the Ops side, avoiding change has been the traditional approach to deliver reliability. The division of concerns was frequently referred to as a wall that developers would toss their code over for the ops side to deal with. DevOps came about to find a way to solve this very real challenge in a harmonious way. By closely integrating all the stakeholders and opening communications, requirements for Dev and Ops could be addressed as part of the whole. The integrated team could now view the entire lifecycle as their responsibility. As well as work together to provide both rapid delivery and operational reliability with much greater efficiency.

Bring teams together that integrate development and operational members is often more about communication and collaboration than a specific technology set. Some characters of effective DevOps teams include:

  • Clear expectations and priorities and where these are derived from
  • A culture of collaboration, communication and sharing within and among teams
  • Embracing automation to reduce human error and free up time for high-value activities.
  • Granular testing to provide rapid feedback at the application and infrastructure level

How do Agile, SRE, and DevOps Relate to Each Other 

As you explore the world of DevOps you will often see terms such as Lean/Agile and SRE in the mix. Agile and Lean are approaches to development that emphasize fast feedback and short development cycles. They are very explicitly a cultural or mindset approach to development rather than a specific toolset though tools that support CI (Continuous Integration) processes are important. DevOps is the culture or mindset that drives the collaborative process and ensures cross-boundary communication.  System (or Site) Reliability Engineering (SRE) applies a software engineering methodology to operations through automation. This is where continuous monitoring and CD (Continuous Deployment) are key. Especially in cloud systems, this becomes an “Infrastructure-as-code” approach where infrastructure development very much begins to resemble software development.

How Does a Team Implement DevOps?

How a company or team’s DevOps implementation will look will be unique. However, there are still going to be commonalities. A successful DevOps culture will eventually include clear methods of collaboration, employ automation, implement CI/CD processes, employ systems monitoring, and rapid remediation.


This is key to a successful DevOps culture. Communication between operation, developers, product owners, executives, and anyone else that is a stakeholder is key. The lack of communication is a primary driver for the creation of DevOps. Many successful DevOps practitioners go as far as to implement “no blame” policies for understanding when things go wrong. This assures that communication remains free and issues can be both rapidly resolved and not repeated.


Automation is key to reduce human error (increasing the reliability that operations appreciates) and to free up time from repetitive, low-value tasks to allow more emphasis on providing value (the developmental velocity that the developer appreciates). 

Continuous Integration

Continuous integration (CI) is an essential part of Agile and servers both to accelerate workflows and enhance communication. When done correctly, CI encourages developers to merge the code that they are working on into a main “branch” frequently (ideally at least daily).  Doing so increases the likelihood of discovering conflicts and by keeping changes small, makes the resolution of such conflicts fast.

Continuous Testing (Unit and Integration)

Continuous testing used to be “over the wall” for developers, who would hand off code changes to a QA team. With CI/CD processes, there is an expectation that code is being merged into a master branch after being tested. This includes a unit test – does your code do what you think it should? – and an integration test – does your code play nice with the rest of the code? This is probably one of the key pieces of DevOps culture that gets ‘overlooked’ in the name of velocity, but can provide a huge road bump when code breaks and a large number of changes need to be reviewed. As part of a CI/CD process continuous testing makes sure that breaks are small and fixes are fast. 

Continuous Delivery and Deployment

The CD in CI/CD can refer to continuous delivery or continuous deployment. Both are the process of getting the software artifact built, tested and ready for deployment to production. In the case of delivery, this requires manual approval for release to production. A continuous deployment process is fully automated. Depending on where in the DevOps journey your team or company is, releases may occur infrequently (days,weeks, months) or as frequently as multiple times a day. Although the exact mechanics of CD vary, as described in the CI section, the model of small, frequent releases brings the benefit of small, rapidly repairable failures rather than large catastrophic ones.

Continuous Monitoring

Even with ample and appropriate unit and integration testing, the real world can bring unexpected surprises. Continuous monitoring of software performance and availability is key to provide stability in production. Though we are not going to get into the weeds of specific tools here, monitoring systems, integrated with CD tools can even automate remediation. In some cases this could be an automate ‘roll back’ to a previous release if the issue is application derived. Automation can also solve infrastructure related performance issues through server scaling and tuning.  

Who Uses DevOps and Why?

While some of the largest companies in tech (Google, Amazon, Netflix, Facebook, …) are well known for their leadership in using and pushing the boundaries of DevOps. Anyone in the software development business can implement it. DevOps, when viewed as the journey that it is, can be gradually rolled out. A team might adopt some Agile best practices, put communications expectations in place and gradually build out a fully automated CI/CD process. That process could then be shared with another team and eventually throughout the company.  Understand the benefits of DevOps is not just for the developers and operators. It is another cultural shift that needs to be recognized. DevOps provides faster time to value. Which benefits the bottom line that CFOs and investors care about. CFOs will further appreciate the granular testing and systems monitoring will assure efficient resource use. Customers will appreciate the faster cadence of software improvements and increased reliability. 

For the above reasons and more, DevOps improves company performance on multiple levels. In Puppet Labs’ “2016 State of DevOps Report”  a couple of key measurable benefits were called out:

Stability & Innovation :

“High-performing organizations spend 22 percent less time on unplanned work and rework. They are able to spend 29 percent more time on new work, such as new features or code.”

Performance Improvements & Stability :

“High-performing organizations decisively outperform their lower-performing peers. They deploy 200 times more frequently, with 2,555 times faster lead times, recover 24 times faster, and have three times lower change failure rates.”

Interestingly, the above points show t both the Devs, Ops and Business interests benefit. It is not just one or the other. While security is mentioned in the 2016 report, DevOps high performers spent 50 percent less time managing security issues, the 2019 Report focuses on it. 

Speedy & On Demand Deployment :

Integrating security deeply into the software delivery lifecycle makes teams more than twice as confident of their security posture.” “Firms at the highest level of security integration are able to deploy to production on demand at a significantly higher rate than firms at all other levels of integration — 61 percent are able to do so.”


Hopefully it has become clear that since the term DevOps was coined in 2009, it has become a win-win-win solution for all involved. It eliminates the traditional friction between Devs and Ops. It increases time to value as a benefit to both users and business managers and executives. 

This does not, however, come without hard work. As DevOps is put into practice by an increasing number of companies new best practices and anti-patterns will be discovered. As new tools develop, what the implementation side of DevOps looks like will also change.  The journey to DevOps success is transformational and will never end, only continue to get better.