Even though it's considered a buzzword that has been discussed extensively in recent years, it seems like even experts struggle with understanding the complete meaning, let alone the significance of DevOps. As the portmanteau of Development and Operations, DevOps denotes a modern approach to these converging roles (along with QA) that is commonly associated with many benefits – but its definition, along with the adequate way of employing the approach, seems hazy nonetheless.
This article of our two-piece post series on DevOps aims to reduce the confusion and explain what DevOps is through its history, and inspects how it relates to Agile. Part 2 focuses on how to implement DevOps and some related practices and methods.
Related reading: DevOps Part 2: Methods, Practices and Tools
Moving Away from the "Siloisation" of Development and Operations
Back when releasing software meant creating a "golden disc" and then copying a few thousand or million copies, any small bug in the software could have catastrophic results. The basic objective of the Waterfall method was to counter this with thorough design and testing phases, in order to make sure the end product was flawless. As a direct result of the Waterfall method, the development stage of the SDLC was isolated from the operations part.
In today's web-based and mobile applications (and especially cloud-based solutions), however, deployment isn't such a big deal. Companies started deploying software often and early, and the resulting need for velocity gave birth to new (iterative and incremental) methods such as Agile to support the frequent release of software. Thus, with practically continuous deployment and development phases, the stages of development, QA and operations are increasingly converging; efficient collaboration between them is more and more necessary. In this sense, DevOps has come from the world of large companies such as Google, Facebook or Amazon.
However, there's another reason that may have promoted the surfacing of the DevOps movement, from quite the opposite direction: the Lean startup culture. Cash-strapped startups developing applications for a specific market need as fast and cost-efficiently as possible simply can't afford to maintain separate departments. Due to a lack of resources, if you're a developer in a startup company, you're most probably expected to take on new responsibilities such as those related to QA or system administration. Due to its perceived usefulness and efficiency, the notion of "multipurpose" developers started spreading from startups, and has gained traction with larger companies.
Now that we have identified the forces that have contributed to the emergence of DevOps, it's time to take a look at another basic question:
So just what is DevOps, after all?
Basically, DevOps means that developers and operators are working together closely on making sure the end product is reliable, and that as many potential issues are covered as reasonably possible. DevOps can be thought of as an approach, culture, as well as a set of values and principles, but it also consists of several tools, methods and practices that are instrumental to implementing this combined approach.
With Agile placing emphasis on the end user's expectations and experience of the product (what users actually want), developers have naturally started prioritizing these aspects of development, incorporating the quality assurance and operations approaches in their work. As such, this tight alignment between "Dev" and "Ops" (and QA that is traditionally in between them, as a responsibility of the operations team) can be regarded as an extension to Agile, which encourages close collaboration of all stakeholders during and following development. DevOps simply extends this to the part in the SDLC that follows delivery. Thus, the basic values that drive the DevOps approach can generally be considered similar to Agile's principles.
The merging of development and operations brings together formerly separate roles and teams, aligning their objectives. Traditionally, the development team aimed to include as many amazing features in the product as possible, while the operations team wanted to make sure the system was reliable and stable at all times. With DevOps, they share the goal of delivering a dependable piece of software that perfectly fits the requirements of the user – with the Agile terminology, we could simply call this "working software".
Similarly to Agile, DevOps should be more than just the implementation of practices or tools in a process – while using adequate methods and tools certainly helps, DevOps means the adoption of the above values and principles. The means to support these principles are secondary to adopting the concept itself on a cultural level.
The benefits offered by employing the DevOps approach throughout the software development lifecycle include:
- more frequent releases / deployment (faster time to market)
- lower chance of product failure once deployed (stability)
- faster time to recovery after unexpected events
- increased efficiency through automation
- maintainability (and scalability) of Ops processes.
In the next part of our DevOps series, we'll elaborate more on the tools and methods applied to help achieving "true" DevOps in an organization.