DevOps : quelles tendances pour 2018 ?

Alors que le mouvement DevOps s’est imposé dans le paysage IT, on se demande aujourd’hui dans quelle direction il peut évoluer. Déjà, le mouvement DevSecOps, qui réunit développement, sécurité et exploitation, est en route. Mais ce n’est pas le seul. Autre interrogation : ces cultures signent-elles la fin des opérations d’exploitation traditionnelles, comme on l'a si souvent prétendu ? Voici quelques pistes d’évolution pour 2018.

La persistance de l’opérationnel

Owen Garrent, responsable des produits chez Nginx, est certain que l’année 2018 ne sera pas celle de la mort de l’opérationnel. « Les applications monolithiques traditionnelles vont perdurer pendant plusieurs d’années, et la plupart des entreprises vont continuer à développer des applications de ce type », a-t-il affirmé. Néanmoins, il estime que le rôle des « ops traditionnelles » est menacé : selon lui, seules les équipes qui comprendront les nouvelles orientations de l'industrie trouveront les moyens d’intégrer des connaissances durement acquises dans les nouveaux processus de développement. Mais ce n’est pas l’avis de Mandi Walls, community manager technique EMEA chez Chef. Selon elle, « beaucoup d’opérationnels seront effectivement hors circuit seulement si l’on pense que les « opérations traditionnelles » se limitent à des opérations d’installation et d’intégration », a-t-elle déclaré.

Intégration des DevOps : d'où viendra le changement ?

Toujours selon Mandi Walls, certes le mouvement DevOps est aujourd’hui dominant, mais le vrai changement doit surtout se traduire par un changement culturel au sein de l’entreprise. « Nous avons vu à quelle vitesse le langage a évolué alors que l’adoption du paradigme s’accélérait », a-t-elle ajouté d’un ton un peu ironique. « D’autres indicateurs intéressants, comme les certifications devops, ont également montré que si un plus grand nombre d’entreprises s’intéressaient à la méthode devops, elles n’ont peut-être pas pris en compte tout ce que cela impliquait ». Enfin, cet engouement « ne signifie pas que certaines industries ne sont pas à la traîne pour ce qui est de l’adoption de la méthode devops, en particulier les industries tributaires de la technologie », a encore déclaré Mme Walls. « La technologie joue un rôle de plus en plus important dans tous les domaines, le secteur bancaire, celui de la santé en passant par l'éducation et le bâtiment. Mais l'assurance et les services publics - des environnements fortement réglementés où les contraintes ont favorisé le développement d’un écosystème de praticiens spécialisés - sont à la traîne. Mais ces industries pourraient rattraper massivement leur retard dès qu’elles auront trouvé la solution spécifique qui satisfait à leurs besoins essentiels ».

Mandi Walls pense que, dans un monde idéal, les initiatives viseront essentiellement « des résultats opérationnels bien définis », qu’elles bénéficieront du soutien des instances dirigeantes et qu'elles « s’appuieront sur les équipes et les personnes concernées par ces changements ». Elle pense également que dans certaines entreprises, « les initiatives pourraient venir des équipes de développement, l’idée étant de dégager la meilleure réponse possible à certains objectifs organisationnels ». D’ailleurs, selon elle, « les changements auxquels nous assistons déjà, comme les migrations vers de nouveaux systèmes de contrôle de version, sont en grande partie liés au workflow instauré par les équipes de développement pour améliorer le débit et l'efficacité ».

DevOps, DevSecOps, DevSecArchOps…

Dernièrement, ce sont surtout les « DevSecOps » qui ont gagné en popularité. Alors, que va-t-il se passer maintenant ? À ce propos, les avis divergent : Andrea Hirzle-Yager, responsable IT chez Allianz, le spécialiste allemand des services financier, pense qu’il faudrait aussi impliquer les architectes dans ce groupe. « Oui, la collaboration entre développeurs et opérationnels est de plus en plus importante. Mais ce qui a fait le succès de notre projet cloud, c’est que, dès le début, tous les départements ont été impliqués », a-t-elle expliqué. « Selon moi, il faut passer au « DevSecArchOps ». Il est extrêmement important que ces quatre groupes - développeurs, sécurité, architectes et opérations - travaillent ensemble. Plus les architectes IT seront impliqués, mieux ce sera. Le scénario vraiment idéal serait que les architectes sachent aussi faire du codage ».

Mais Simon Ratcliffe, stratège et évangéliste pour l’entreprise de services IT Ensono, imagine d’autres développements. Selon lui, le mouvement DevOps va retourner à sa source. « Je pense que l’on va retrouver la philosophie japonaise de gestion de la qualité, le Kaizen, qui prône une amélioration continue fondée sur des actions concrètes, simples et peu onéreuses », a-t-il expliqué. « En tant qu'industrie, nous sommes coupables d'avoir privilégié une informatique monolithique, car en fait, nous n’avons pas besoin de changements radicaux. Cela s’explique peut-être par le besoin de l'entreprise de faire du « tri » dans l’IT, ce qui laisse entendre qu'il y a une finalité à atteindre. Mais, il n’y a jamais de « tri » possible dans l’IT. C'est une saga permanente. Idéalement, nous devrions appliquer les processus de changements itératifs du DevOps aux devops eux-mêmes ».

L'Open Source ouvre toujours la voie

« Il est important de répéter que le DevOps n'est pas une solution que l’on peut acheter sur le marché », a encore déclaré Owen Garrett de NGINX. « C’est une combinaison de produits, de services et de composants open source, assemblés de la manière qui convient le mieux à chaque entreprise, avec des intégrations personnalisées », a-t-il ajouté. « L’achat de services DevOps coûte cher, mais les entreprises avec des objectifs clairs et urgents ne pourront pas s’en passer ». « L’open source permet d’accéder à une technologie éprouvée, à un vaste écosystème de solutions et de support », a encore expliqué M. Garrett. « Et il facilite le recrutement et la fidélisation des talents. De plus, il permet de maîtriser les évolutions de la technologie utilisée par l’entreprise. Bien sûr, le support du fournisseur garantit une assistance technique rapide et confidentielle, un accès et un droit de regard sur la feuille de route, quelques fonctionnalités propriétaires auxquels vous n’aurez peut être pas accès, plus la livraison en temps voulu des mises à jour et des correctifs de sécurité ».

Attention aux charlatans : le DevOps vient « de l'intérieur »

Carlos Sanchez, ingénieur chez CloudBees, rappelle avec force que la méthode DevOps ne repose pas sur des outils, mais sur la culture. « Ce sont des objectifs partagés et une collaboration pour résoudre les problèmes pour, finalement, accélérer le logiciel. En ce sens, le DevOs est très différent des outils cloud et VM conçus spécialement pour les applications cloud et VM. Donc, beaucoup d’entreprises disposent d’un set d’outils qu’elles peuvent partager pour adopter la méthode DevOps et certaines l’on fait avec succès ». Celui-ci cite citer par exemple Maven, Jira, Jenkins, CloudBees, Git, Puppet, Chef, Docker, Subversion, Nexus, Nexus, Ansible, Vagrant... « Ce ne sont pas des « outils devops » à proprement parler, mais des outils qui permettent aux entreprises d'optimiser leur pipeline de logiciels et de se transformer pour adopter une culture devops ».

Jason Yee, évangéliste technique chez Datadog, reconnaît qu'il y a une différence fondamentale entre les fournisseurs d'outils propriétaires et les débuts du cloud ou VM. « Aux tout débuts du cloud, des entreprises ont migré aveuglément vers le cloud et elles ont vu leurs coûts d'infrastructure monter en flèche par rapport à ce que leur coûtaient leurs infrastructures sur site », explique M. Yee. « En grande partie, elles n’ont pas compris ce qu’elles possédaient ou ce qu’elles achetaient. Et cela risque de se reproduire avec les entreprises qui essaient d'acheter des solutions DevOps. Elles pourront acheter des outils et des services incroyables, mais si leurs équipes ne commencent pas par adopter une culture DevOps, le ROI de la plupart de ces outils et services sera probablement très décevant ». Enfin, pour Patrick Hubbard de SolarWinds, les entreprises pour qui le DevOps correspond à une offre de fournisseur contribuent au retard de son adoption. « Le fait de considérer le DevOps comme une solution de fournisseur type favorise de manière significative le retard persistant de son adoption. Le DevOps prêt à l’emploi n'existe pas et les DSI doivent cesser de l'acheter. Le DevOps vient de l'intérieur ».