Repensons les processus IT DevOps

« De nombreuses entreprises existent grâce à leurs applications, ce qui signifie que la performance des applications est la mesure la plus critique outre le chiffre d'affaires », déclare Chris Farrell, vice-président des services logiciels d'automatisation de la valeur chez IBM. « Lorsque votre application détermine votre activité, la vitesse est à la fois une arme et un indicateur de sa qualité ».

Dans ce monde marqué par un déploiement massif, Chris Farrell estime qu'il est essentiel que les entreprises « inversent la tendance » dans leur façon d'envisager l'intégration continue et le déploiement continu (CI/CD). Il signale que « Plutôt que de parler du nombre de jours entre les déploiements, vous devriez vous concentrer sur le nombre de mises à jour par période de temps ». « Plus la période est courte, plus la progression est importante ».

La série « Repenser et automatiser » d’IBM invite les dirigeants à repenser les processus métier et informatiques courants en les abordant d’un point de vue nouveau et en adoptant l’automatisation. Le processus DevOps classique est un ensemble cyclique de huit étapes que sont la planification, le codage, le développement et les tests, suivis de la mise en service, du déploiement, de l'exploitation et de la surveillance.  Lorsque l'une des huit étapes connaît une baisse de régime, c'est l'ensemble du processus qui s'en trouve ralenti.

« En dehors du monde « natif du numérique », le gain de vitesse peut être encore plus crucial pour les grandes entreprises en place », note Hans A.T. Dekkers d'IBM dans « The speed of smarter architecture », un document publié par le IBM Institute for Business Value. « Quand on voit la durée de vie moyenne des entreprises du S&P 500 passer de 60 ans (dans les années 1960) à moins de 20 ans (aujourd'hui), avec un turnover de plus en plus marqué, on mesure les effets de la rapidité, ou plutôt de son absence. »

Découvrez de nouvelles façons d’améliorer vos processus IT DevOps dans un atelier sur l’innovation en automatisation, proposé gratuitement.

Pour réussir le CI/CD, les développeurs doivent concevoir une seule fois, déployer n'importe où et gérer le processus en permanence. Voici comment Chris Farrell repenserait le cycle typique en utilisant l'automatisation, en notant que toute amélioration nécessite « un engagement absolu dans le DevOps et une volonté de parvenir à un déploiement continu ».

De la surveillance à l'observabilité

« Cela peut surprendre les gens, mais si je devais repenser le processus DevOps en repartant de zéro, je me focaliserais d'abord sur la dernière étape : la surveillance », affirme Chris Farrell. « Il faut se débarrasser des outils de surveillance classiques et adopter l'observabilité le plus rapidement possible. N'oubliez pas que plus vous appliquerez l'observabilité à un grand nombre de workloads, plus les membres de l'équipe d'exploitation pourront identifier rapidement et précisément les origines d'un problème, sans faire appel aux développeurs et aux autres experts en la matière ».

Dans le domaine des technologies de l'information, l'observabilité fait référence aux outils logiciels et aux pratiques permettant d'agréger, de corréler et d'analyser un flux constant de données de performance provenant d'une application distribuée ainsi que du matériel et du réseau sur lesquels elle s'exécute. Cela permet de dépanner et déboguer l'application et le réseau plus efficacement. L'observabilité est une évolution naturelle du suivi des performances des applications (APM) pour faire face à la nature de plus en plus dynamique, distribuée et réactive des déploiements d'applications cloud native.

En dehors de la surveillance, chaque étape du processus DevOps dispose déjà de nombreux outils qui accélèrent, intègrent et automatisent le processus. « Les outils de surveillance classiques ont du mal à s'adapter aux processus accélérés et aux piles technologiques modernes, notamment parce que la configuration manuelle, la reconfiguration et/ou le redéploiement freinent les opérations », précise Chris Farrell. La plateforme d'observabilité offre une meilleure compréhension et une visibilité contextuelle, et s'adapte à toute évolution en temps réel, ce qui signifie qu'elle est toujours à jour.

L'observabilité relie également les applications et l'infrastructure, ce qui est indispensable à mesure que s'estompent les limites entre le code de l'application, l'infrastructure basée sur le code et les piles matérielles. « Si l'on pense au besoin de rapidité dans le processus, les plateformes doivent être aussi flexibles et rapides que le code de l'application elle-même », ajoute Chris Farrell.

Automatisez l'observabilité pour plus de rapidité et de résultats

« Il est impératif de recourir à l'observabilité, mais il faut l'automatiser », poursuit Chris Farrell. Une plateforme d'observabilité automatisée dotée d'un analytics engine permet à la plateforme elle-même de fournir une compréhension, des recommandations et des solutions aux problèmes. Vous ne perdrez plus de temps à diagnostiquer les problèmes, cela se fera automatiquement.

L'automatisation du processus IT DevOps offre un certain nombre d'autres avantages outre la rapidité. Les commentaires permanents permettent aux développeurs de prendre des mesures rapides et fermes en vue d'une amélioration continue. Une meilleure identification des erreurs permet aux développeurs d'y remédier avant qu'elles ne causent ce que Chris Farrell qualifie d'impacts « catastrophiques ». Enfin, l'intégration des systèmes améliore la collaboration au sein de l'équipe, en permettant à tous les professionnels de l'informatique et du DevOps au sein d'une équipe de modifier le code, de répondre aux commentaires et de résoudre les problèmes sans ralentir leurs collègues.

Selon le rapport DORA 2018 Accelerate : State of DevOps report (Lien externe à ibm.com), les « elite performing organizations » (organisations d'élite) ont des déploiements de code 46x plus fréquents, un délai de 2 555x plus rapide entre la validation et le déploiement, un taux d'échec lié aux évolutions 7x plus faible, et sont 2 604x plus promptes à se remettre d'un incident. Vous pouvez constater l'avantage exponentiel de déploiements plus fréquents conduisant à des versions accélérées de nouveaux logiciels, et à des résolutions d'incidents des milliers de fois plus efficaces. « L'une de mes corrélations préférées est la réduction du taux d'échec des évolutions, même si le déploiement est plus rapide », confie Chris Farrell.

Lorsque les organisations automatisent les huit étapes du processus, elles peuvent s'attendre à une meilleure qualité et satisfaction client. Mais Chris mentionne que son avantage préféré est la rapidité. « Un exemple parmi d'autres serait celui d'une banque. Il lui faudrait environ 10 à 12 mois pour imaginer un produit avant qu'il ne soit lancé sur le marché. Une fois les nouveaux processus DevOps mis en place, ce délai est passé à deux semaines », explique-t-il. « Vous constatez donc les résultats concrets et tangibles de sa réussite sur le marché ».