DevOps : histoire & origines

Histoire et origines du DevOps

Historiquement, DevOps est né de la nécessité de briser les silos entre les équipes de développement (Dev) et d’opérations (Ops). Nous parlons d’un « mur de la confusion » entre ces deux équipes ayant des enjeux différents :

• Les développeurs veulent des changements rapides (livraisons de nouvelles fonctionnalités),
• Tandis que les équipes opérationnelles (administrateurs, ingénieurs systèmes, etc.) veulent garantir la stabilité des infrastructures.

Avant que le DevOps ne s’impose comme un concept à part entière, un mouvement vers une « infrastructure agile » avait déjà commencé à émerger. Alors que le développement logiciel adoptait des méthodes agiles pour améliorer les livraisons, des discussions ont débuté sur l’application de principes similaires à l’infrastructure et à l’exploitation.

L’histoire du DevOps remonte à 2008 lors de la conférence Agile de cette même année, où l’idée, bien que sans nom à l’époque, a commencé à prendre forme. La collaboration entre les développeurs et les équipes opérationnelles y était l’un des principaux sujets.

En 2009, le premier « DevOpsDays » a lieu  à Gand, en Belgique. Cette conférence organisée par Patrick Debois, souvent considéré comme l’un des fondateurs du DevOps, marque une étape cruciale dans la structuration et la diffusion du mouvement.

Plusieurs ouvrages ont ensuite contribué à façonner la philosophie DevOps, parmi lesquels : « The Phoenix Project » de G. Kim, K. Behr et Georges Spafford, ou encore « Continuous Delivery » par J. Humble, D. Farley.

La croissance rapide des technologies de livraison continue (Jenkins, Docker, Kubernetes), a soutenu et propagé la philosophie DevOps, rendant plus facile la mise en œuvre pratique de ses principes.

Pour découvrir notre chronologie détaillée de l’évolution du DevOps, téléchargez notre livre blanc :

Le saviez-vous ?

Lors de cette première conférence « DevOpsDays », un bug critique est survenu lors d’une démonstration en direct. Plutôt que de céder à la panique, les participants se sont rapidement mobilisés. Combinant leurs compétences, le problème a été résolu en moins d’une heure. Cet incident a illustré la puissance de la collaboration DevOps, démontrant comment développeurs et opérations peuvent surmonter ensemble des défis complexes.

Les principes fondamentaux du DevOps

L’approche CALMS est l’un des principes fondamentaux permettant d’intégrer pleinement la méthodologie DevOps. En combinant Culture, Automation, Lean, Measurement et Sharing, les entreprises favorisent une meilleure collaboration, une plus grande efficacité et l’amélioration continue dans le développement et la livraison de logiciels.

• Culture : rupture des silos
  Promouvoir un état d’esprit d’amélioration continue et de responsabilité partagée.
• Automation : automatisation des processus
  Rendre les processus reproductibles, fiables et rapides.
• Lean : optimisation du flux de travail
  Éliminer les gaspillages, raccourcir les cycles de feedback et travailler en « petit lots ».
• Measurement : mesure des indicateurs
  Analyser des Key Performance Indicators (KPI) fiables pour prendre des décisions éclairées.
• Sharing : partage des connaissances
  Renforcer la collaboration inter-équipes.

L’adoption de l’approche CALMS dans le cadre d’une transformation DevOps vise à s’assurer que l’organisation ne se concentre pas uniquement sur les outils et les processus, mais qu’elle prend également en compte les personnes, la culture et les pratiques de travail. C’est un cadre holistique qui, lorsqu’il est pleinement adopté, peut conduire à une livraison logicielle plus rapide, plus efficace et de meilleure qualité.

Le profil DevOps

Force est de constater que l’énigmatique « profil DevOps » est un sujet qui déchaîne les passions parmi les professionnels de l’IT.

À l’origine, le mouvement DevOps était une philosophie de travail et une culture. Cependant, nous avons assisté à un changement de paradigme ces dernières années avec l’émergence de profils dits « DevOps » (ingénieurs, intégrateurs, architectes ou encore experts, etc.). Ces profils doivent faire face à de nouveaux défis afin de répondre à des écosystèmes IT toujours plus complexes (conteneurisation, microservices, CI/CD…) dans un contexte de transformation Cloud & DevOps des organisations toujours plus important.

Grâce à ses connaissances Dev & Ops (avec une appétence plus prononcée pour l’un ou l’autre selon son background), le profil DevOps peut jouer un rôle déterminant dans la réussite de la transformation DevOps.

Il apporte le liant entre les équipes, ainsi qu’un niveau de technicité avancé sur les outils de l’écosystème DevOps.

En combinant les pratiques de développement logiciel (Dev) et les opérations informatiques (Ops), le profil DevOps améliore la collaboration entre ces deux domaines, accélérant la livraison de logiciels, augmentant leur qualité, tout en garantissant stabilité et fiabilité dans l’environnement de production.

S’il est vrai que le terme « Ingénieur DevOps » était superflu, voir fantaisiste il y a encore quelques années, il est aujourd’hui globalement adopté. Notamment grâce à des acteurs importants du marché comme Google, qui a joué un rôle phare dans la mise en lumière de DevOps (State of DevOps, Guidelines, DORA) et qui comporte une armée d’ingénieurs DevOps en son sein.

Les profils dits « DevOps » jouent donc un rôle majeur aujourd’hui dans la mise en place de ce mouvement. Véritables facilitateurs : ils sont le pont entre les équipes Dev & Ops pour diffuser activement les bonnes pratiques, acculturer et former techniquement les collaborateurs.

Les profils DevOps contribuent activement à détruire les murs de la confusion érigés entre les équipes de développement et opérationnelles ayant des enjeux différents.

Les défis majeurs du DevOps

L’adoption de DevOps, malgré ses nombreux avantages, est semée d’embûches. Parmi les principaux obstacles on retrouve :

• Obsolescence des outils : les entreprises restent souvent attachées à des outils anciens et dépassés. Ces outils, mal adaptés à la dynamique et à l’agilité qu’exige DevOps, peuvent ralentir les processus, nuire à l’efficacité des équipes et exposer les entreprises à de sérieuses failles de sécurité.
• Barrières organisationnelles : en dépit de l’ambition de renforcer la collaboration entre les services, les barrières et silos subsistent, entravant une interaction harmonieuse entre les équipes de développement et d’exploitation. Cette segmentation compromet la transparence et à la collaboration (le pan organisationnel étant souvent le plus compliqué à adresser).
• Automatisation incomplète : l’automatisation incomplète des processus empêche des déploiements réguliers et sans accroc.
• Sécurité négligée : une approche où la sécurité est reléguée au second plan est risquée. Intégrer la sécurité tardivement dans le cycle de développement peut compromettre l’intégrité de l’ensemble du système.
• Absence d’outils de mesure et de feedbacks : sans ces éléments, les équipes naviguent à vue et sont dans l’incapacité d’identifier clairement les domaines nécessitant des améliorations.
• Résistance culturelle : certains professionnels sont réticents à abandonner leurs méthodologies familières. Cette réticence est souvent renforcée par un déficit de formation et de compétences, laissant les équipes dépourvues face aux nouvelles exigences.
• Infrastructures inadaptées : même les équipes les plus motivées sont entravées par l’absence de plateformes et d’outils modernes. Sans infrastructures adaptées, leur capacité à travailler efficacement et avec précision est limitée.

Pour véritablement tirer pleinement parti de DevOps et garantir son succès, il est impératif de reconnaître ces défis et de mettre en œuvre des solutions pour les surmonter.

La charge mentale des développeurs, un défi de taille

La surcharge mentale des développeurs constitue un autre obstacle majeur à la mise en œuvre efficace de DevOps. Cela s’explique en partie par l’émergence rapide des technologies Cloud et la difficulté de jongler avec plusieurs environnements dans des contextes d’hybridation de plus en plus répandus. La complexité croissante des infrastructures exige une attention accrue pour gérer et intégrer une multitude de services provenant de différents providers. De surcroît, l’éventail d’outils et de structures à comprendre et maîtriser est immense, rendant difficile la mise à jour des compétences associées. De nombreuses équipes entament leur transition vers le cloud sans anticiper l’impact mental de ces systèmes et configurations complexes.

Les équipes peinent souvent à définir clairement les responsabilités, donnant lieu à une attitude contre-productive du type « confions tout aux développeurs », peu importe la tâche. On suppose que les développeurs doivent tout maîtriser, de Kubernetes à la supervision de leurs services internes. C’est cette pression qui contribue en grande partie aux déconvenues lors de l’intégration du DevOps.

L’idée de confier les opérations aux développeurs est séduisante, tant pour sa célérité que pour encourager l’initiative de groupe. Une solution envisageable consisterait à associer un expert DevOps à chaque groupe de développement pour superviser les infrastructures, garantissant ainsi une cohésion optimale et un suivi rigoureux des procédures et normes. La pratique émergente du self-service permet également de répondre à cette problématique. L’automatisation des composants d’infrastructure, les consignes, les balises, les audits entre pairs et les archétypes peuvent être harmonisés afin de respecter une ligne directrice. Cependant, cette approche repose fortement sur la rigueur des équipes et demande beaucoup de moyens. Des palliatifs ou des signaux d’alerte peuvent atténuer ces difficultés, mais il reste difficile d’anticiper toutes les variables et de se tenir informé des dernières méthodes et consignes.

Dans ce contexte flou, les développeurs doivent se préparer à toutes éventualités. Au-delà de traiter les requêtes d’assistance, ils sont parfois totalement immergés dans l’univers de Kubernetes, devenant ainsi des « clandestins » des équipes Ops. D’ailleurs, une tendance récurrente apparaît : la sollicitation continue des développeurs backend chevronnés pour gérer les aspects d’infrastructure. Cette situation leur laisse de moins en moins de temps pour programmer ou accomplir leurs autres tâches, impactant ainsi la performance globale de l’équipe.

Les différents patterns DevOps

À mesure que le monde de l’informatique évolue, la philosophie DevOps a introduit des « patterns » efficaces pour améliorer la collaboration et l’automatisation, ainsi que des « anti-patterns » à éviter, afin d’assurer des déploiements fluides et une meilleure synergie entre les équipes de développement et d’opérations.

Anti-pattern 1

Anti-pattern 2

Anti-pattern 3

Pattern 1

Pattern 2

Pattern 3

Vous l’aurez compris, la dimension organisationnelle des équipes IT est fondamentale dans une transformation DevOps réussie. Les modèles évoqués ci-dessus sont des leviers d’action essentiels pour démarrer cette démarche, cependant ils ne constituent qu’un point de départ :

Les leviers d’action pour réussir

Mesurer le niveau de maturité DevOps

Après avoir sélectionné le pattern DevOps adapté à votre organisation, il est essentiel d’évaluer la maturité DevOps de votre entreprise. Ce diagnostic permet de déterminer le niveau de progression dans votre transformation DevOps et d’identifier les périmètres nécessitant des améliorations.

Un outil couramment utilisé pour cette évaluation est le radar de maturité DevOps. Cet outil vous aide à visualiser les progrès et les lacunes à travers plusieurs dimensions clés, offrant une vue d’ensemble de votre démarche DevOps.

Le radar de maturité DevOps, illustré dans le graphique ci-dessous, est divisé en plusieurs segments, chacun représentant une dimension cruciale de la pratique DevOps. Ces dimensions incluent :

• la construction du bon produit,
• la livraison plus rapide de la valeur,
• la qualité supérieure des processus et déploiements,
• et l’amélioration continue de la culture.

Chaque segment du radar est noté sur une échelle, permettant aux équipes de visualiser leurs points forts et les domaines nécessitant des efforts d’amélioration. Par exemple, une entreprise peut constater qu’elle possède une forte capacité à livrer rapidement mais qu’elle a besoin de renforcer sa culture d’amélioration continue.

En utilisant un radar de maturité, les organisations peuvent établir une feuille de route claire pour leur transformation DevOps. Cela inclut l’identification des priorités immédiates, la définition des objectifs à court et long terme, et la mesure continue des progrès. Cet outil dynamique évolue avec l’organisation, fournissant des insights précieux pour un développement et une livraison de produits plus efficaces et de meilleure qualité.

En conclusion, le radar de maturité DevOps est un instrument essentiel pour toute organisation cherchant à évaluer et à améliorer ses pratiques DevOps. En offrant une vue d’ensemble des capacités actuelles, il guide les entreprises vers une transformation DevOps réussie.

Définir des indicateurs (KPI) DevOps

Pour évaluer l’impact des pratiques DevOps, il est crucial de définir et de suivre certains indicateurs clés de performance (KPI). Ces métriques offrent une vue d’ensemble de la santé des processus de développement et de déploiement, et permettent d’identifier les domaines nécessitant des améliorations.

Les DORA Metrics, popularisées par le livre « Accelerate » de Nicole Forsgren, Jez Humble et Gene Kim, sont largement reconnus pour leur efficacité à évaluer la performance DevOps.

En voici quelques exemples :

KPI	Description	Métrique
Temps de mise sur le marché (time-to-market / TTM)	Mesure le temps nécessaire pour déployer une nouvelle version.	Minutes, heures
Taux de réussite des déploiements	Pourcentage de déploiements réussis.	Pourcentage
Taux d’échec des déploiements	Pourcentage de déploiements échouant.	Pourcentage
Temps de récupération (MTTR)	Temps moyen nécessaire pour résoudre un incident.	Minutes, heures
Fréquence de déploiement	Nombre de déploiements effectués sur une période donnée.	Déploiement par période

Collaborer autour d’une approche itérative

L’itération et la collaboration sont des éléments essentiels pour réussir une transformation DevOps.

Collaboration : de l’importance de travailler ensemble

Dans le cadre du DevOps, la collaboration est cruciale. Les équipes de développement et d’exploitation ne sont plus des entités séparées. Elles doivent travailler ensemble de manière cohérente pour atteindre des objectifs communs. Cette synergie est représentée par l’image de l’escalade en groupe, où chaque membre aide les autres à progresser. De même, dans un environnement DevOps, chaque membre de l’équipe apporte ses compétences spécifiques pour résoudre des problèmes complexes et créer des solutions robustes.

Petits pas : l’approche itérative

L’itération est au cœur de la méthodologie DevOps. Plutôt que de tenter de réaliser de grands projets en une seule fois, l’approche DevOps favorise la réalisation de petites améliorations continues. Ces quick winspermettent d’ajuster rapidement les processus et de s’adapter aux changements. Cette méthode permet également d’identifier et de corriger les erreurs rapidement, avant qu’elles ne deviennent des problèmes majeurs.

Minimum Viable Product (MVP) : l’essence de l’itération

Le concept de Minimum Viable Product (MVP) est un autre aspect crucial de l’itération. Il s’agit de développer une version minimale du produit qui puisse être mise sur le marché afin de recueillir des retours d’utilisateurs réels. En se concentrant sur le MVP, les équipes peuvent obtenir des informations précieuses sur ce qui fonctionne et sur ce qui doit être amélioré, permettant ainsi des ajustements rapides et efficaces. Cette approche réduit les risques et assure une utilisation optimale des ressources.

En combinant l’itération et la collaboration, les équipes DevOps peuvent surmonter les obstacles plus efficacement. Chaque membre de l’équipe apporte sa contribution unique, tandis que l’approche itérative permet de faire des progrès continus et mesurés. Ensemble, ces éléments créent un environnement dynamique et adaptable, propice à l’innovation et à l’amélioration continue.

Conclusion

Depuis ses débuts, le DevOps a évolué, s’adaptant constamment aux besoins changeants des entreprises et des technologies. Les patterns classiques et le profil DevOps que nous connaissons aujourd’hui sont le résultat d’une évolution continue, façonnée par l’expérience et l’innovation.

Cependant, cette évolution est loin d’être terminée. Le DevOps continue de se transformer chaque jour, intégrant des pratiques modernes et des outils avancés qui repoussent les frontières de ce que nous considérons comme possible en matière de développement et d’opérations. Les défis d’aujourd’hui exigent des solutions de plus en plus sophistiquées, et c’est dans ce contexte que le DevOps se réinvente sans cesse, en adoptant des approches comme le DevSecOps, le GitOps, et l’ingénierie de plateformes.