What is DevOps?

The Accelerate State of DevOps 2021 report highlights the vast differences between high-and low-performing software delivery teams. For example (Google Cloud, 2021):

1. Throughput (p. 12)

• Deployment frequency: Elite performers deploy code 973 times more frequently than low performers.
• Lead time for changes: Elite performers have 6,570 times faster change lead times than low performers.

2. Stability (p. 12)

• Time to restore service: Elites have 6,570 times faster time to restore service than low performers.
• Change failure rate: Elite performers reported a change failure rate between 0%–15%, while low performers reported change failure rates of 16%–30%.

3. Reliability (p. 20)

• Elite performers are 2.1x as likely to report the use of SRE (Site Reliability Engineering) practices as their low-performing counterparts. But even teams operating at the highest levels have room for growth: only 10% of elite respondents indicated that their teams have fully implemented every SRE practice we investigated.

We have emphasized the importance of excellent software delivery in a recent blog post. Low-performing businesses must start making changes to stay competitive. But although recognizing that there are issues is a good start, how can a team begin to optimize their software development workflows?

DevOps is a potential answer to this question. With DevOps, teams can:

• Make software products that are secure, efficient, and bug-free.
• Meet the business goals of stakeholders.
• Continuously grow and adapt to industry challenges.

But what is DevOps, and how exactly does it work? This post covers the DevOps model’s fundamental ideas and its benefits for businesses.

What is DevOps?

DevOps is an operational approach that combines software development (Dev) and IT operations (Ops). Development and IT operations in DevOps form a continuous process called “The DevOps Loop.” This loop incorporates the following phases (Figure 1):

• Software development– plan, code, build, and test.
• IT operations– release, deploy, operate, and monitor.

Sometimes, DevOps approaches also incorporate quality assurance (QA) and security. The integration of security into DevOps is often called DevSecOps.

DevOps has emerged from agile development and aims to apply the principles of agile to IT operations, QA, and security. Furthermore, DevOps intends to connect teams to help them more efficiently meet business goals. Businesses that follow the DevOps model often merge their development and operations teams into one unit. At the same time, some firms choose to keep their teams separate and optimize their communication.

Kim, et al. (2021, p. vix) outline the current myths that challenge the application of DevOps:

• Myth 1—DevOps is only for startups
• Myth 2—DevOps replaces Agile
• Myth 3—DevOps is incompatible with ITIL
• Myth 4—DevOps is incompatible with information security and compliance
• Myth 5—DevOps means eliminating IT operations, or “NoOps”
• Myth 6—DevOps is just “Infrastructure as Code” or automation
• Myth 7—DevOps is only for open source software

How DevOps differs from traditional IT operations

Prior to the popularization of DevOps in recent years, software development, IT operations, QA, and security teams typically operated independently, and their responsibilities and skills were clearly separated. Independent and isolated teams are often called siloed teams in the software industry.

The gap between development and operations is illustrated through different levels (Hüttermann, 2012, p. xvi):

• The incentives gap is a result of different goals of development and operations.
• The process gap results from different approaches of development and operations how to manage changes, bring them to production, and maintain them there.
• The tools gap has its origin from the fact that, traditionally, development and operations often use their own tools to do their work.

Consequently, development and operations may often be depicted as two divergent teams collaborating sub-optimally.

While perhaps simpler and easier to conceptualize, the pre-DevOps approach to software development and IT operations was riddled with inefficiencies and bottlenecks. In a “classical” environment, the process of software development is sequential and rigid, with the stages coming strictly one after another. Each stage in this sequential lifecycle – be it planning, development, quality assurance, or deployment – is dependent on the previous one.

According to Cunningham, (1992), the waterfall approach solved the problem of “technical debt” in a software development initiative. The concept of technical debt (tech debt) originated because some developers used iterative development instead of waterfall development. Each iteration of a software module created only a partially correct deliverable associated with evolving requirements towards the end goal of a software delivery project. Subsequent iterations “appeared” to move the developers further away from the goal of a perfect final deliverable.

The waterfall method was mistakenly associated with apparently perfect requirements being formulated before the actual development and coding would take place with the end goal in mind. What has not been considered at that time was that by the time a waterfall method development had been completed with supposedly zero tech debt, the requirements changed and the gap between the ideal requirements and the final deliverable was very wide.

The waterfall model is a foundational example of a sequential process. Workflows that follow the waterfall model have a rigid structure, are planned from the beginning to the end, and exhibit weak communication between teams. The rigid waterfall model can severely hinder software development and delivery in a field that is as quickly changing and unpredictable as the software industry. Changes in project scope, unforeseen issues, and new feature requests can cause significant delays in development.

The weaknesses of classical workflows became especially evident when software firms started growing more prominent. Although appropriate in well-defined environments, classical approaches made scaling and growing exceptionally difficult. This situation has prompted businesses to identify more cost-effective and flexible approaches to software development and delivery, one of which is DevOps. DevOps, when boiled down to its essence, is about optimizing for maximum results by overcoming an environment of constraints.

“Some people fear that DevOps capabilities such as continuous delivery are incompatible with the checks and processes prescribed by the Information Technology Infrastructure Library (ITIL), a set of documented best practices for IT service management. In reality, ITIL’s life-cycle model is compatible with DevOps. Most of the principles defined by ITIL align very well with DevOps principles.”

— Sharma and Coyne (2015, p. 60).

How DevOps works and how it can help the enterprise

To make software delivery pipelines more seamless and efficient, DevOps unifies the teams involved in planning, developing, deploying, and monitoring software. DevOps blurs the borders between teams and allows them to collaborate more closely throughout the lifecycle of a software product through four main activities (Sharma and Coyne, 2015, p. 6):

• Develop and test against production-like systems,
• Deploy with repeatable, reliable processes,
• Monitor and validate operational quality, and
• Amplify feedback loops.

Rather than operate sequentially, teams that use the DevOps model work together to produce, deploy, and maintain products throughout the application lifecycle. This approach allows teams to respond to challenges faster and be better adaptable to changes in market conditions and customer demands. As an example, the first activity encompasses the DevOps concept SHIFT LEFT, shifting operations issues earlier in the software delivery life cycle toward development (Figure 2).

Where Can DevOps Be Used?

Any business that develops software can and should use DevOps. The DevOps model can apply to various industries: financial services, manufacturing, or video game development. DevOps is not specifically tailored to one sector – it can adapt and integrate into any software development workflow. DevOps is based upon a reference architecture that furnishes a pattern of proven solutions that adopt a suite of preferred methods and capabilities that accommodates people, processes, and technology (Figure 3).

What are the principles of DevOps?

The main principles of DevOps are (Sánchez-Gordón and Colomo-Palacios, (2020, June):

• Agility. DevOps encourages the release of application updates in short and frequent cycles. DevOps adopts this approach from agile development and related software development methods.
• Shared ownership. Teams typically assume accountability for areas outside their main specializations in environments that adopt DevOps. Software developers, as an example, can become responsible for the security of their code. Besides, teams often expand their skillsets to perform the functions of their peers.
• Collaboration. DevOps emphasizes collaboration and communication between involved teams. More closely connected, teams can operate as a single entity that serves a common goal.
• Automation. With automation, DevOps allows businesses to minimize the time spent on repeatable steps. The efficiency can dramatically accelerate application development, quality assurance, and deployment.
• Continuous learning. DevOps promotes a growth mindset in teams. Continuous learning improves adaptability, fosters innovation, and allows teams to react to mistakes and failures appropriately.

DevOps vs Agile development – what is the difference?

“DevOps is about fast, flexible development and provisioning business processes. It efficiently integrates development, delivery, and operations, thus facilitating a lean, fluid connection of these traditionally separated silos.”

— Ebert, et al., (2016, p. 94)

The software industry today is laden with buzzwords. “DevOps”, “agile development”, “CI/CD”–concepts like these can easily confuse businesses that have not yet adopted an agile approach to software development.

With that in mind, where should a business start on its way to DevOps? DevOps, as a concept, does not compete with agile development. Nor does DevOps compete with other software development methods or toolsets.

Instead, DevOps is meant to help businesses unite many different software development approaches in a single environment. Agile, CI/CD, orchestration, monitoring – all these are merely tools that a business can use to build an efficient, high-performance delivery workflow. With that in mind, DevOps can be considered an umbrella model that incorporates many smaller toolsets and concepts. CALMS is an example of a conceptual framework for applying DevOps (Figure 4).

Next steps

Before undertaking any major changes, understanding the process of software delivery and as well as the value proposition for software delivery is important. The practices of DevOps are also worth attention because they underly modern software delivery. Once the basics are covered, businesses can plan their transition to DevOps. At the same time, an enterprise can consider adopting software delivery simulation to significantly accelerate and facilitate DevOps adoption. Of course, if the team might benefit from a course offered by IBM, then this Introduction to DevOps course is a great place to begin.