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 en dehors du chiffre d'affaires », déclare Chris Farrell, vice-président Automation Value Services chez IBM. « Lorsque votre application est votre activité, la vitesse est à la fois une arme et un indicateur de la qualité de votre application. »

Dans ce monde de l'hyper-déploiement, Farrell estime qu'il est essentiel pour les entreprises qu'elles « inversent le scénario » dans leur manière d'envisager l'intégration et la distribution continues (CI/CD). « Plutôt que de parler du nombre de jours entre des déploiements, il faudrait parler du nombre de mises à jour par période », explique-t-il. « Plus le temps est limité, plus vous progressez. »

La série « Repenser et Automatiser » d'IBM invite les dirigeants à réinventer les processus commerciaux et IT courants en les abordant sous un angle nouveau et en adoptant l'automatisation. Le processus DevOps typique est un ensemble cyclique de huit étapes – planification, codage, génération et test, puis publication, déploiement, exploitation et surveillance. Lorsque l'une de ces huit étapes ralentit, c'est l'ensemble du pipeline qui ralentit.

« En dehors du monde numérique d'origine, l'amélioration de la vitesse peut s'avérer encore plus cruciale pour les grandes entreprises actuelles », écrit Hans A.T. d'IBM. Selon Dekkers dans « The speed of smarter architecture » (PDF, 696 ko), document publié par l'IBM Institute for Business Value : « Lorsque nous voyons 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 une tendance croissante à un taux de rotation encore plus élevé, nous voyons les effets de la vitesse – ou de son absence. »

Pour réaliser la pratique CI/CD, les développeurs doivent créer une seule fois, déployer partout et gérer le pipeline en permanence. Voici comment Farrell repenserait le cycle typique en utilisant l'automatisation, en soulignant que toute amélioration nécessite « un engagement total dans le DevOps et un désir d'atteindre et de réaliser la distribution continue ».

Passer de la surveillance à l'observabilité

« Cela peut surprendre les gens, mais si je devais entièrement repenser le processus DevOps, je me concentrerais d'abord sur la dernière étape : la surveillance », explique M. Farrell. « Il faut se débarrasser des outils de surveillance traditionnels et passer à l'observabilité le plus rapidement possible. N'oubliez pas que plus vous appliquerez l'observabilité à un grand nombre de charges de travail, plus les membres des opérations pourront remonter rapidement et précisément d'un problème à sa cause première, 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 pratiques et outils logiciels permettant d'agréger, de corréler et d'analyser un flux constant de données sur les performances provenant d'une application distribuée, ainsi que le matériel et le réseau sur lesquels elle s'exécute, afin de pouvoir dépanner et déboguer l'application et le réseau de manière plus efficace. L'observabilité est une évolution naturelle de la surveillance des performances des applications (APM) pour mieux répondre à la nature de plus en plus rapide, distribuée et dynamique des déploiements d'applications natives cloud.

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 traditionnels ont du mal à s'adapter aux pipelines accélérés et aux piles technologiques modernes, notamment parce que la configuration manuelle, la reconfiguration et/ou le redéploiement ralentissent les choses », explique Farrell. La plateforme d'observabilité offre une compréhension – une visibilité contextuelle – et s'adapte à tout changement en temps réel, ce qui signifie qu'elle est toujours à jour.

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

Automatiser l'observabilité pour gagner en rapidité et en résultats

« La nécessité de parvenir à l'observabilité est absolue, mais elle doit être automatisée », explique Farrell. Une plateforme d'observabilité automatisée dotée d'un moteur d'analyse permet à la plateforme de fournir compréhension, recommandations et mesures correctives pour les problèmes. Vous n'avez plus besoin de passer du temps à diagnostiquer les problèmes, cela se fait automatiquement.

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

Selon le rapport DORA 2018 Accelerate: State of DevOps (lien externe à ibm.com) (PDF, 1,8 Mo), les « organisations ultra-performantes » (elite performing organizations) ont des déploiements de code 46x plus fréquents, un délai de production 2 555x plus court entre la validation et le déploiement, un taux d'échec des changements 7x plus faible, et elles se remettent 2 604x plus vite 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 rapides. « L'une de mes corrélations préférées est la réduction du taux d'échec des changements, même si vous déployez plus vite », explique Farrell.

Lorsque les organisations automatisent les huit étapes du processus, elles peuvent s'attendre à une meilleure qualité et à une meilleure satisfaction des clients. Mais Farrell affirme que son avantage favori est la vitesse. « J'en ai vu la démonstration dans une banque. Il leur aurait fallu environ 10 à 12 mois pour avoir l'idée d'un produit avant que celui-ci ne soit mis en service. Une fois qu'ils ont mis en place leurs nouveaux processus DevOps, ce délai est passé à deux semaines », explique-t-il. « Vous voyez les résultats absolus et directs de la réussite sur le marché. »