In the IT industry, the term DevOps has been floating around in discussions for several years:
- We will hire a DevOps Engineer –
- We’re introducing a DevOps culture in our Company –
- By introducing DevOps in our company, we have reduced operational costs by x percent –
Discussions, discussions, but what is DevOps?
The story of a meeting
To answer this question, we need to go back to 2008. Until the day of the Agile conference in Toronto.
Andrew Clay Shafer – the current Vice President of Transformation at Red Hat – suggested that one of its sessions be called „Agile Infrastructure”. However, attendees of this noble gathering did not quite understand his intentions. The session did not take place due to a lack of interest. Fortunately, the Toronto conference visited independent IT consultant Patrick Debois. Today is called the Godfather of the DevOps movement.
A Conversation with Consequences
Andrew and Patrick met to share their insights and experiences. Patrick at the time was implementing a Data Center migration for the Belgian government. In this project, he was working with agile development teams on the one hand and unpredictable operations teams on the other.
He was undoubtedly between a rock and a hard place. He couldn’t have run out of topics to discuss with Andrew. It turned out to be extremely fruitful because it resulted in the formation of the Agile System Administration group. The group is still active. It organizes many interesting meetings, not only on technical topics but also on how to introduce DevOps to the organization.
The birth of DevOpsDays
Agile System Administration was the driving factor behind the IT industry’s first DevOpsDays conference in Belgium on October 30-31, 2009. The conference generated tremendous interest among developers, administrators, and managers. It has become the driving force behind many initiatives and individuals.
Projects like: Vagrant, Puppet, and Chef were created on its wave. Without them, it would be hard to imagine the world of programmers today.
So what is DevOps?
DevOps is a methodology. It draws heavily from methodologies such as Agile, Lean, and Kaizen. Its main task is to break down walls and establish cooperation between development and operations teams.
This greatly streamlines the process of delivering software to the customer. The software also has fewer bugs and is more responsive to the customer’s needs.
The main idea behind the creation of DevOps was to create interdisciplinary and conversational teams – Dev(development) and Op(operations), or DevOps.
DevOps methodology in a company – benefits
There is no shortage of benefits of introducing DevOps methodology in a company. Let’s list the most important ones:
Reduction in software delivery time
– DevOps assumes that software should be delivered in smaller but frequent „portions”. Additionally, the Customer should participate both in the stage of planning works (Planning, Refirement) and in the stage of accepting small parts (Demo) – thanks to that he sees the progress and can give quick feedback on a given increment, as well as on the whole solution.
Resistance to changes
A well-implemented DevOps methodology is not afraid of changes it likes changes. It is not afraid of crises.
This is what I wrote about earlier. My favorite benefit of introducing DevOps to an organization is setting a goal for the team – „proving” the product/change. The method of getting there goes by the wayside – the team organizes itself, chooses the technology, testing approach, etc. Thanks to this seemingly simple change, the so-called micromanagement can be easily avoided.
Breaking down the wall of responsibility
My second favorite benefit. What did it use to look like? A manager would go from department to department and ask who would fix an urgent bug in production. Subsequent teams said: it’s not my problem – move on. It’s frustrating, right? What does it look like in DevOps? The team is responsible for creating, developing, and maintaining the solution, meaning the problem is solved immediately.
It’s pretty obvious, but often overlooked. Repeated testing, releases of small portions of software, allows a large number of bugs to be discovered and fixed before release. Such bugs detected in production may turn out to be difficult and expensive to remove because just improving the process is often not enough. It must also concern data, which often turns out to be a complicated task.
My third favorite benefit. Each person in the team/company is aware of what is going on in the company or project they are working on. This is why we have a flow of knowledge both between departments and individuals. We build trust. And as Michał Szafrański, a financial expert and a famous blogger, says: Trust is the Currency of the Future.
To be called an organization that has implemented DevOps – a DevOps Organization – you must strive to meet six principles, which are:
- Customer-centric operations.
- Manufacturing with a vision of the end.
- Accountability from start to finish -> You did it, so keep it.
- Interdisciplinary teams.
- Continuous Improvement.
- Automation. Everything. Even as art for art’s sake.
After meeting these 6 points, a company can confidently say that it is DevOps. It is known that fulfillment is one thing, but you need to constantly develop and nurture these Principles.
So why DevOps?
For many years I have been trying to build just such interdisciplinary teams. Teams, that work according to the principles of DevOps.
When I decided to start building my organization, I didn’t even think about its name for a moment – I knew right away that DevOpsi would perfectly represent what we stand for. Our Mission, Vision, and Values.