Posted on 8 July 2019, updated on 23 January 2024.
The main principles of DevOps Culture
DevOps is the contraction of the words "Developers" and "Ops", but you probably already know it. The DevOps culture aims to break the gap between developers who produce new features, and Ops who aim for site reliability.
They had antagonistic interests as illustrated by Andrew Shafer in 2008 at a conference with a scheme that has become known worldwide: "The wall of confusion".
DevOps or continuous deployment culture
DevOps' objective is to break this barrier between Developers and Ops. This collaboration involves many actions that we will discuss later in this article, but the objective is always the same: to get developers and Ops teams to collaborate to achieve common objectives.
The objective of this collaboration, in the end, is to implement new features faster, without altering quality. This is called continuous deployment. This idea is illustrated by an essential concept of DevOps culture, the "feedback loop":
- I deploy my features;
- I operate on them;
- I get feedback;
- I fix and deploy new features.
It is therefore impossible to set up a DevOps approach if you are not listening to the user, and involved in continuously improving the products.
Where does the work of the developers stop, where does the work of the Ops begins?
This is the eternal question, when does the developer's area stop to give space to the Ops missions and tasks? Whatever the organization set up, whatever the principles of collaboration, we are talking about two different professions. Two different technical stacks.
Here are some moments when a blurry distinction between the 2 stations will play tricks on you:
- The production launch: heavy responsibility, the production launch may have a direct impact on your users and your business in the event of an incident. Is the developer responsible if the code is breaking the production? Does the Ops responsible since his priority is stability?
- The product code quality: the Ops provides the developer with test tools to check the quality of its increment. On the other hand, you shouldn't take away the developer's responsibility "I'm throwing out my code, the Ops will manage with it"
- Post-mortem: Each incident must result in a post-mortem, it is analyzed and corrective actions are taken. The Ops team runs the platform, and the developer has produced the code, who must take responsibility for this problem resolution, and for the actions to be held?
From a technical point of view, the question also occurs. Example: who manages the environment variables and how to ensure that they are secure but do not impact the development flow.
All these issues must be resolved. Everyone must know their role, their responsibility. The rules of the game will change over time, but they must remain clear and known (accepted) by everyone.
The history of DevOps
The Shafter conference in 2008 marks the beginning of DevOps.
In 2009, the first DevOpsDay conference was held in Ghent, Belgium. Created by Patrick Debois, an agile organization consultant. The DevOpsDays is then developed internationally and continues to be one of the pillars of the DevOps world with more than 30 conferences scheduled for 2019.
In 2012, the first report "State of DevOps" was produced by Alanna Brown of Puppet. A few months later, in 2013, "The Phoenix Project" was released. This short novel tells the story of an IT manager involved in a situation that seems desperate.
One of the keys to its success will be the application of lean and DevOps concepts. This book will greatly contribute to the spread of DevOps culture.
In 2019, according to IDC, the DevOps approach is a major trend in the IT organization, but DevOps still only concerns 20% of application projects. According to forecasts, this figure will rise to 35% or even 40% in 2021.
The advantages of DevOps
A DevOps approach will save you time. A lot of time.
A small example:
On one of our prospects' e-commerce websites, some products were displayed twice. It took 19 man-days of work for the internal teams to find the cause: a cron was running in two different places but was working on the same database. The Ops had the info "where the cron runs" and the developers the info "what the cron does".
From the moment both teams started working on this bug in the same room, it was fixed in 2 hours...
In general, DevOps will allow you to:
Accelerate launch times
According to the 2016 State of DevOps report, companies that have set up a DevOps organization have a deployment frequency 200 times higher and production times 2,555 times shorter (between the willingness to deploy and the production launch).
Reduce risks
As well as the collaboration of all parties, process automation will reduce the risk of failure. A continuous improvement process, key in DevOps, will thus make deployments increasingly reliable and fluid.
Accelerate the response to incidents
The automation approach set up by DevOps should help to better react to unavoidable incidents. Good communication between both teams (as in our client's example) will also facilitate this reaction.
Increase customer satisfaction
Having short deployment cycles and regularly bringing new features into production will mechanically improve customer satisfaction and your market relevance. Seeing their feedback taken into account and the product improving enhances their value solves their problems, and makes a difference with the competition.
How to implement DevOps in your company?
Plan time for collaboration
Do your development team(s) and Ops team(s) have time to collaborate? Or is it an additional burden that adds to the pressure of their sprints?
Some examples of ways in which time can be dedicated to this collaboration, and to facilitate the implementation of DevOps team and culture in the company:
Conception workshop tickets:
The conception of a new feature or the addition of new technology must be the subject of a meeting between developers and Ops. To do so properly, this workshop must be taken into account in the sprints of both teams in the form of an estimated ticket. Otherwise, you have every chance to do it in a hurry between two features, and you'll regret it later.
Training time:
Is the architecture designed by your Ops correctly used by your developers? Is the process simple for them, or do they lack technical knowledge? Especially if turnover is high in your technical teams, planning a weekly training period on the tools implemented can solve many problems.
User tests:
You're going to tell me "what does a user test have to do in the world of DevOps?". You are wrong. This vision can be annoying, but your developers are the users of the DevOps tools set up by your Ops, so make sure that these tools are practical and meet their needs.
Have common objectives
Another way to allow your Ops and developers to work together is to set common goals for them. This creates a virtuous circle where the successes of some are the successes of others, and where everyone has an interest in collaborating.
It is then necessary to set objectives with 2 measures, one coming from the "natural" objectives of the developers, and one from the world of Ops.
If you set an Ops "branded" objective, such as "the platform is available at 99.9% ", you can be sure that your Ops will fight against the developers who will compromise this objective by adding new features into production.
No matter how hard you try to onboard your Ops on the development roadmap, you have created a culture where infrastructure dominates the application. Set a delivery target, and you will get the reverse process with developers obsessed with features delivery that will make the life of your Ops hellish.
Example of objective: 1 production launch per week with 0 downtime of the application
It is up to you to manage the recognition and celebration you set up to motivate your troops, this enters the management field. But keep in mind that you are laying the foundation for a healthy and effective DevOps collaboration.
Develop customer culture among Ops
An Ops team is a transversal support team, which has its own users. Internally, for a large part of its tasks, an Ops team has "customers". You need to develop a customer service culture in your infrastructure team:
- Understand developer issues
- Adapt solutions to their needs
- Take into account their feedback
This requires a real dose of humility, and it is a change of mindset that will be very difficult to implement in many companies where the DevOps culture is not yet well implemented. Nor should we fall into a dictatorial and unhealthy mode of communication where developers use this "client" label to dominate the Ops team.
But developing a culture of service and customer satisfaction in your Ops team will allow you to improve the quality, the speed of deliveries, and communication between your Ops and your developers.
In a previous article, we gave you the different steps to align your Dev and Ops, to have a DevOps culture perfectly implemented within your company.
Relationship between DevOps and other organizational approaches
Agile: DevOps is often seen as a way to apply agility to the world of production. Agile development methods can reduce the distance between user needs and the development team. DevOps comes in addition to the agile methods, allowing the development team to quickly bring the new features into production.
We wrote a previous article with a little more detail about DevOps culture and especially how to adapt it to an Agile methodology.
ArchOps: Extension of DevOps starting from the software architecture and not the code for deployment operations.
DataOps: Application of continuous deployment and DevOps to data analysis. DataOps seeks to integrate data engineering, data integration, data security, and data privatization with operations (Ops).
Site Reliability Engineer (SRE): Site Reliability Engineering is an approach developed by Google in 2003, intending to continuously deploy new features while maintaining a high level of infrastructure quality and availability. DevOps and SRE cover largely similar issues.
WinOps: WinOps is the term used for DevOps practices centered around the Windows environment
In 2019, the DevOps approach is integrated into 20% of application projects in France. In 2021, forecasts put the number of projects using this organization at 40%. There is still a lot to say about DevOps culture, but this quick overview will allow you to lay the first foundation for this collaboration in your company.
If you would like more information on how to implement DevOps and what practices are adopted, feel free to browse through our other articles or contact us directly!