The difficulty of implementing DevOps in a company

"DevOps", that word, one can no longer see an IT job offer for infrastructure or development positions without it being mentioned. Many companies are turning to DevOps, ideas and concepts are mixed, the target is often blurred, while the objectives are clear, leading this transformation is therefore far from being an easy task.

This article is written in collaboration with Pierre Galdon, a SysOps engineer friend with whom I worked for several years.

There is no doubt that before arriving on this post you have read definitions, articles, perhaps participated or presented at conferences, in short you have your own idea on the subject. We don't presume to change your mind, that's not the point. We summarize here what we could learn from our experiences as spectator and actor of this major change in IT in recent years.

Why DevOps, and what the hell is it?

We will have heard "DevOps are methods, like agile", or "No, DevOps is the collection of tools, which allows us to automate", I (Pierre) believe that DevOps is all that and more. We will retain above all the definition of its objective.

The role of DevOps is to improve collaboration between development teams and production engineers. The principle is to increase the interaction between the two parties. From these interactions, the fruits are numerous: reduce time to market, increase team agility,... It also allows us to increase our skills together, by increasing the number of subjects to share, centered around problems faced together.

The goal is therefore to break down the barriers between the two teams / camps / clans, in order to produce applications (application + infrastructure) of superior quality, by unifying development and production practices.

Development and production: Two worlds that oppose each other?

This is probably the first concern, in an idyllic world, DevOps has only advantages. Unfortunately, often the expectations of Dev and Ops are not the same. Where a developer will deliver an application, which must meet business constraints, stability constraints, and possibly security (security by design is not yet widespread enough), an Ops must for its part take care of the observability, security, and reliability of the infrastructure and middleware that host the solution. On paper, no incompatibility to be expected. Yet very often, tensions are created, reducing the quality of the work, because the objectives given to the two sides of the team are too far away from each other.

Let's imagine the following conversation about an application:

"I've been asked to deliver the feature Too_good_2"

"We didn't anticipate the load from the feature Too_good_1, we need to stabilize the application"

It sums up perfectly what is described above: two seemingly opposing points of view, whose respective goals contribute to the improvement of the application. This is where it all comes into play, to succeed in reconciling the actors by offering them a rational, clear, and coherent discourse.

Motivating teams to work together rather than forcing them to do so

From my professional experiences, the model I have seen working for a DevOps collaboration is that of making teams aware, explaining to them why the company has chosen to move towards this model and the advantages it intends to draw from it. Forcing people to work together because it has been decided always creates resistance and reduces the adoption of DevOps methodologies.

It is important to raise the awareness of its teams because it is important to understand that some employees may have experienced other "miracle" methodologies before, and may not necessarily have fond memories of them.

The importance of leadership and exemplarity should not be neglected either. Motivated managers, who manage to set aside their ambitions for a healthy and productive collaboration, will certainly be your best argument to convince the teams.

Improve relations between Dev and Ops

For me, this point is a prerequisite to implement DevOps more easily within a company. It is necessary to create concrete exchanges between Dev and Ops. This can be done through multiple methods, such as, for example, in a non-exhaustive way:

• The "one team" mode, no longer talking about Dev or Ops but about feature team without necessarily making the distinction between the two, it allows to create a unity within the team.
• Set goals for both parties that can only be achieved by working together
• Organise workshops, either by an external service provider or by internal staff, on topics of interest to both sides.
• Organizing chaos day (I was talking about it a few months ago)
• If the teams are not located close to each other, it can also be useful to organize "safaris", making a Dev work in the open space of Ops for example, it helps to understand some of the issues that people may face.

A bit of team building doesn't hurt, organizing lunches, outings, afterworks, will make relations between colleagues more fluid, and make it easier to get in touch afterwards.

Don't do project scoping, because we're "agile."

I won't go into this often made amalgam between DevOps and Agile, but I often heard, when I was Ops and complained that the specs changed every two days: "we're agile, you have to adapt". NO, being agile doesn't mean doing anything anyhow anytime. NO, being agile doesn't mean having specs coming out of your hat every other day. On the contrary, this kind of specs can create frustration within teams and reduce the adherence that can be created between Dev and Ops.

All aspects must be taken into account in the framing of the project, regardless of the methods applied, and even beyond the framing, throughout the life of your applications.

In conclusion

The DevOps model can improve productivity within companies, the concern for me is that many companies have seen it successfully implemented at major players, and especially GAFAM, and wanted to impose it as it is, without necessarily taking their teams with them. The DevOps model does not impose strict rules that are identical from one company to another, but collaboration models. It is necessary to adapt these models to the functioning and history of one's IT department, and to disseminate them as clearly and concretely as possible, otherwise disorganization and resistance to change will set in.