What Is DevOps? Understanding How It Works and Its Benefits

Wondering what DevOps is all about? We will explain what it is, how it works, why it matters, and how it can help your organization.

What is DevOps?

DevOps is a practice that involves Development and IT Operations working together closely throughout the development process. This collaboration aims to enable faster deployment of reliable software products.

Gartner gives the following definition of DevOps:

“DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and it seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology — especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.”

The Origin of DevOps

The term DevOps was coined by Patrick Debois in 2009 and, as you can probably figure out, combines aspects of software development and systems operations. Developers and operators serve different roles in the software development lifecycle (SDLC). They naturally have unique priorities and, over time, have optimized their workflows and efficiencies based on those specific priorities.

Developers or coders care about releasing changes and new features, whereas the operations team is focused on stability and reliability. Coding is the developer's responsibility and, generally speaking, development teams are not focused on operational practices. By contrast, the operations (Ops) team manages new release deployment and how production services are running, focusing less on the actual code being shipped and modified. In short, developers are focused on delivering features, and operations care about reliability and performance. 

DevOps is a culture and set of practices designed to break down the barriers between coders, operators, and other teams within an organization. Having a more unified approach allows teams to share responsibility and ultimately build better services. DevOps creates a holistic view of the entire software lifecycle and improves communication by way of shared tooling and data insights.

It goes without saying that business requirements are always changing and customers expect frequent updates and value-add features. Amidst all that velocity and pressure, it can be difficult to strike the right balance between release frequency and service reliability. If developers and operators are not on the same page, it ultimately affects the end-user experience. 

DevOps, SRE, and Agile

DevOps and SRE are two terms often used side-by-side. Additionally, engineering organizations often talk about introducing the Agile methodology into their SDLC. The question is, how do the three practices relate to each other?

Agile is an iterative software development approach that helps teams work faster and easily adapt to new changes. 

DevOps is a practice that helps engineering organizations improve communication and collaboration across disparate teams within the software development lifecycle (SDLC). 

The DevOps concept originally emerged from a discussion on the drawbacks of Agile between Patrick Debois and Andrew Clay. It gained popularity following the 2009 DevOpsDays event in Belgium. 

What made the practice interesting and timely was that it represented more than just an attempt towards improved efficiencies across the entire lifecycle. It was a step towards a cultural change, a cross-department collaboration, and an ‘interlock’ between developers, QA engineers, and system admins. DevOps is often referred to as “a blend of Agile methodology with lean thinking”. 

SRE (Site Reliability Engineering) is about treating IT operations as a software problem. SRE originated from Google in 2003 with the goal of keeping Google websites available and reliable. SRE practices are employed to continuously improve service reliability.

At its core, DevOps and SRE are two very similar concepts, both working towards breaking down silos and establishing a blameless culture. The main difference between DevOps and SRE is that the former determines “what needs to be done”, and the latter determines “how it will be done”. 

The difference between DevOps and SRE can be summarized as:

• DevOps approaches problem-solving in a fluid manner, and SRE takes a more consistent approach based on established processes and playbooks. 
• DevOps is focused on increasing development velocity, adjusting reliability metrics as needed. SRE works with agreed SLOs based on user needs and expectation thresholds, and generally advocates less risk tolerance.
• DevOps focuses on the traditional development cycle and focuses less on modern practices such as chaos engineering.
• Both SRE and DevOps prioritize automation, but they apply it to different processes. DevOps seeks to automate the feedback between development and ops teams in order to speed up deployment. SRE aims to automate manual routine operations tasks in order to establish consistency and also to collect data insights with the aim to measure and improve over time.  

The DevOps Lifecycle

DevOps has become a crucial part of most engineering organizations. It influences every phase of the application development lifecycle where no phase is independent of the others. Each individual in development and operations is involved in nearly every phase of the project. 

Planning

The first phase of the DevOps lifecycle is to establish the scope of the project. Teams ideate on new features and capabilities that they want to add to the roadmap. They consider how their product aligns with business growth by conducting research to learn more about the end user. This can involve market research and surveying an existing customer base. This planning phase also provides the foundation for product design.

Development

After planning and design, the development phase begins. This phase includes all aspects of coding such as writing, reviewing, and integrating with other code and tools. 

During this phase, the team focuses on rapid development to maintain service quality and reliability. Teams use various tools such as Git to automate tasks and iterate in small increments via automated testing and continuous integration. 

Deployment

Deployment is the process of delivering the product to the end-users, generally referred to as production. This step involves deploying and configuring the final application code to the production environment. 

In a DevOps lifecycle, deployment is not a one-time process. Over time, end-user requirements change, and new features are added or modified over time. 

Operation

After deployment, the product must be maintained, monitored, and investigated if there’s an issue. That falls under the operations team and is a continuous process. In a DevOps practice, teams focus on system reliability, availability, and optimal performance with hopefully minimal errors.  Teams continuously work towards improving the system by identifying any issues, mitigating them before they impact the user experience. 

The DevOps Culture

So far, we’ve been talking about the technical processes of DevOps, but the cultural philosophy is just as important. DevOps extends beyond workflow automation and optimization. Actually, it starts with the people within an organization and requires a change in the way people work and collaborate. 

DevOps introduces the following cultural philosophy.

Remove Silos within the Organization 

The first and foremost pillar of a healthy DevOps culture is collaboration. DevOps seeks to remove organizational silos by helping teams share responsibilities and work towards a shared end goal or outcome. When engineering and DevOps teams work together with end-user experiences in mind, the agreed Service Level Objectives (SLOs) aim to measure how code is behaving in real-time and, therefore, how users experience production.

In organizations of any size, teams work on the same project, and each team tends to pull in a different direction. When no one is responsible for overseeing the “big picture” it can lead to confusion and potentially slower release frequency.

Implement Gradual Changes over Time

Business requirements continuously evolve, emphasizing a pressure to keep up with increasing customer demand. DevOps teams tackle this by implementing small and gradual changes. For one, small changes are easier to review and implement. What’s more, in the event that something goes wrong, it’s much easier to roll back, fix, and get back online. By implementing incremental changes, teams are in a stronger position to manage incidents quickly. One drawback to keep in mind is that a slower implementation approach may not be the best answer over time, especially in a competitive market.

Tooling and Automation

Teams responsible for DevOps use a variety of tools and adopt a fairly rigorous process with some automation in place. Tooling and automation standardize process steps and reduce toil for repetitive tasks. They also help to identify unexpected errors and performance degradation that directly impact the end-user experience. Often DevOps teams rely on a mix of monitoring. What this means is that they will leverage APM and Observability tools to alert on unexpected behavior in the code, which can then be acted upon or further investigated by the on-call or dev team. 

Many of these monitoring activities can be pre-configured based on what the team wants to ‘watch’ with it simply running in the background, or continuously watching for unexpected behaviour in production. This helps the engineering teams streamline the SDLC phases, making it easier to scale and meet user expectations and requirements. Additionally, by having shared processes and tools in place, organizations can operate efficiently, giving developers time back to focus on solving real problems vs. manual, time-consuming tasks. 

Failure as a Learning Opportunity

DevOps is about being proactive, and creating predictable situations, but failure (for example, failure to meet the SLO) is unavoidable. When teams embrace failure and use it as an opportunity to learn and grow, everyone benefits, especially end-users. DevOps is a journey, and for every team member, there is room to grow and improve over time. 

Monitor and Measure Everything

Last but not least, measure. In an automated system, measurement plays a critical role so that teams can make data-driven decisions. Real-time dashboards and reports tell you exactly how the service is behaving against key metrics such as Service Level Indicators (SLIs). Often, teams pay close attention when new features are deployed. Ultimately you cannot predict how your code will behave in production, so you must monitor closely in order to address issues as they arise. 

DevOps Best Practices 

Beyond the culture, teams need to employ best practices throughout the application lifecycle. Some of these practices are employed at a specific phase and some span several phases. 

• Continuous Integration (CI) is a software development practice in which changes are frequently integrated into the master code branch. 
• Continuous Delivery (CD) involves frequently deploying new versions of the application into the production environment. 
• Microservices architecture is an approach to design and build an application as a set of several small (or micro) services. Here, each service runs its own processes and communicates with other services via an interface. 
• Version control is the practice of tracking and managing changes in your code. It makes it easier for developers to manage revisions and review change history by making use of techniques such as feature flags (a toggle to enable, disable, and hide a specific feature in runtime).  
• Agile software development emphasizes team collaboration and customer feedback to make incremental changes via short release cycles.
• Infrastructure as a code involves managing through coding instead of manually managing and configuring the hardware and software. After defining the code parameters, developers run scripts to automatically build the infrastructure.
• Configuration management is the process of managing the state of system resources such as VMs (Virtual Machines), and servers. This allows teams to deploy changes in a more controlled way, reducing the risk of modifying system configurations. 
• Continuous monitoring and logging are having real-time visibility into the performance and health of a system by analyzing the log data. This ultimately helps teams better understand how changes impact their customers.

The Benefits of DevOps

According to the 2019 State of DevOps Report, the elite DevOps performers deploy code 208 times faster than low performers and 106 times faster time from code commit to deployment. Not only that, but the software quality is also higher with a seven times lower change failure rate. It also improves collaboration among teams, reducing inefficiency caused by communication gaps. 

The report outlines five main benefits of adopting a DevOps model:

• Improved development velocity and delivery 
• Improved software reliability 
• Easy scaling 
• Better communication and reduced silos
• Improved security 

DevOps Challenges 

In 2021, most organizations, large and small, have implemented DevOps models across their teams. Over the past decade, many organizations have faced challenges in adopting DevOps and posed the question of whether the problem is the culture or technology. The question was posed in the Puppet State of DevOps Report 2021, and the results indicated that it’s a combination of both culture and technology.

The report shows that DevOps challenges vary for teams on different evolution levels. For example, low-evolution teams face a mix of challenges, such as organizational resistance to change or lack of automation. Mid-evolution teams have clearer objectives, some level of organizational buy-in, and have begun to automate. 

The following table displays survey results from organizations that were categorized into low, middle, and high evolution teams. The results are shared as percentages of those organizations falling into the respective categories that agree that the following obstacles were a “challenge” they faced in their efforts to implement DevOps into their organizations. This research comes from the Puppet State of DevOps Report 2021.

What percentage of each team category reported facing the following challenges?

How do DevOps Teams operate?

DevOps promotes communication and reduces silos among teams in an organization. In this model, development and operations are no longer separate entities independent of each other. Rather, they are merged into a single team where engineers handle the entire SDLC (software development lifecycle) from development to operations. In some organizations, even QA and security teams are integrated with development and operations through the lifecycle. The skillset of these engineers is not limited to a specific operation, but they become experts in all phases of the life cycle.

DevOps and Security 

Historically, security had been an isolated phase in the development lifecycle. The security team reviewed software at the very end, and the software was then tested by a separate QA (Quality Assurance) team. This approach worked well when development lasted for months or years, and there was no emphasis on rapid delivery. Today, however, given that DevOps prescribes frequent development cycles (ideally weeks or days), old security practices are no longer sustainable. 

This has given rise to DevSecOps - Development Security Operations. The goal of DevSecOps is to integrate security at every phase of the SDLC from design to integration, testing, and deployment. This allows security to fix issues as they emerge when they’re less expensive and easier to fix. 

Patrick Debois, who coined the term DevOps, speaks in the favor of DevSecOps:

“I found a lot of similarities between DevOps and DevSecOps. The “say no” mentality was very predominant in the Ops and security world. A similar mentality shift is happening, with security becoming friendlier, more focused on the people who consume their services. The scaling problem is similar in the way that the Ops person was outnumbered, and the security people were outnumbered by other groups. The narrative of “we’re here to help and rebuild trust” is also very similar.”

There are two schools of thought on the relationship between DevOps and DevSecOps. The first emphasizes that DevSecOps shouldn’t exist as a separate label. Security is an integral part of both development and operations. The second view upholds that labels are a powerful way to drive change and that the industry needs an explicit call to action such as DevSecOps to start including security from the beginning of SDLC. Regardless of where one stands, data from the DevOps report shows that DevOps has enabled better security outcomes.

How Can Blameless Help?

For engineering organizations, starting with DevOps is a journey. It starts with carefully considering where to begin, who to begin with, and how to structure teams. Blameless can make the process seamless for your organization and help to increase efficiency and communication. To learn more, check out the demo or sign up for our newsletter below.