The history of DevOps

Why this post?

This article is about the history of DevOps. I'll talk about all the people who gave birth to DevOps, and where and why the history of DevOps began.
If you want to get into this field it's important to khow the history of DevOps, and understand why DevOps?

The history of DevOps

Let start by the year 2003, Google hired Ben Treynor to lead engineers in production, separate from development. The new position for these engineers is called SRE (Site Reliability Engineering).
Her primary responsibility is to maintain uptime of services provided by Google, while working closely with developers to ensure that customers' operations are not disrupted by any outage by Google resulting in lost sales of their core products. Although the term had not yet been coined, SREs were the first true practitioners of what is now known as the “DevOps” philosophy.

SRE: Site reliability engineering is a set of principles and practices that applies aspects of software engineering to IT infrastructure and operations. SRE claims to create highly reliable and scalable software systems. Although they are closely related, SRE is slightly different from DevOps.(Wikipedia)

In 2007/2008 Patrick Debois, a Belgian project manager and agile practitioner, accepted a contract with the Belgian government to support the migration of its data center and was responsible for testing. His responsibilities require him to manage activities and relationships between the application development team and the operations team (servers, network, and database). The experience and frustration of a lack of consistency between the application approach and the infrastructure approach led to Patrick Debois becoming dissatisfied. His desire for a better way would soon be put into action.

In 2008 at an Agile conference in Toronto (Canada), a man named Andrew Shafer tried to organize a session called "Agile Infrastructure." When Patrick showed up for the meeting, he was the only one there, but Andrew received so many negative comments that he didn't show up for his own meeting. However, Patrick was there leading a session called "Using Scrum and Agile Practices in a Business Context" and he was so excited that others shared his frustration that he found himself in the conference hallway Andrew and had a long discussion that made me realize there must be others out there who want to discuss an issue that seems so pervasive and systemic.

They then formed a focus group to allow others to share ideas on how to bridge the gap between the development phase and subsequent operations. Their discussions and sharing of ideas with others promoted the concept of “Agile Systems Management.” That same year, Debois and Shafer established a group of agile systems administrators at Google, but with limited success.

In 2009, the birth of DevOps: Flickr's senior vice president of technical operations John Allspaw, and director of engineering Paul Hammond, leveraged their experience managing uptime at the world's largest photo-sharing site. They noticed that the operations team, responsible for managing the servers, and the development team, responsible for writing the code, always seemed to be at odds. The proposed solution, they said, was to hire "operators(ops) who think like developers(dev)" and "developers(dev) who think like operators(ops)."

The two Flickr employees gave a now famous presentation translated into French as “10+ déploiements par jour : coopération Dev et Ops à Flickr”. The presentation had an air of drama, as Allspaw and Hammond role-played the contentious interaction between development and operations representatives during a typical software deployment, as well as all the blame that occurs, such as: "It's not my code, it's your machines!" or " It’s not my machines, it’s your code!". Their presentation showed that the only rational way forward is for application development and operations activities to be transparent and fully integrated.
Over time, this presentation acquired legendary status. They proposed unifying development and operations into an automated infrastructure with a common version controller, including one-step build and deployment. At this time, DevOps was born, but it didn't have a name yet.

October 2009 – Present: Popularization of the term “DevOps”
Debois did not attend the conference presented by two Flickr employees in person, but chose to watch via video stream. Inspired, he decided to host his own conference called "DevOpsDays". To promote the conference on Twitter, he used the hashtag "DevOps" as an abbreviation for the words "development" and "operations." This soon became the name of the movement Allspaw and Hammond first expressed during the conference.
DevOpsDays begins in Belgium. The event will be held in Australia and the United States next year... As time goes by, more and more DevOpsDays are being held in different countries and cities around the world. There, developers and operations experts come together to discuss automation, testing, security, and the organizational culture needed to avoid premature conflicts. The personal meetings influenced more and more people about DevOps and eventually became an independent grassroots movement. At this point, the term "DevOps" officially entered the history books.

Conclusion

the term DevOps consists of the words "Dev" (development) and "Ops" (operations), and we can say that there are two teams here. The role of operations in business enablement is to create an environment in which all aspects of an organization work together smoothly to achieve the organization's goals. This includes a combination of efficient processes, effective technology and infrastructure, risk management, customer satisfaction, cost control, and the ability to adapt and expand as needed. Development teams play a critical role in enabling your business by creating and maintaining high-quality solutions. High-quality software that meets the needs of businesses and their customers.
In a DevOps culture, the collaboration between development and operations is key to achieving agility, speed, and reliability in delivering software solutions.