Les origines du DevOps

avril 20, 2021

Noces rebelles – les origines du DevOps

DevOps est un ensemble de pratiques qui combinent le Développement (Dev) et les Opérations informatique (Ops). Il s’agit avant tout d’une culture issue de la fusion de principes de management, du développement traditionnel de logiciels, de processus de gestion d’infrastructure et d’outils qui augmentent la capacité d’une organisation à fournir à un rythme intense des applications et des services.
Faire travailler ensemble tous les services IT, est un concept qui peut sembler évident. Mais la réalité s’avère plus complexe à mettre en place pour une raison, elle, très simple : traditionnellement, Devs et Ops fonctionnent chacun en silos et ont des rôles et objectifs diamétralement opposés. Plus simplement, le DevOps est né de la volonté de réconcilier ces deux camps devenus opposés. Pour mieux comprendre il faut déconstruire cette tragédie en 3 actes, menant à la rupture Dev/Ops.

Des problèmes systémiques

Pour comprendre la notion même de DevOps, il faut remonter un peu dans le temps. Traditionnellement, l’organisation des services IT privilégiait une approche fonctionnelle, organisant les équipes en fonction de leurs spécialités – les administrateurs de bases de données, les administrateurs réseaux, les administrateurs serveurs, les Développeurs etc. Chacun dans des groupes différents, et pour rajouter à la difficulté, chacun ayant des objectifs diamétralement opposés.

Devs

Les développeurs se concentrent sur la réalisation des besoins de l’entreprise en matière de nouvelles caractéristiques et fonctionnalités ainsi que sur leur mise en production le plus rapidement possible.

Ops

Les opérations informatiques ont pour mission de fournir à leurs clients un service informatique à la fois stable, fiable et sécurisé, et par conséquent, cherche à tout prix à éviter l’introduction de changements susceptibles de mettre en péril la production.

“Practice the philosophy of continuous improvement. Get a little bit better every single day.”
— Brian Tracy

Le drame

Commence ici le drame classique, une structure en 3 actes.

Acte 1 – l’exposition (Set Up)

La scène commence au sein des Ops, occupé à maintenir les applications et infrastructure pour s’assurer que l’organisation continue à délivrer de la valeur à leurs clients. La routine consiste à devoir régler les problèmes dû à la complexité des applications, à la dette technique et aux hacks quotidiens. Bien sûre, la promesse est faite de régler le problème plus tard, quand la charge de travail s’allègera…

Acte 2 – Confrontation (confrontation)

Evidemment, les artefacts les plus fragiles, car les plus sujets à modification lourdes et toujours urgentes, sont aussi ceux supportant généralement les projets les plus critiques ou les systèmes apportant le plus de revenues. Et là, c’est le drame. Un bug, un système down, des retards, un problème de sécurité. Et pendant que les équipes Ops s’affairent à résoudre le problème, un Product Manager ou un CEO, un Commercial, arrive avec une idée lumineuse pour une nouvelle fonctionnalité qui résoudra sûrement tous les problèmes préexistant (peu importe la difficulté ou la faisabilité technique). Entre à nouveau en scène les Devs qui vont devoir trouver une solution rapide pour créer cette nouvelle fonctionnalité, relever les défis techniques et parfois prendre des raccourcis pour respecter les deadlines. Et le cycle continue…

Acte 3 – Dénouement – Résolution (climax)

Pas de dénouement heureux ici, le cycle fini par aboutir logiquement à des cycles de livraison rallongés, des résultats de déploiements moins fiable, des pannes, une plus grande résistance des Ops à tout changement, le traitement des feedbacks interne et externe se ralenti… Finalement toute l’entreprise perd de sa compétitivité et les équipes IT qui se sentent coincé dans un système qui prédispose à l’échec dans lequel ils se sentent impuissant et non reconnu. Demandez à n’importe quel administrateur système ce qu’il pense des joies du déploiement du vendredi soir, qui force toutes les équipes à travailler tout le weekend.

Epilogue – Calms down

Au cours de la dernière décennie, les évolutions technologiques et la transformation numérique ont impacté toutes les entreprises. La transformation numérique est pilotée par les interactions avec les clients, les partenaires et les fournisseurs, qui évoluent toujours plus vers le numérique. De nos jours, « Chaque entreprise est une entreprise technologique » et les application et infrastructure sont devenues des facteurs stratégiques clés de différenciation des entreprises.
Autant dire que les enjeux et la pression auxquels sont confrontés les équipes IT est immense.
Et là, entre le DevOps ! L’idée apparait pour la première fois en 2008 de la rencontre d’Andrew Shafer (software Développer) et Patrick Debois (sysadmin) à une session devenue célèbre de la conférence Agile de Toronto : Birds of Feathers. Fini les équipes de Développement et d’exploitation « cloisonnées », souvent fusionnées en une seule équipe où les ingénieurs travaillent ensemble du cycle de vie (build – test – release).
Au fil des années sont aussi apparus des Frameworks regroupant les principes de base du DevOps : CALMS, The Three Ways, Accelerate.

TAGS:

You may also like

DevOps & le Gaspillage Lean

DevOps & le Gaspillage Lean

DevOps adopte le même objectif que le Lean, à savoir réduire ou éliminer les gaspillages, et en informatique les gaspillages se...

Les pratiques DevOps

Les pratiques DevOps

DevOps est un ensemble de pratiques qui rationnalisent les processus de développement logiciel (Devs) et de gestion de...