Bien des définitions du DevOps cohabitent, certaines étant même contradictoires et une lecture trop rapide de ces définitions peut amener plus de confusion que de succès. Mais surtout, au-delà de potentiels méthodes et outils, il s’agit avant tout d’un état d’esprit, ce qui s’avère souvent plus difficile à modéliser et concrétiser.

Tout comme la musique se base sur des notes pour obtenir des symphonies adaptées au style de chacun, nous donnerons les éléments principaux qui font partie de la philosophie au travers de ce papier. Nous verrons que les notes seules ne font pas une musique et que c’est ce lien qui permet la création d’une mélodie, voire d’une symphonie, pérenne dans le temps.

Le DevOps c’est quoi ?

C’est en 2008 que le terme Agile Infrastructure a fait son apparition et a très rapidement été repris par la communauté, ce qui était déjà en soi une révolution. Dès l’année suivante, le mouvement était né au travers des premières présentations d’une seule voie sur l’agilité au sein des développements et l’agilité de l’infrastructure avec comme leitmotiv de casser les silos et d’améliorer la flexibilité au sens large.

A une époque où le hashtag arrivait en force, #devops s’est alors imposé. Pourtant ce terme représente assez mal ce mouvement et ne met en exergue que le rapprochement voire la collaboration entre les développeurs et les opérations ou encore ce qui est en amont et en aval du livrable. Pourtant, dans un contexte agile, le livrable évolue et n’est plus le point de référence.

Le rapprochement entre les Devs et les Ops a permis de mettre en avant d’autres silos au sein même de cette seconde catégorie. En effet, bien que cela ne fasse pas toujours plaisir à tout un chacun, Ops englobe bien des choses : les bases de données, le réseau, les sauvegardes, les logs, la sécurité etc.

Mais dès lors comment être agile quand, en pratique, bien des silos existent ? Chaque élément du système se doit d’être agile, c’est un fait mais surtout il est nécessaire de faire en sorte que chacun partage « un état d’esprit DevOps » qui repose sur quelques fondements que nous allons aborder ci-dessous.

Que peut-on attendre de DevOps ?

Les objectifs de DevOps sont multiples. Nous ferons le choix de les grouper en 6 grandes catégories et qui se caractérisent par des mots clés spécifiques :

• Déploiement accéléré

déploiement en continu, automatisation, connaissance des environnements

• Robustesse

micro-services, architecture, tests réguliers

• Evolutivité

élasticité de la charge, architecture modulaire

• Cohésion des équipes

interdisciplinarité, compréhension transverse, expertise, rapport d’activités commun

• Sécurité

security by design, déploiements automatisés

• Mesurabilité

accès à l’information de production, connaissance des environnements, micro services et architecture, traçabilité complète

Nous pouvons, d’ores et déjà, remarquer que bien des mots clés se retrouvent dans différents objectifs, ce qui explique la complexité de mise en œuvre. Nous y reviendrons.

Que faire pour implémenter DevOps ?

La vraie question à se poser est : que veut dire « implémenter DevOps » ?

Sur base du manifeste Agile avec lequel DevOps partage les enjeux, il est possible de définir un manifeste DevOps en définissant un état d’esprit, des valeurs, des principes, des méthodes et des pratiques. Une approche DevOps réussie repose sur l’ensemble des éléments de la pyramide :

De nombreux livres existent sur le sujet. Nous n’abordons ici que les mots clés et des pistes de réflexion.

Un état d’esprit …

Un mouvement repose tant sur les aspects techniques que sur les personnes et ne peut s’effectuer que si chacun a la volonté d’aller dans une direction commune, en collaborant et en acceptant le changement en tant que tel, ayant pour but de permettre un gain tant pour le collaborateur que l’utilisateur final du produit.

… des valeurs …

Sans pour autant négliger la valeur des éléments en second, il s’agit de garder certaines valeurs en mémoire lors de la mise en œuvre de DevOps :

• Les individus et leurs interactions, plus que les processus et les outils
• Des logiciels opérationnels, plus qu’une documentation exhaustive
• La collaboration avec les clients, plus que la négociation contractuelle
• L’adaptation au changement, plus que le suivi d’un plan

… des principes…

Il existe de nombreuses variantes de cette liste. De ce fait, le choix s’est porté sur celle de la DevOps Agile Skills Association[1] qui est plutôt représentative de l’état d’esprit :

• Le client est au centre de l’activité
• La finalité est la cible
• La co-création et la responsabilité sont partagées entre tous
• Les silos font partie du passé et une équipe produit représente le présent
• L’amélioration fait partie du quotidien, l’organisation doit la permettre
• L’automatisation doit être favorisée dès que cela est possible

… des méthodes …

Toutes les variantes des méthodes agiles peuvent être utilisées dans ce contexte et se doivent d’être choisies en fonction des objectifs et de la maturité de l’organisation.

…et finalement des pratiques

Les pratiques sont multiples avec notamment l’Infrastructure as Code qui permet de stocker et de gérer l’ensemble des configurations mais aussi l’automatisation des déploiements, tant des systèmes hôtes que des applicatifs. Cette automatisation peut s’étendre aux tests qui, également, peuvent être effectués en continu. La virtualisation et le cloud computing complèteront ces pratiques afin d’à nouveau améliorer les déploiements accélérés, la robustesse, l’évolutivité. Pour répondre aux objectifs de mesurabilité, de robustesse et d’évolutivité, le monitoring doit faire le lien entre applications et les systèmes hôtes.

Les architectures jouent un rôle prédominant dans la mise en œuvre de l’ensemble des pratiques citées précédemment. Ainsi les micro-services et la containerisation sont autant de pratiques facilitant la mise en œuvre d’architectures évolutives et robustes, permettant notamment de mettre le focus sur un composant donné.

Enfin, il s’agit ainsi de mettre en place une culture de communication et de collaboration dans laquelle tout un chacun peut se permettre l’erreur afin d’en tirer avantage. Pour leur gestion au quotidien, les équipes produit (et non « les équipes opérationnelles ») se doivent de mettre en place des méthodes telles que Scrum ou encore Lean, notamment au travers d’outils comme le Kanban, nommé parfois LeanKanban ou ScrumBan.

[1] https://www.devopsagileskills.org/dasa-devops-principles/

Et concrètement, cela donne quoi ?

La cohésion des équipes

Démarrons par ce qui est généralement acquis comme un fondement de DevOps : la collaboration entre deux groupes de personnes ayant un bon niveau, chacun dans son domaine. Cette collaboration doit permettre l’échange d’informations mais aussi de bonnes pratiques provenant de chacun des deux mondes qui doivent s’unifier. Mais au-delà de cet échange, il s’agit surtout de concevoir ensemble, avec un objectif commun, le produit pour les utilisateurs. Cette équipe produit se doit ainsi de participer à l’ensemble des activités, du design au support en production.

La sécurité

La sécurité est souvent perçue comme étant une couche système additionnelle. Pourtant elle se doit d’être réfléchie dès les phases de stratégie et de conception. La solution implémentée se doit de permettre un accès aisé et sécurisé aux données mais aussi de mettre en place de contrôles automatisés que ce soit à priori ou à posteriori. Il s’agit, notamment, de détecter des comportements anormaux et d’effectuer les actions qui en découlent.

Mais la sécurité ne s’arrête pas à l’applicatif. La notion de sécurité est présente et doit être pensée au sein des pratiques. Au travers de déploiements automatisés, un système peut être déployé sans pour autant nécessiter quelle qu’intervention humaine et ainsi limiter le risque d’accès à des données ou des systèmes protégés.

L’évolutivité

Avec une architecture basée sur les micro-services, il sera aisé de faire évoluer un système dans son ensemble, en fonction du besoin. Ainsi de nouvelles fonctionnalités sont plus aisément mises en œuvre. De plus le système, de par sa structure, peut s’adapter à la charge à un moment donné, par exemple pour supporter la génération mensuelle de factures grâce au provisionnement de ressources en fonction d’une situation donnée, attendue ou non.

A nouveau, pour se faire, il est nécessaire de créer une équipe multidisciplinaire qui sera en charge de concevoir la solution que l’on pourra qualifier d’agile.

La fourniture de solutions robustes

Les tests sont particulièrement importants et un maximum de ces tests doit être effectué régulièrement. Evidemment, les outils de test font partie prenante de la solution mais ce n’est pas tout. Pour tester des configurations différentes en y incluant différents containers, différents patches sur les systèmes d’exploitation, des configurations diverses mais aussi des configurations matérielles différentes, il est nécessaire d’automatiser tant les déploiements et les configurations que les tests. Les tests portent tant sur l’applicatif que sur la capacité du système à s’adapter en fonction de la charge de travail.

En complément aux tests, la robustesse requiert des contrôles et du support à chaque étape du processus en partant des éléments stratégiques, de conception mais aussi des revues de code et bien d’autres.

Le déploiement rapide

Pour qu’un système puisse être rapidement déployé il est nécessaire que chaque composant puisse l’être. Il est fréquent de voir des déploiements applicatifs automatisés mais bien souvent cette automatisation ne s’applique pas à la mise à disposition d’une infrastructure en charge de supporter l’application. A nouveau, l’atteinte de cet objectif repose sur différents aspects dont l’infrastructure as Code, la virtualisation et la containerisation.

La mesure du DevOps

La mesure est d’autant plus importante qu’un mouvement peut sembler abstrait. Différents indicateurs sont ainsi regroupés en 6 grandes catégories :

• La performance de l’entreprise :

quels sont les gains financiers, de part de marché ou même le retour sur investissement

• La valeur pour le client :

sa satisfaction, la durée avant la mise à disposition d’une nouvelle fonctionnalité

• L’efficacité organisationnelle :

la satisfaction et la motivation des collaborateurs, l’adoption plus ou moins rapide des changements et la collaboration entre eux

• La qualité de service :

les incidents et la dette technique

• La vitesse de service :

les durées avant détection et résolution

• L’efficacité opérationnelle :

le coût d’une transaction, le coût opérationnel ou d’un changement

Le DevOps et le Service Management

Très souvent perçus comme mutuellement exclusifs, DevOps et ITIL sont pourtant compatibles voire confondus à certains moment. Preuve en est qu’ITIL, dans sa dernière version parue en janvier 2019, aborde les notions d’agilité et de DevOps. ITIL est plus procédural que DevOps, qui se veut fortement agile, comme l’indique les mots choisis mais tous deux ont des objectifs communs. Comparativement, ITIL définit des processus alors que DevOps est orienté sur une approche globale. ITIL couvre également un périmètre assez large puisqu’il décrit un grand nombre de fonctions nécessaires à la vie d’une entreprise telles que service desk, incident and problem management, continual service improvement, etc. DevOps, quant à lui, se focalise pas mal sur l’interne, à contrario d’ITIL qui couvre d’autres aspects tout aussi importants, notamment le budget et les fournisseurs. On pourrait ainsi dire qu’ITIL supporte DevOps puisqu’il rend concret certains aspects de DevOps qui a pour but de présenter une démarche.

ITIL propose des définitions de concepts tels que le changement. Le seul objectif d’ITIL est cependant que le changement soit traqué. Le lien entre les déploiements et le changement défini par ITIL est ainsi simple à faire : un déploiement applicatif automatisé est potentiellement pré-approuvé. Ainsi, lors du déploiement, une simple entrée peut être ajoutée afin de profiter de l’efficacité de DevOps tout en atteignant les objectifs d’ITIL.

« Oui mais mon outil de déploiement garde déjà l’information du déploiement passé ». Tout à fait, cependant un système est bien plus large que l’applicatif lui-même et repose sur le réseau, le pare-feu, les systèmes d’exploitation, la configuration de l’applicatif et du système hôte, notamment lors de l’auto-scaling. De ce fait, l’information au sein de l’outil de déploiement ne représente aucunement le système. Cette information sera utile dans le temps, notamment lors d’incidents.

Etre agile, c’est savoir pour aller vite. C’est ce que propose la combinaison ITIL / DevOps.

Des recommandations en termes d’outillage ?

Nous ne ferons qu’aborder les produits les plus fréquemment utilisés dans le domaine du DevOps tant le marché est prolifique :

• Entrepôt de code sources, de configuration et de scripts: TFS, GitHub pour le développement, Terraform pour l’infrastructure-as-code
• Entrepôt d’artefacts : Artifactory, Nexus Repository
• CI/CD : Jenkins, GitLab CI, Concourse, Octopus Deploy, TeamCity 
• Containers: Docker (runtime)
• Configuration: Puppet, chef, ansible
• Orchestration: zookeeper ou encore Kubernetes quand il s’agit d’orchestrer des containers
• Monitoring : Elastic Search, Logstash et Kibana pour les logs. AppDynamics pour les indicateurs
• ChatOps : Zulip, Mattermost

Ces outils se doivent d’être étudiés afin de choisir celui qui s’avère le plus adapté à la culture et au stack technologique de l’entreprise.

Démarrer la mise en place d’une approche DevOps

Être agile n’est pas chose aisée puisque chaque maillon se doit d’être agile. On retrouve ainsi des initiatives particulières qui, bien qu’elles aillent dans le mouvement DevOps, ne permettent pas à l’organisation d’être agile dans son ensemble. D’ailleurs, il est fréquent d’entendre que des entreprises sont agiles là où seul le développement peut se targuer d’être agile. Ces entreprises ont en réalité implémenté une approche hybride, souvent appelée Water-Scrum-Fall et qui fait référence aux approches Waterfall et à Scrum. Ce n’est certes qu’une première étape vers une approche agile mais elle a cependant le mérite d’exister.

En effet, il n’existe aucune approche figée pour arriver à la finalité et le chemin pour y arriver dépend fortement de l’entreprise qui souhaite implémenter une telle approche. Pour un maximum de succès, il est cependant nécessaire de travailler sur l’état d’esprit, potentiellement au travers d’initiatives qui semblent tout à fait hors sujet telle que le team building, une réorganisation de l’espace de travail et bien d’autres. Pourtant ce sont ces initiatives qui permettront de créer un esprit d’unité dans lequel le collaborateur pourra y trouver des avantages et y répondre en fournissant le meilleur de lui-même.

N’oublions pas que le succès n’est pas la somme des outils mais bien de la manière dont ceux-ci sont utilisés.