Devops ou l’exploitation à la sauce agile

L’agilité à la conquête de la DSI

Depuis le tournant du siècle les démarches agiles ont fait une entrée progressive dans la DSI[1]. Partant du constat que l’élaboration itérative d’un système informatique par de équipes resserrées et auto-organisées travaillant en collaboration étroite avec les utilisateurs s’avère particulièrement efficace, chacune de ces démarches préconise le déploiement de pratiques et d’outils propres à faire émerger cette agilité, objet de toutes les convoitises. Si le développement logiciel a été le point d’entrée de ces idées, celles-ci ont par la suite essaimé dans le reste de la DSI où elles ont contribué à rénover d’autres activités. Une exigence de cohérence culturelle en est à la cause principale. Difficile en effet de concevoir la mise en place d’une culture qui serait l’apanage des seules équipes de développement sans transformer également les modes de fonctionnement des autres équipes avec lesquels elles interagissent. A ce titre, le management d’équipes agiles doit par exemple être repensé en profondeur. De même les interactions entre les équipes de développement et les équipes d’exploitation devront être revues et c’est là précisément ce que préconise le mouvement Devops.

Le constat de Devops

Apparu en 2009 en Belgique, l’acronyme Devops, concaténation de « Development » et « Operations » (exploitation en anglais) désigne un mouvement qui fédère en réalité deux courants de pensée. Le premier est celui des cercles classiques de l’agilité. L’autre est celui des experts de la production informatiques des géants du web tels qu’Amazon, LinkedIn ou Facebook qui estiment que l’expérience acquise par ces pionniers, notamment en matière d’industrialisation des environnements de productions, devrait désormais profiter à toutes les entreprises. Sur un plan culturel, le principal constat que font les partisans de Devops est celui de la dichotomie qui existe traditionnellement entre les équipes de développement et celles en charge de l’exploitation.

Férues de technologies et aux prises avec des besoins qui varient au gré des humeurs des utilisateurs et des opportunités du marché, les équipes de développement sont souvent familiarisées avec les principes de l’agilité. Elles manifestent un intérêt spontané pour l’innovation technologique qu’elles conçoivent avant tout comme une source de gratification professionnelle. Leur perception de la production, en caricaturant un peu, est celle d’une petite secte d’individus qui appuient sur des boutons et restent crispés sur deux ou trois technologies obsolètes.

Les équipes de productions sont cependant celles que l’on réveille à trois heures du matin lorsqu’un service  tombe en panne. Non sans raisons légitimes, elles se considèrent donc comme étant « au front » et responsables en dernier ressort de la disponibilité effective du SI auprès des clients et des partenaires. Le foisonnement technologique, loin de les réjouir, est leur principal ennemi. Dans un département de production on aime l’uniformité et les standards, de préférence en nombre limité. Et lorsqu’une solution a fait ses preuves, on n’y touche plus ! Les développeurs quant à eux sont perçus comme une bande d’adolescents immatures pour qui la technologie n’est qu’un terrain de jeu personnel.

Cette dichotomie culturelle possède pourtant un caractère largement artificiel. Car si l’on y songe un instant, le déploiement d’une application dans son environnement de production n’est que la dernière étape du processus de développement. Rien n’oblige sur le plan des principes à disjoindre cette dernière activité de celles qui la précèdent.

Ce qui est nouveau et ce qui l’est moins

Faire pièce à cet fracture culturelle qui relève d’une tradition malencontreuse plus que de la raison est l’objectif principal du mouvement Devops. On peut distinguer deux aspects dans cette entreprise louable. La première est conceptuelle (ou culturelle si l’on veut), l’autre est plus technique. Attachons-nous à voir dans un cas comme dans l’autre en quoi réside la nouveauté de Devops, pour autant qu’elle existe.

Versant conceptuel

Décrire le contenu effectif de Devops n’est pas aisé car les contours du sujet restent assez flous et chacun voit aisément midi à sa porte. Pour dissiper ces brumes conceptuelles, dressons une courte liste des principales suggestions de la communauté Devops et comparons-les avec les pratiques agiles usuelles préconisées dans le secteur du développement logiciel.

1. Les partisans de Devops tout comme les agilistes considèrent que l’imprévisibilité du comportement d’un système informatique est une réalité qu’il convient de reconnaître. Tous deux estiment qu’à trop vouloir s’en prémunir on évite finalement d’acquérir la compétence pour faire face aux dysfonctionnements puisque les erreurs sont des sources d’apprentissage aussi incontournables qu’utiles.
2. Les uns comme les autres estiment encore que la meilleure manière pour résoudre les problèmes conjoints au développement et à l’exploitation reste l’auto-organisation d’équipes soumises aux contraintes nés d’intérêts partagés qui sont, en définitive ceux de l’entreprise, des clients et des partenaires. Pour éviter de casser cette dynamique d’auto-organisation spontanée, il convient de prohiber les mécanismes d’incitations contradictoires comme ceux qui consistent par exemple à récompenser les équipes de développement pour le nombre de fonctionnalités développées alors que les exploitants le seraient en fonction de la stabilité de l’infrastructure dont ils sont les garants.
3. Enfin, dans l’objectif de fiabiliser des opérations telles que la préparation ou la création de plateformes de production, le déploiement d’applications et pour réduire la variabilité du comportement des systèmes, on insiste de part et d’autre sur l’importance d’automatiser les tâches rébarbatives et sujettes aux erreurs humaines. Par souci de robustesse, on cherche aussi à privilégier les solutions les plus rustiques.

Sur le plan conceptuel, rien de neuf sous le soleil, Devops n’invente rien. Il s’agit simplement de mettre en œuvre les principes usuels des démarches agiles dans un contexte où, désormais, le déploiement d’une application n’est plus considéré comme une activité disjointe du développement mais n’en constitue en fait que son ultime étape.

Versant technique

Il en va différemment pour les aspects techniques liés à Devpos. Depuis quelques années en effet sont apparues sur le marché des solutions techniques innovantes qui permettent de concrétiser l’exigence d’automatisation mentionnée au point 3. ci-dessus. Chose qui était difficilement envisageable il y a encore quelques années.

La première catégorie d’outils correspond aux plateformes IaaS disponibles sur étagère auprès des fournisseurs de services dans le Cloud comme Amazon, Google, Oracle ou IBM. Dans ce modèle d’infrastructure déportée, les clients bénéficient de l’expertise des géants du web, littéralement insurpassable en matière d’automatisation des déploiements et d’infrastructure à grande échelle. Une configuration IaaS est spécifiée en quelques clics et est disponible en l’espace de quelques secondes.

La seconde catégorie d’outils, plus adaptée à des besoins très spécifiques, est constituée d’outils et langages de programmation dédiés[2] qui permettent d’automatiser la configuration de serveurs, les déploiements d’applications critiques et les tests d’infrastructure. Ces outils permettent aujourd’hui de réaliser au niveau de l’infrastructure ce que les outils d’intégration continue permettaient de réaliser pour le code source.

Pour conclure on peut donc considérer que, même s’il ne faut pas négliger tout ce qui peut contribuer à l’instauration d’un dialogue entre les deux communautés, en appliquant par exemple le principe du « vis ma vie » durant quelques jours, l’essentiel de l’effort pour concrétiser les objectifs de Devops consistera en une veille technologique active et permanente sur ces nouveaux outils d’automatisations.

Téléchargez l’article

[1] XP en 1999, Scrum en 2001, Kanban 2003 et le Lean Software Development en 2003.
[2] On parle de DSL = Domains Specific Language. Voir p.ex. les outils Chef ou Puppet Enterprise