Pour paraphraser Charles Dickens, « c’était la meilleure des idées, c’était la pire des idées ». À quoi fais-je référence ? DevOps et à la manière dont le concept a été interprété.
La meilleure idée de DevOps, c’est l’infrastructure as code, ou IaC. Plutôt que de créer manuellement les environnements applicatifs, un processus long et sujet aux erreurs, l’IaC définit dans un modèle la manière de construire l’environnement, puis le crée automatiquement à partir de cette définition.
Cela se fait à la vitesse de l’ordinateur plutôt qu’à la vitesse humaine et, tout aussi important, de manière cohérente à chaque fois, ce qui améliore considérablement la qualité des applications. Bien appliqué, DevOps peut augmenter considérablement la vélocité des applications.
Cette approche du développement et du déploiement applicatifs a été baptisée « shift left », parce qu’elle avance les tâches post-développement dans le cycle de vie applicatif.
À lire aussi : DevOps, low-code et RPA : avantages et inconvénients
Les défis de DevOps sont pourtant nombreux
Cependant, si l’infrastructure as code de DevOps était sa meilleure idée, elle était aussi — du moins dans ses mises en œuvre courantes — l’une des pires.
Trop souvent, on demandait aux développeurs de prendre en charge la création des modèles IaC. Cela peut sembler logique : après tout, le développeur d’une application devrait être le mieux placé pour connaître ses besoins en infrastructure , n’est-ce pas ?
D’un autre côté, cela rend également les développeurs responsables de la compréhension des besoins de mise en réseau en production, des configurations de stockage à grande échelle et de la gestion des ressources nécessaires à la résilience. Face à cette charge considérable, il est juste de dire que, selon la complexité de l’environnement de production d’une application, DevOps n’est pas une panacée.
Néanmoins, inspirées par le mantra du shift left, de nombreuses organisations informatiques ont décidé qu’il était pertinent d’avancer d’autres tâches dans le cycle de vie applicatif. Les développeurs sont donc devenus responsables des tests. Et de la sécurité. Et de la gestion des correctifs.
Malheureusement, dans la pratique courante, ces tâches n’étaient pas traitées « as code ». Autrement dit, les équipes qui en étaient auparavant responsables transféraient cette responsabilité aux développeurs, ainsi que les check-lists manuelles généralement utilisées pour les réaliser. Les développeurs se retrouvaient donc avec quantité de tâches manuelles dans des domaines où ils ne possédaient aucune expertise particulière.
Et devinez quoi ? Un développeur qui effectue une tâche manuellement ne la réalise pas plus vite, surtout s’il dispose de peu d’expertise dans le domaine concerné. La vitesse potentielle d’une approche DevOps reste donc souvent bien inférieure à ce qui est souhaité.
À lire aussi : Pourquoi le cloud implique le cloud native
Le shift left de la bonne manière
Alors, quelle est la voie à suivre pour une approche du shift left fondée sur le principe du « as code » ? Les applications sont-elles condamnées à rester empêtrées dans des processus manuels exécutés par des développeurs débordés ?
En un mot, non. Mais les organisations doivent appliquer le shift left de la bonne manière. Voici trois conseils pour y parvenir.
1) Automatiser toutes les tâches
S’il est pertinent de faire de l’infrastructure as code, il est également pertinent de faire des tests as code, de la sécurité as code et de la gestion des correctifs as code. En d’autres termes, il faut appliquer la logique de DevOps à toutes les étapes du parcours vers la production.
Naturellement, cela implique d’appliquer des compétences de développement à ces tâches, ce qui nécessite, eh bien, des développeurs. Attendez-vous à ce que le profil des spécialistes du domaine (par exemple, un membre de l’équipe d’assurance qualité) évolue pour intégrer une expérience de la programmation. Cela signifie également gérer l’automatisation de chaque tâche comme une application à part entière, avec sa propre gestion du cycle de vie.
2) Traiter le parcours vers la production comme un produit automatisé
Les organisations technologiques qui affichent le parcours vers la production le plus rapide traitent l’ensemble du processus comme un produit intégré à automatiser à travers ses différentes sous-étapes. Cela implique d’automatiser les transferts entre les étapes intermédiaires et de supprimer les validations manuelles. Je pense à vous, comités de contrôle des changements.
Dans le monde réel, la plupart des étapes de validation manuelle sont des rituels formels qui cochent automatiquement les cases de la revue. Si le transfert d’une étape à l’autre peut être réduit à un simple acquiescement automatique, il peut également être automatisé, avec une gestion des exceptions clairement définie.
Cela signifie également que le parcours vers la production nécessite de gérer l’ensemble comme un produit à part entière, avec une revue d’architecture afin de s’assurer que tous les sous-systèmes automatisés fonctionnent harmonieusement ensemble.
Si cela vous semble demander du travail et des investissements, vous avez raison. Sans cela, le parcours vers la production restera lent, la vitesse aux deux extrémités (via le Dev et l’Ops) encadrant les mêmes vieilles étapes manuelles lentes au milieu.
3) Aller encore plus loin dans le shift left
Si l’automatisation de toutes les tâches — et du processus global — constitue une bonne avancée, garantir une bonne sécurité reste difficile lorsque du code vulnérable ou obsolète constitue le socle d’une application. Comme le dit le vieil adage : « garbage in, garbage out ».
Vivre avec ce type de failles de sécurité est encore pire lorsqu’une vulnérabilité est rendue publique ou qu’une personne l’exploite. S’ensuit une course folle pour mettre à jour les bases de code et intégrer les mises à jour en production.
Ce problème est endémique lorsque les développeurs partent d’une page blanche et téléchargent directement des bibliothèques et des composants depuis Internet. Il est stupéfiant de constater combien d’applications fondées sur des conteneurs sont créées à partir d’images téléchargées depuis DockerHub, alors qu’il est bien connu que nombre des plus populaires contiennent du code obsolète et/ou vulnérable.
Une bien meilleure approche consiste à fournir aux développeurs des bases de code préparées, dont on sait qu’elles sont à jour et exemptes de vulnérabilités après évaluation. Les mécanismes permettant cela sont appelés modèles, frameworks ou accélérateurs. En pratique, le développeur télécharge le modèle dans son IDE préféré et démarre avec un socle de code sûr, dans lequel il intègre les fonctionnalités de l’application.
Une fois la mise à jour de l’application terminée, celle-ci entre dans le processus automatisé décrit plus haut. Les artefacts applicatifs sont créés et franchissent les différentes étapes du cycle de vie jusqu’à leur déploiement final.
Cette approche d’hygiène du code peut être étendue au reste du cycle de vie, en mettant en place un processus indépendant d’un pipeline applicatif donné pour surveiller les vulnérabilités signalées. Lorsqu’une vulnérabilité est annoncée et qu’un correctif est disponible, un processus de compilation et de déploiement applicatif est lancé afin de mettre automatiquement à jour l’artefact concerné et de le déployer en production.
Cela évite de suivre manuellement les bibliothèques et les composants contenus dans chaque application. Cela évite également la gestion de crise associée à la nécessité de s’assurer que chaque application concernée est mise à jour, processus qui en oublie inévitablement certaines et laisse des applications vulnérables sans correctif.
Le terme qui s’impose dans le secteur pour désigner ce « shift left encore plus poussé » est celui de chaîne d’approvisionnement logicielle sécurisée. Il s’agit d’une approche appelée à se généraliser, notamment à mesure qu’un nombre croissant de processus métier basculent vers des mécanismes numériques. Je n’ai fait qu’effleurer le sujet ici et j’espère l’approfondir dans une prochaine chronique.
La vérité, c’est que DevOps est à la fois une bonne et une mauvaise idée, selon la manière dont il est appliqué. Saupoudré sur un cycle de vie applicatif léthargique, il ne résout pas grand-chose. Utilisé comme un concept d’automatisation au sein d’une chaîne d’assemblage applicative, c’est un outil puissant au service de la transformation numérique.
À lire aussi : Guide de la transformation numérique : définition, types et stratégie