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.

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.

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.

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.

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:

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.

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.

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:

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:

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.

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?

Try Bunnyshell today