Quelles évolutions pour DevOps en 2019 ?

Consolidation, acquisitions, sécurité… Les évolutions concernant l’approche DevOps pour l’année à venir sont nombreuses. Zoom sur les principales d’entre elles.

« Les leçons de l’approche DevOps s’internalisent dans de nouvelles entreprises et de nouveaux projets, les jeunes dans le coup vont cesser d’en parler », a notamment expliqué Nigel Kersten, vice-président de l’ingénierie des écosystèmes chez Puppet. (crédit : diwou/Pixabay)

La méthode DevOps est sans doute devenue plus courante aujourd’hui, et les nombreux développements qui ont eu lieu en 2018 dans ce domaine permettent de penser que l’année 2019 sera riche en évolution. De manière générale, l’approche DevOps consiste à faire travailler ensemble, avec des outils d’automatisation, les équipes de développeurs et les équipes opérationnelles dans un contexte de transformation de la culture organisationnelle, et libérer le logiciel le plus rapidement possible. Évidemment, c’est une proposition attrayante pour les entreprises, en particulier celles qui entament leur « transformation numérique », même si elles travaillent actuellement sur un projet DevOps au niveau micro et ne sont pas encore tout à fait à l’échelle. L’idée de « rationaliser » (ou de « réduire ») les effectifs des équipes existantes est aussi attractive.

Comme le fait remarquer Abby Kearns, directrice exécutive de la Cloud Foundry Foundation, les acquisitions dans le domaine de l’open source, comme IBM-Red Hat et VMware-Heptio, témoignent d’une nouvelle consolidation du marché du cloud natif. « Aujourd’hui, le paysage est vaste, fragmenté et bouillonnant », a-t-elle écrit. « Bref, il se passe beaucoup de choses. C’est ainsi que les nouveaux marchés évoluent : création de nouvelles technologies, hordes de start-ups attirées par le secteur, formation d’un nouvel écosystème autour de la technologie. Il y a beaucoup d’activité pour voir ce qui fonctionne et ce qui ne fonctionne pas ».

Selon elle, « au fur et à mesure que le marché et la technologie arriveront à maturité, il y aura un alignement autour d’une technologie clé. Les chefs de file de l’écosystème l’emporteront, soit par des abandons significatifs, soit par des acquisitions par des entreprises technologiques en place. Le reste du marché se solidifiera autour des solutions dominantes, et il évoluera à l’échelle ». Autre énorme acquisition par un acteur historique : le rachat de GitHub par Microsoft. Nigel Kersten, VP de l’ingénierie des écosystèmes chez Puppet, pense que celle-ci va aider l’entreprise de Redmond à se renforcer de plus en plus dans l’open source, « en se démarquant fortement de l’acquisition IBM/Red Hat en termes de résultats et de pérennité ».

« Mort au DevOps » ou « Vive le DevOps » ?

Selon Nigel Kersten de Puppet, de plus en plus de gens vont proclamer la « mort » du DevOps. Cela ne veut pas dire que les pratiques vont disparaître, mais à mesure que « les leçons de l’approche DevOps s’internalisent dans de nouvelles entreprises et de nouveaux projets, les jeunes dans le coup vont cesser d’en parler ». « Le vrai travail pour les entreprises sera de trouver comment mettre le DevOps des petites équipes à l’échelle des grandes entreprises. De nombreux experts risquent de mal interpréter la situation et de déclarer que le DevOps est mort en 2019 », a encore expliqué M. Kersten.

Selon Mark Madden, directeur de la transformation numérique et des technologies émergentes chez CGI UK, cela pourrait signifier une évolution dans les types d’entreprises qui envisagent de le déployer. « En 2019, la façon dont les gens réagiront à l’approche DevOps va aussi évoluer, passant de la curiosité à l’acceptation », a encore déclaré M. Madden. « Déjà, quelques entreprises leaders dans les secteurs des services publics et des services financiers, à l’avant-garde de l’adoption DevOps, ont évoqué les économies de coûts et les gains en productivité dont elles ont bénéficié grâce à l’automatisation dérivée du DevOps. « Leurs concurrents s’appuient sur ces bons résultats pour alimenter la demande au sein de leurs entreprises. Ces industries qui, jusque-là, méprisaient ces progrès, nous approchent activement pour savoir comment le DevOps pourrait résoudre certains de leurs problèmes métiers ».

Les outils

Edson Yanaga, directeur de l’expérience développeurs chez Red Hat, pense que les microservices pourraient « atteindre un plateau de la productivité » et devenir une « source de désillusion », pour reprendre l’expression de Gartner. « Je pense que, l’an prochain, certaines équipes et entreprises vont commencer à parler de leurs échecs dans l’adoption des microservices. Ces retours d’expériences vont nous permettre de nous rendre compte que les microservices ne sont pas une panacée – rien ne l’est – mais qu’ils sont très utiles dans certaines situations particulières », a-t-il déclaré, ajoutant qu’il s’attend à « une certaine consolidation » des meilleures pratiques. Selon lui, les développeurs vont également se rendre compte que les architectures orientées messages sont « plus adaptées à la plupart des cas d’usages en entreprise » que le HTTP/REST. Apache Kafka va continuer à gagner en popularité, et le service mesh Istio lancé par Google-IBM va également gagner en importance.

Kunal Agarwal, CEO d’Unravel Data, est d’accord pour dire que Kafka va continuer à gagner en popularité de même que Spark, mais qu’en 2019, TensorFlow et H2O seront les technologies de rupture. « En fait, l’écosystème d’outils sur lequel l’équipe DevOps doit s’appuyer va s’étendre », a-t-il déclaré. « Je suis impatient de voir comment les gens vont gérer la configuration d’Istio sur leur architecture distribuée », a expliqué Edson Yanaga. « Je pense que l’outil sera intégré sur un pipeline de déploiement distinct, en utilisant un référentiel Git séparé ».

Conteneurs et Kubernetes

L’un des principaux arguments de Docker, c’est qu’en utilisant ses produits d’entreprise, les clients bénéficient des avantages des conteneurs, mais via à une interface simplifiée. Ce qui signifie que les utilisateurs n’ont pas besoin de connaître les tenants et aboutissants précis de tous les éléments constitutifs des outils pour en tirer profit. La Cloud Native Foundation a reconnu plus tôt cette année que Kubernetes pouvait être difficile à maîtriser pour les développeurs en termes de complexité et qu’il faudra des efforts concertés de la communauté pour simplifier le système d’orchestration de conteneurs.

Edson Yanaga de Red Hat estime pour sa part que les outils autour des conteneurs vont s’améliorer. « Des domaines comme le débogage, l’emballage, les éditeurs de code et autres ont encore des années de retard sur les outils des environnements non conteneurisés », a-t-il ajouté. « Nous n’atteindrons pas la maturité l’année prochaine, mais je pense que les choses s’améliorent en ce qui concerne l’expérience de développement des conteneurs ». Il fait remarquer qu’en 2018, « de nombreuses plates-formes FaaS (Fonction-as-a-Service) basées sur Kubernetes ont été créées et qu’en 2019, il y aura sans doute une standardisation du modèle de programmation FaaS sur Kubernetes ». « La Cloud Native Computing Foundation (CNCF) ou la Fondation Eclipse peuvent mener des projets de ce type », a-t-il ajouté. « Cette standardisation permettra une consolidation de la plate-forme à long terme ».

Chris Griggs, vice-président et directeur général EMEA de SkyTap, pense que « tout le monde va reconnaitre qu’on ne peut pas maîtriser les conteneurs sans prendre pleinement conscience du changement culturel selon lequel chacun à la responsabilité de délivrer des logiciels de qualité ». « Dans cet esprit, les équipes IT encourageront plus activement les développeurs à faire en sorte que leur code fonctionne dans le monde réel, et les équipes opérationnelles à prendre part à cette évolution en traitant leur infrastructure comme du code », a-t-il déclaré. « Comme ces équipes continuent de sur-performer, leurs succès vont créer une émulation ».

DevSecOps

La sécurité est toujours une question très importante, et cela ne va pas changer en 2019. Si la tendance est à la fusion des équipes opérationnelles et des équipes de développeurs, les meilleures pratiques en matière de sécurité devront également être intégrées à l’équipe. La bonne nouvelle c’est que les outils d’automatisation sont disponibles pour la sécurité dans les équipes DevOps, et même si l’on aura toujours besoin d’un personnel qualifié en matière de sécurité, l’automatisation d’une grande partie du travail peut permettre à l’équipe de se délester des tâches les plus pénibles.

Gary McGraw, VP de la technologie de sécurité chez Synopsys, explique que même si son entreprise a automatisé l’analyse de la sécurité au niveau du code et mène des tests d’intrusions au niveau de l’application depuis « plus d’une décennie », « on ne peut en dire autant du processus de développement d’un design ou de la modélisation des menaces ». « Le manque d’automatisation de l’analyse des risques architecturaux signifie que souvent, ce travail passe commodément à la trappe et que l’on cache la poussière sous le tapis », a déclaré M. McGraw. « Ce problème devient de plus en plus tangible à mesure que l’adoption DevOps progresse ».

Mark Madden, de CGI, est d’accord pour dire que l’an prochain il faudrait « mettre davantage l’accent sur la collaboration entre la sécurité et les développeurs ». « Une devsecops correctement intégrée permettrait d’accélérer et d’ajouter une sécurité optimisée au niveau des processus pour l’intégration et la livraison en continu (CI/CD) des versions release », a-t-il déclaré. « Elle contribue également à atténuer les menaces auxquelles peuvent exposer les nombreuses failles de sécurité qui perdurent dans le cycle de développement des applications. Car celles-ci peuvent être identifiées et corrigées si nécessaire, au lieu d’attendre la fin du cycle pour s’en préoccuper ».

chevron_left
chevron_right