As discussions, approaches, and practices only now begin to take flight, you might be tempted to think that the DevOps philosophy is quite new. In reality, however, this methodology first emerged back in 2007, when a frustrated consultant, project manager, and agile practitioner, Patrick Debois, got fed up with the separation between software development and IT operations and the inefficiencies it raised.
In this article, we explore the history of DevOps, from the circumstances that led to its appearance to its status today, and we’ll try to determine the exact moment DevOps became a thing.
History of DevOps – From the Early Years to the Present
The DevOps philosophy is actually not completely new, it has naturally evolved from the Agile methodology. The two have many similarities, which is why they’re not mutually exclusive – instead, DevOps and Agile can be used together for the best results.
What Was Life Like before DevOps?
Today, we take services like Netflix for granted. But what makes Netflix possible is actually the ability to make hundreds of deployments per day. Can you imagine a world where you can only deploy once a month, or, worse, once every few months? That was the reality for developers back then, in the golden days of the waterfall methodology.
The software was developed and tested for months before release. Leading up to the release date, QA was scrambling to test everything and send back defects, while devs were scrambling to fix bugs and send them back to QA faster than they could test them. The night before the release, QA and Ops would recommend the release date should be pushed back because the software is not production-ready, but the business stakeholders would dictate to stick to the original plan. The software is deployed and, in the next 12 hours, it would either be rolled back after everyone tried everything to make it work, or it would make it into production and, for the next weeks, the Ops team would do rolling restarts, hotfixes, and whatever they can to minimize impact. They will only manage to stabilize it in time for the next release. And then, the fun would begin again.
When Did DevOps Become a Thing?
In 2009, at the O’Reilly Velocity Conference, John Allspaw, Senior Vice-President of Technical Operations, and Paul Hammond, Director of Engineering, gave a presentation titled, “10+ Deploys per Day: Dev and Ops Cooperation at Flickr” – and the rest is history!
Through their talk, they made a case on why communication and collaboration between development and operations are vital, which sparked the appearance of what we now know as DevOps.
Patrick Debois identified with the situation the two were describing – developers and operation engineers pointing fingers at each other and passing the blame (“it’s not my code, it’s your machines!”), and, encouraged by others on social media, decided to form his own conference, “DevOps Days” in Ghent.
What Led to the Appearance of DevOps?
However, there’s more behind DevOps than just a historic talk and a conference. Other circumstances also had an impact, like “Lean Manufacturing” (also known as the “Toyota Manufacturing Method”).
Initially inspired by the ingenious assembly line methods introduced by Ford Motor Company, lean manufacturing’s goal was process optimization across the manufacturing floor. This methodology was centered around “Continuous Improvement” and encouraged practitioners to:
- keep inventory at a minimum (for both raw materials and finished products waiting to be shipped)
- minimize order queues – orders received would immediately move into fulfillment mode (the key metric was “order to ship” time)
- maximize efficiency in the manufacturing process – improved automation that enabled goods to be produced as fast as possible (each station for the operation was evaluated for inefficiencies).
Pretty similar to what DevOps is trying to achieve, right? If we also add the need for speed without compromising software quality (which led to the appearance of iterative methodologies such as Agile), the establishment of IaaS and PaaS as mature service offerings, and the emergence of “Continuous Integration” tools, you have all the ingredients for a DevOps recipe.
When Was the Term DevOps Coined?
Sometime between Allspaw and Hammond’s presentation and Debois’ conference, the term DevOps had officially landed in the history books. Officially, we consider the latter to be the first to use DevOps when referring to the relationship between software development and IT operations.
What Problems Was DevOps Trying to Solve?
DevOps aimed to maximize the predictability, efficiency, security, and maintainability of operational processes. As DevOps was meant to fix the inefficiencies raised by the Waterfall method, its goals were:
- lower failure rate for new releases
- faster mean time to recovery (in case a new release crashed or disabled the current system)
- shorter lead time between fixes.
Additionally, besides solving these problems, it also improved deployment frequency, a major benefit for tech giants like PayPal, Intel, or Facebook, for example.
DevOps integration targets product delivery, continuous testing, quality testing, feature development, and maintenance releases in order to improve reliability and security and provide faster development and deployment cycles. This is why it shares so many similarities with the Agile software development movement.
Organizations that implemented DevOps have also reported other significant benefits, such as:
- significantly shorter time to market
- improved customer satisfaction
- better product quality
- improved productivity and efficiency
- increased ability to build the right product by fast experimentation.
As the industry continues to improve, the proportion of highest performers has almost tripled, now comprising 20% of all teams.
We see that software speed, stability, and availability contribute to organizational performance (including profitability, productivity, and customer satisfaction), and top performers are twice as likely to meet or exceed their organizational performance goals. The use of the cloud, in particular, has a crucial role in ensuring high software delivery performance and availability.
The Bunnyshell Solution
We see DevOps as a journey, not a destination, so only time will show us how it will evolve. For now, however, we think automation plays a huge role in DevOps’ evolution, and DevOps automation tools, in particular, support its goal of achieving greater efficiencies.
Do you want to give DevOps automation a try?