A Brief History of DevOps and Its Impact on Software Development
Software development has been and continues to be one of our society's most important building blocks. Software development has gifted us with the mobile phones we use to stay connected, the rockets we send to space and a host of other great innovations.
As complex as these innovations become, the more complex and time-demanding the software that drives them becomes. In an attempt to make the entire software development process as efficient as possible, different approaches have been introduced. An example of one of these is DevOps.
This article will share a brief history of DevOps, from its early days and its impact on software development today. At the end of this article, you will learn what to expect next in the field of DevOps.
Before DevOps: The early days of software development
In the early days of computing, software was developed and maintained by a small group of specialists, often working in isolation from the rest of an organization. The development process known as “Waterfall” was slow, with teams spending months or even years building and testing software before it was ready to be deployed.
The Waterfall model breaks project activities into pre-defined phases, passing the project down from one phase to another. In the waterfall model, each phase depends on the deliverables of the previous one; as a result, each phase must be completed before the next phase can begin with no overlap.
The Waterfall model is typically divided into the following distinct stages:
Image source: Adobe
- Requirements gathering and analysis: This phase involves gathering and documenting the requirements for the project.
- Design: In this phase, the system architecture and design are developed based on the requirements gathered. The system design helps specify the hardware and software requirements, like what programming language would be the best, while defining the overall system architecture.
- Implementation: This phase involves the actual coding and development of the system or software.
- Testing: The system is tested in this phase to ensure it meets the requirements and is error-free.
- Deployment: The system is deployed and available to the end-users in this phase.
- Maintenance: This phase involves ongoing maintenance, bug fixes, and updates to the system.
Challenges with the Waterfall model
Although this Waterfall model has pros, like its ease of use and management, it is inefficient and has high risk and uncertainty. Some of the many disadvantages of the Waterfall model are:
- Lack of flexibility
- No room for errors
- Difficulty in dealing with changes
- No customer involvement
The rise of the Agile methodology
Recognizing the disadvantages of the Waterfall approach in building software, in the late 1990s, a new approach to software development, known as Agile, emerged to improve the software creation process.
Agile combats the rigidity of the Waterfall model by focusing on the clean delivery of individual pieces or parts of the software and not the entire application.
Launched formally in 2001, Agile looked to get new features into the hands of the users quickly by focusing on rapid iteration and delivery brought by emphasizing collaboration, flexibility and continuous improvement.
Teams were encouraged to work in short, iterative cycles, known as “Sprints”, and to continuously refine and improve the software they were building.
Image source: Krusche & Company GmbH
To practice agile effectively, its creators outlined the following guidelines in the Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
While there is value in the items on the right, we should value the items on the left more.
Agile significantly improves how we create software and offers advantages like:
- faster time-to-market,
- testing and superior quality,
- flexible priorities,
- risk reduction,
- project visibility and transparency, etc.,
It soon began to replace the need for the Waterfall model in the software development life cycle.
The History of DevOps
As Agile development gained popularity, a new term emerged to describe the practices and principles used to streamline the development and deployment process: DevOps.
To share the history of DevOps, below is a detailed history of DevOps timeline, listing all the defining moments and summarizing the contributions of key influential people from 2007 to 2019.
DevOps started in 2007 when Patrick Debois — an IT consultant, recognized that development (Dev) and operations (Ops) teams were not working well together. While the gaps and conflicts between Dev and Ops have always been unsettling to him, the constant switching and back and forth on a large data center migration project where he was responsible for testing particularly frustrated him.
One day he was deep in the rhythm of Agile development. Next day he was firefighting and living the unpredictability of traditional operations. He knew there had to be a better way.
The following year, at the 2008 Agile Conference, Andrew Shafer created a birds of a feather meeting (BoF) to discuss “Agile Infrastructure”. Andrew didn't think anybody would come, so he himself didn’t show up to his own meeting. Patrick Debois showed up, and went looking for Andrew because he wanted to talk about Agile infrastructure being the solution to get operations to be as Agile like the developers were. This was where DevOps got started.
In 2009, at the Velocity conference, John Allspaw and Paul Hammond talked about “10+ deploys per day - Dev and Ops Cooperation at Flickr,” and the idea started gaining traction. This talk made people notice what was possible by adopting these early DevOps practices. Also, in October 2009, Patrick, held the first DevOpsDays conference in Ghent, Belgium. It was described as “The conference that brings development and operations together.” This is where the term "DevOps" was first used. DevOpsDays is now a local conference held internationally several times a year in different cities.
In 2010, Jez Humble and David Farley wrote a groundbreaking book called Continuous Delivery that sets out the principles and technical practices that enable rapid, incremental delivery of high-quality, valuable new functionality to users using a technique called Continuous Delivery.
Through automation of the build, deploy, and test processes, along with improved collaboration between developers, testers, and operations, delivery teams can release changes in a matter of hours—sometimes even minutes—no matter the size of a project or the complexity. The book is over 13 years old, but it still has a lot of great concepts that helped changed a lot of people's thinking about how to perform software delivery in a continuous fashion.
Two years later, in 2013, Gene Kim, Kevin Behr, and George Spafford published The Phoenix Project, based on Eliyahu Goldratt’s book, The Goal. The Goal is about a manufacturing plant about to go under and what they had to do to bring it back to life. It is a story about lean manufacturing principles. The Phoenix Project is about an information technology (IT) shop in a company about to go under and what it took to bring it back to life. This story is about applying lean manufacturing principles to software development and delivery.
In 2015, Dr. Nicole Forsgren, Gene Kim, and Jez Humble founded a startup called DORA (DevOps Research and Assessment) that produced what are now the largest DevOps studies to date called the State of DevOps Reports. Nicole was the CEO and is an incredible statistician.
Through this research, she found that taking an experimental approach to product development can improve your IT and organizational performance and that high-performing organizations are decisively outperforming their lower-performing peers in terms of throughput. The research shows that undertaking a technology transformation initiative can produce sizeable cost savings in any organization. If you haven't read the most recent State of DevOps report, I strongly urge you to do so.
The DevOps Handbook was published in 2016. It was written by Gene Kim, Jez Humble, Patrick Debois, and John Willis as a follow-on to The Phoenix Project and serves as a practical guide on implementing the concepts introduced in that book. John Willis, by the way, worked at Docker and Chef back then, and is a DevOpsDays coordinator after being at the original DevOpsDays in Ghent 2009 with Patrick Debois. If you only read one DevOps book, this is the book to read. They looked at companies that have adopted DevOps and document what did work and what did not work. It's a great read.
2019 — 10 years of DevOpsDays
Come 2019, 10 years after the first DevOpsDays in Ghent, Belgium, 60+ DevOpsDays events were held in 21 countries.
Patrick Debois led DevOpsDays from its inception in 2009 until 2014, and then Bridget Kromhout became the lead in 2015. She is also the co-host on the very popular podcast, Arrested DevOps. If you don't listen to it, you should. She stepped down in 2020 but stayed on the advisory board of DevOpsDays with Patrick.
The individuals mentioned above are some of the major influential people in the early DevOps movement. They weren’t the only ones, but they went out and made a difference. They showed us how DevOps can be impactful.
Why is the DevOps History Important?
Knowing the DevOps History is important because DevOps was a grassroots effort started by people like Patrick Debois and Andrew Shafer, who just wanted to eliminate the roadblocks in software delivery and figure out how can development and operations work better together.
And as Damon Edwards, who co-hosted a podcast with John Willis called the 'DevOps Cafe', said it best in his talk on “The (Short) History of DevOps”:
- DevOps is from the practitioners, by practitioners.
- It’s not a product, a specification, or job title.
- It is an experience-based movement that is decentralized and open to all.
DevOps Impact on Software Development
The impact of DevOps on modern software development has been significant. The following are some of the key ways that DevOps is changing the way software is developed and deployed:
- Faster Time-to-Market: DevOps enables teams to deliver software quickly and efficiently, which reduces the time it takes to bring new features or products to market.
- Improved Collaboration: DevOps encourages collaboration between developers, testers, and IT operations teams, which leads to better communication and a faster resolution of issues.
- Increased Quality: By automating testing and deployment processes, DevOps reduces the chance of errors and increases the overall software quality.
- Greater Efficiency: DevOps automates repetitive tasks and streamlines processes, freeing time and resources for more important tasks.
- Better Customer Satisfaction: DevOps allows teams to respond quickly to customer feedback and make necessary changes, resulting in better customer satisfaction.
What next in DevOps?
DevOps is a constantly evolving field, and several trends and areas of focus are likely to shape its future. Here are a few things to keep an eye on in the world of DevOps:
- DevSecOps: The integration of security into DevOps practices, also known as DevSecOps, is becoming increasingly important. As software security threats continue to grow, organizations realise the need to prioritize security throughout the entire software development lifecycle.
- Artificial Intelligence and Machine Learning: The use of AI and machine learning in DevOps is on the rise, with the potential to automate more tasks and improve the efficiency of software development and deployment.
- Serverless Computing: Serverless computing is a growing trend in DevOps, allowing for code deployment without needing to manage infrastructure. This can help reduce costs and improve scalability.
- Site Reliability Engineering: Site Reliability Engineering (SRE) is a discipline that focuses on the reliability and scalability of software systems. It is becoming increasingly important in DevOps as organizations seek to improve the reliability and availability of their applications.
The following are the references used in creating this article: