Technologies

Comment éviter les sorties de route du DevOps

Plusieurs projets DevOps se terminent en échec pour ne pas avoir respectés quelques principes essentiels. (Crédit Photo : Bru-No/ Pixabay)

Il y a toujours un fossé entre la théorie et la pratique. Le voyage vers le DevOps peut s'avérer compliquer si on ne respecte pas quelques principes. Nos confrères de CIO Etats-Unis ont demandé quelques conseils et des retours d'expérience auprès de spécialistes sur le sujet.

PublicitéLa méthode DevOps prend de l'ampleur au sein des entreprises en devenant le moyen de développement adapté à l'agilité et la rapidité de mise en production d'applications. Elle stimule la collaboration entre les développeurs et les équipes en charge de l'exploitation en s'appuyant sur des outils d'intégration et de livraison continues. En théorie, le DevOps rend le développement plus agile et réduit les conflits internes.

Mais la théorie n'est pas toujours alignée sur la pratique. Nos confrères de CIO Etats-Unis ont discuté avec des personnes ayant aidé à déployer du DevOps pour découvrir le côté sombre de cette philosophie IT (à la fois les problèmes propres à la méthode et ceux liés à son intégration).

Le DevOps est plus qu'une suite d'outils

« Dans cet univers, il y a eu une explosion d'outils de publication (Jenkins, Travis, Teamcity), de gestion de configuration (Puppet, Chef, Ansible, Cfengine), d'orchestration (Zookeeper, Noah, Mesos), de monitoring, virtualisation et conteneurisation (AWS, OpenStack, Vagrant, Docker) et bien d'autres. Dans le sens des principes agiles, il est incorrect de penser qu'un de ces outils est un « outil DevOps » et qu'il apportera la magie DevOps », explique Ernest Mueller sur le site Amin Agile.

Le problème est que les fournisseurs mettent en avant cet aspect totémique des outils DevOps. Et ils ne font aucun effort pour changer cette mentalité. L'article de notre confrère de CIO US évoque le cas de « Mike » qui a travaillé dans l'équipe d'un CTO d'une PME technologique et qui a vécu un passage au DevOps. Il dénonce le « culte du cargo » en ciblant la vision tunnel des développeurs. « Ils répondaient à un problème par une solution logicielle en considérant que le DevOps comme une suite de technologies à intégrer dans différentes applications ». Il ajoute « c'est totalement faux, mais c'est difficile de savoir par où commencer ». Mike s'est inspiré d'un roman « The Phoenix Project » qui raconte comment un DSI a réussi à sauver un projet IT grâce au DevOps. Il a organisé des formations sur Ruby et Chef, réalisé des hackathons. Mais au final la transition de Mike vers le DevOps était pavée d'erreurs qu'il attribue en grand partie à l'incapacité de connaître les réelles implications d'un tel projet. « Si le DevOps n'est pas du logiciel, qu'est-ce que c'est ? » s'interroge-t-il. La réponse est bête, souligne Mike en expliquant que « le DevOps est une culture » et changer de culture est la chose la plus difficile à réaliser au sein d'une entreprise. Les développeurs ont particulièrement du mal à se plier aux exigences venues de la direction. « Cette culture doit être travaillée en interne par des managers forts, mais ils se font rare au sein des entreprises ».

Tout le monde ne sera pas à bord

PublicitéLa version idéale du DevOps est que l'ensemble des équipes techniques adoptent et rejoignent cette méthode. Mais dans la réalité, ce changement est compliqué car certaines personnes estiment qu'ils font leur travail correctement et qu'il n'y a pas lieu de changer. Cody Swann, CEO de Gunner Technology, éditeur de logiciels pour aider les organisations à passer DevOps, a pu constater à différentes reprises les résistances des collaborateurs. Ainsi dans un projet IT, l'équipe Ops a remis en question la viabilité d'une nouvelle infrastructure. « Ils ont démontré que les microservices sont une mode et qu'ils n'étaient pas viables pour des grands projets, car ils sont difficiles à maintenir et ne peuvent pas évoluer avec du JavaScript », se rappelle le dirigeant. Sur ce projet, les choses ne sont pas améliorées au fur et à mesure de l'avancée du projet. « Nous étions en train de décomposer une énorme application/infrastructure monolithique .Net en microservices Javascript basés sur AWS Lambda », souligne Cody Swann et d'ajouter, « une migration des données Oracle vers une solution DynamoDB/Elasticsearch était prévue ». Sur ce dernier point, « l'équipe Ops a estimé qu'il était impossible de nous donner accès à la base de données Oracle pour migrer les données. Des excuses fallacieuses comme par exemple prétendre que la base de données n'était accessible qu'aux adresses IP internes ». Au final, « nous avons établi une connexion VPN à partir d'AWS pour migrer les données, mais avec beaucoup de pushback ».

La sécurité reste comme d'habitude un problème

Qui dit nouvelle méthode, dit aussi l'apparition des problèmes de sécurité spécifiques. « Avec l'intégration et le déploiement continu, une grande partie des bonnes pratiques de sécurité est souvent automatisée ou parfois exclue du processus pour ne pas freiner la sortie des applications », explique Davy Hua, responsable DevOps pour Shiftleft. « Par conséquent, la croissance des versions publiées générera du code peu ou pas éprouvé, engendrant des risques de fuites de données comme ce fut le cas chez Equifax ». Il poursuit en expliquant, « qu'il s'agisse d'une application monolithique ou segmentée en microservices, les flux de données sont complexes et exigent beaucoup de compréhension pour installer des règles de sécurité efficace. Si on ajoute la contrainte de temps pour délivrer rapidement, il en résulte un certain degré de négligence en matière de sécurité ».

De son côté, Igor Livshitz, directeur produit chez Guardicore, voit la sécurité devenir un problème particulier pour le DevOps quand « elle est intégrée dans différents points du processus DevOps, au lieu d'être un sous-produit post déploiement ». Il estime que « dans le monde actuel, où les instances, les microservices et les infrastructures hybrides ont une durée brève, tout point unique de contrôle basé sur l'humain ne peut pas vraiment suivre la cadence ». Dans l'idéal, les développeurs décrivent les politiques nécessaires applicables pour leurs applications et les responsables sécurité les regardent et installer des outils d'audit et de monitoring pour s'assurer de la conformité. Il s'agit là encore ce scénario idéal ne se réalise pas dans la vie réelle, « tout cela peut s'effondrer s'il y a un manque de confiance entre les fonctions de sécurité et les DevOps dans l'entreprise », souligne Igor Livshitz. Au sein de ses clients, il a souvent constaté que les deux entités sont souvent dans des départements séparés avec un esprit de corps affirmé. « La méfiance peut s'installer à la suite d'un incident de sécurité provoqué par un manque de sensibilisation de la part de l'une ou l'autre partie ». Pour éviter cela, les équipes de sécurité doivent intégrer des contrôles de sécurité tout au long du cycle DevOps.

Ne pas confondre rapidité et précipitation

L'intérêt de passer au DevOps réside dans le fait de délivrer rapidement des applications. Mais trop souvent les équipes pensent que le passage au DevOps doit se dérouler tout aussi vite avec des résultats désastreux. Si l'accompagnement au changement des équipes n'existe pas, on peut aboutir à la création d'un DevOps à la mode Frankenstein. Ed Price, directeur de la conformité chez Devbridge Group donne un exemple de signes avant-coureurs, « si les entreprises conservent des migrations et des mises en productions manuelles de code. Si elles gardent une équipe dédiée aux environnements. Si elles ne disposent d'unité automatisée, de tests de régression ou de performance intégrés dans les pipeline de CI (intégration continue) pour bloquer le code quand il n'est pas encore prêt ».

Il faut aussi du temps pour obtenir le bon mélange des personnes nécessaires à une bonne équipe DevOps. « Il est courant pour les entreprises d'identifier les « rock stars », les membres les plus performants et les plus prometteurs pour les nouvelles initiatives », constate Justin Rodenbostel, vice-président en charge du développement des applications Open Source chez SPR. Il poursuit, « la constitution d'équipes basées sur des prouesses techniques ou d'expertises peut échouer si d'autres compétences comme la collaboration et la communication ne sont pas également prises en compte ».

Un état d'esprit adapté

S'il y a une leçon à tirer de l'ensemble des éléments précédents, c'est que les gens sont les plus importants pour pousser le projet DevOps du côté sombre à la lumière. « Il faut recruter des gens avec un bon état d'esprit, plutôt que de comprendre comment créer du DevOps à partir de rien », analyse Ryan Duguid, chef évangéliste chez Nintex (plateforme d'automatisation des workflow). « Quand cela arrive, les équipes finissent par faire trop d'ingénierie, dépenser trop ou aboutir à une telle sophistication impossible à gérer. Il faut faire appel à des gens qui viennent en demandant « de quoi a-t-on besoin ici ? » plutôt que « voilà ce que j'ai fait dans mon dernier poste ». Cela dépend beaucoup de l'état d'esprit de l'entreprise vis-à-vis du projet DevOps, si elle débute, « elle aura besoin d'un talent qui comprend, qui a déjà accompagné un projet DevOps et qui est capable de se concentrer sur l'essentiel » observe Ryan Duguid. Il conclut son propos en prodiguant un conseil « apprenez à marcher avant d'essayer de voler ».

Article écrit par Josh Fruhlinger/CIO US (traduite et adapté par Jacques Cheminat)