Trois obstacles qui vous empêchent d’adopter le DevOps

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Non, pas vous. Vous. Les dirigeants sont loin d’être aussi enthousiastes à l’égard du DevOps que les équipes sur le terrain, et l’une de ces trois préoccupations majeures pourrait bien en être la raison.

Les organisations les plus performantes ne se sont pas contentées d’adopter DevOps : elles l’ont pleinement intégré. Le rapport de référence State of DevOps de Puppet Labs nous le montre depuis deux ans, et j’imagine qu’il confirmera une nouvelle fois cette corrélation au cours de l’année à venir. Selon plusieurs enquêtes et études sectorielles, les organisations adoptent DevOps. Mais, comme lorsqu’elles ont adopté par le passé les méthodologies agiles et lean de développement d’applications, « adopter » ne signifie pas toujours ce que l’on croit. Il s’est avéré que, lorsque les organisations parlaient d’« adopter l’agilité » pour le développement d’applications, elles voulaient en réalité dire qu’un pourcentage relativement faible de leurs projets utilisait des méthodes agiles. Cela ne signifiait pas qu’elles s’étaient lancées à corps perdu en les adoptant pour chacun de leurs projets.

Il semble en aller de même pour le DevOps : les personnes interrogées l’adoptent avec enthousiasme — et obtiennent des résultats —, mais les dirigeants semblent, dans l’ensemble, encore peu convaincus par cette approche. Son « impact stratégique » n’a progressé que de deux points de pourcentage en un an, passant de 15 % en 2016 à 17 % en 2017, selon notre enquête État de la livraison des applications . Si les architectes cloud et les personnes se définissant comme exerçant des fonctions « DevOps » peuvent s’investir pleinement dans leur initiative DevOps, voire l’avoir déjà déployée en production, les dirigeants tardent encore à adopter cette approche. Autrement dit, les « organisations » n’adhèrent pas nécessairement toutes pleinement au DevOps.

Trois préoccupations majeures expliquent probablement pourquoi les directions informatique et métier hésitent encore à réserver à DevOps l’accueil véritablement chaleureux qu’il mérite.

1. Temps. Les projets informatiques internes de toute nature qui nécessitent une démarche de migration — qu’il s’agisse de passer d’une infrastructure traditionnelle au cloud, d’un monolithe à des microservices ou de processus manuels à des processus automatisés — sont parfois considérés comme une simple perte de temps. Ils ne contribuent pas directement à la croissance de l’entreprise, si bien que les parties prenantes peuvent être réticentes à consacrer du temps à de tels projets. Il appartient aux partisans du DevOps de présenter aux dirigeants de l’entreprise un ensemble clair d’objectifs et de bénéfices attendus de la mise en œuvre de ces projets. Qu’il s’agisse de réduire les coûts ou de rendre l’informatique plus réactive, il est important que l’entreprise comprenne le retour sur investissement escompté afin d’obtenir son adhésion et son soutien. Un sou économisé est peut-être un sou gagné, mais un sou investi en rapporte souvent dix. En investissant dès maintenant dans le DevOps, les entreprises en récolteront les fruits plus tard.
   
2. Perturbations. Aucun responsable informatique ne souhaite être à l’origine de perturbations de l’activité. Investir dès maintenant dans une initiative DevOps peut être perturbateur, en particulier si cela ralentit la chaîne de production alors que tout le monde sait qu’il faut au contraire l’accélérer. En effet, préparer la production à l’automatisation et à l’orchestration implique souvent d’intervenir sur les systèmes qui assurent le fonctionnement quotidien de l’entreprise ; toute initiative de ce type peut donc entraîner des perturbations indésirables. En réalité, continuer à s’appuyer sur des méthodes manuelles obsolètes pour provisionner, faire évoluer et gérer les systèmes pourrait constituer la véritable source de perturbation, si ce n’est aujourd’hui, alors demain. L’une des caractéristiques d’un environnement de production fluide est sa capacité à répondre à la demande aux besoins en capacité et en services. Or, cela devient de plus en plus difficile à mesure que l’informatique ploie sous le poids d’une demande croissante liée aux efforts de transformation numérique. Qui ne risque rien n’a rien. Prendre ce risque aujourd’hui en comporte probablement moins que d’attendre que votre portefeuille d’applications ait doublé, voire davantage.
   
3. Dépendance vis-à-vis d’un fournisseur. Les responsables informatiques craignent souvent de se retrouver « prisonniers » de leurs choix. La bonne nouvelle, c’est que la grande majorité des équipements réseau et des systèmes prenant en charge l’automatisation et l’orchestration reposent sur des protocoles standard ouverts et des concepts tels que HTTP, REST et JSON. C’est là que le temps consacré en amont à la conception et à l’architecture d’un système exploitant autant que possible les API et les modèles portera ses fruits par la suite. L’intégration à des équipements ou à des systèmes qui nécessitent de recréer pas à pas, via une API, des commandes exécutées depuis une interface en ligne de commande (CLI) entraînera presque certainement une dépendance vis-à-vis d’un fournisseur. C’est l’un des principaux avantages des modèles : ils réduisent la dépendance aux API propres à chaque équipement ou système et limitent ainsi votre exposition à quelques commandes seulement, qui pourront facilement être migrées vers un nouveau système ou une nouvelle application à l’avenir. Assurez-vous que l’infrastructure prend en charge une API REST et, dans la mesure du possible, utilisez des modèles afin de faciliter l’extraction ultérieure des systèmes et des environnements.

Il existe bien sûr d’autres préoccupations, mais ce sont principalement ces trois enjeux majeurs qui reviennent constamment dans les centres de données et au fil du temps lorsqu’il s’agit d’adopter des technologies et des méthodologies. Cela prend du temps, peut perturber l’activité et présente un risque très réel de dépendance vis-à-vis d’un fournisseur. Une analyse rigoureuse, une démarche de mise en œuvre réfléchie et une volonté d’investir aujourd’hui pour en récolter les fruits demain peuvent atténuer ces inquiétudes et accroître les chances de poser avec succès des bases solides mais flexibles, qui non seulement rendent possible la transformation numérique nécessaire à la croissance de l’entreprise, aujourd’hui comme demain, mais l’accélèrent également.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie