Réduire le délai de création de valeur : processus et parallélisation

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

À Noël, on entend souvent la même complainte. Elle retentit du haut des toits comme sous les branches épineuses des sapins.

« Quand une ampoule s’éteint, elles s’éteignent toutes ! »

C’est le cri de quelqu’un qui se retrouve avec une guirlande lumineuse montée en série. Je ne vais pas me lancer dans un cours pour expliquer pourquoi, mais disons simplement qu’une seule ampoule grillée suffit à interrompre le circuit.

Ce n’est pas le cas de ceux qui ont la chance d’avoir des guirlandes lumineuses montées en parallèle. Une ampoule peut griller tandis que les autres continuent de briller de mille feux.

Quel est le rapport avec le délai de rentabilisation et les applications ? Tout. Car il s’avère que l’informatique traditionnelle avance vers la mise en production selon un circuit en série, tandis que le développement d’applications modernes fonctionne à plein régime, jour et nuit, sur un circuit en parallèle.

Processus

Dans un récent article de blog, le directeur technique mondial de terrain de Pivotal, James Urquhart présente une vision importante de l’informatique en continu qui privilégie, à juste titre, les processus plutôt que les produits. Il l’appelle le « parcours vers la production ».

L’idée d’un parcours vers la production repose avant tout sur les processus et, dans le cas de l’informatique traditionnelle, sur la parallélisation. Ce concept est au cœur du développement et des architectures d’applications modernes. La décomposition même des applications en composants individuels et spécialisés (parfois appelés microservices) conduit naturellement à un développement en parallèle. En effet, des équipes plus petites travaillent simultanément sur différents composants. C’est, en définitive, ce qui permet à la méthode Agile d’accélérer le rythme et de réduire le délai de création de valeur des applications. Ce ne sont pas les équipes plus petites. Ce ne sont pas les applications plus petites. C’est la parallélisation obtenue grâce à l’application de ces concepts au développement et à la livraison des applications.

La même approche s’applique au parcours de mise en production. Autrement dit, les composants de production (services) nécessaires pour assurer la montée en charge et la sécurité des applications s’inscrivent dans un processus bien plus vaste, dont certaines parties peuvent être développées et livrées en parallèle.

Ce qui fait obstacle, c’est l’informatique traditionnelle. Une informatique séquentielle. Des méthodes de développement en cascade qui ont débordé jusque dans l’environnement de production. Nous concevons les réseaux comme des chaînes séquentielles, car les données y circulent de manière séquentielle : du routeur au pare-feu, puis à l’équilibreur de charge, au serveur d’applications et enfin à la base de données. Les données suivent un parcours prévisible d’une extrémité du réseau à l’autre. Nous mettons donc en œuvre et fournissons ces services applicatifs de la même manière : selon un processus prévisible et séquentiel qui suit naturellement le cheminement des données.

Ça ne va plus fonctionner.

Tout d’abord, parce qu’il existe désormais plusieurs chemins de données. Il ne s’agit plus seulement des chemins de données orientés nord-sud et est-ouest, mais aussi de ceux qui bifurquent vers d’autres directions cardinales. Vers le nord-est, jusqu’à un cloud pour récupérer un script. Vers le sud-ouest, pour récupérer des sprites et des polices web. Vers l’ouest-sud-est, pour récupérer une carte et l’intégrer à notre application.

Mais ce n’est pas seulement la répartition des chemins de données qui rend aujourd’hui nécessaire la parallélisation du processus de mise en production. C’est aussi la recherche d’efficacité et de rapidité, autrement dit l’optimisation.

Parallélisation

Pour atteindre la vitesse nécessaire afin de répondre aux attentes actuelles en matière de délai de rentabilisation, le développement en parallèle est indispensable. Cela vaut non seulement pour le développement d’applications, mais aussi pour l’informatique de base. Si l’on considère l’étendue des services applicatifs utilisés aujourd’hui par les organisations, on constate que la parallélisation peut contribuer à accélérer le déploiement dans de nombreux domaines.

Le problème n’est pas tant que l’informatique traditionnelle fonctionne en silos. Après tout, une architecture de microservices aboutit à des dizaines, voire des centaines de petites équipes cloisonnées, chacune se concentrant sur un ensemble très ciblé de fonctions applicatives. L’informatique traditionnelle est déjà constituée de silos au sein de silos. Le problème, c’est que les pratiques de développement Agile favorisent le développement en parallèle au sein de ces silos, tandis que l’informatique traditionnelle continue d’enchaîner les processus de production de manière méthodique et séquentielle.

C’est le passage de relais entre les équipes qui pose problème, ainsi que la manière dont nous répliquons le trafic réseau tout au long du processus de mise en production. Ce processus n’est pas séquentiel et, chaque fois que nous pouvons paralléliser le développement et la livraison des services, nous devons le faire.

Cela implique des équipes pluridisciplinaires structurées de manière à favoriser la collaboration le plus tôt possible.

En parallélisant les processus grâce à l’adoption de pratiques plus agiles dans tous les domaines, les organisations peuvent gagner en rapidité et en efficacité dans leur mise en production.

Le processus est le produit

Comme James le laisse entendre, le parcours vers la production est en réalité un processus. Et tout processus se compose d’étapes. Comme vous le dira n’importe quel expert ceinture noire Six Sigma, accélérer ce processus consiste à repérer et à éliminer les inefficacités. En production, celles-ci se manifestent par des temps d’attente (passages de relais) entre les étapes rigides et séquentielles du processus de déploiement.

Les outils peuvent être utiles. Mais, en définitive, toute amélioration nécessitera un examen approfondi des processus et la recherche de possibilités permettant de paralléliser la livraison des services applicatifs dans le cadre de votre parcours vers la production.

La culture — et plus particulièrement une culture de la collaboration — n’est pas facultative. Elle a un impact très concret sur les comportements et les pratiques. À elle seule, la structure des équipes modifie radicalement l’automatisation du pipeline, les équipes traditionnelles à fonction unique se laissant distancer par leurs homologues modernes axées sur le DevOps. Encouragez des structures d’équipe plus collaboratives. Dans le même esprit, une équipe collaborative doit s’accorder sur des indicateurs clés. Des indicateurs communs permettent aux équipes NetOps et Sécurité d’œuvrer au déploiement continu sans être pénalisées. À l’heure actuelle, près des trois quarts des équipes NetOps sont évaluées sur la DISPONIBILITÉ DU RÉSEAU. La fréquence des déploiements entre à peine en ligne de compte pour elles. Elles vont donc s’attacher à maintenir le réseau opérationnel, car c’est sur cela qu’elles doivent se concentrer. Des indicateurs communs autorisent les équipes NetOps à se focaliser sur les besoins de l’entreprise : des déploiements plus rapides et plus fréquents.

Enfin, l’empathie est indispensable. Vous faites tous partie de la même équipe et, aussi surprenant que cela puisse paraître, vous accordez de l’importance aux mêmes choses. Les équipes NetOps sont tout aussi susceptibles que les équipes DevOps d’accorder une grande importance à l’automatisation des pipelines. N’oubliez pas que les DevOps ont dix ans d’avance sur les NetOps lorsqu’il s’agit d’identifier et de surmonter les obstacles liés à l’intégration, aux outils et aux compétences. Les équipes collaboratives peuvent apporter leur contribution en favorisant la standardisation d’outils couvrant l’ensemble du processus, de la livraison au déploiement (comme Jenkins et GitHub/GitLab).

Le parcours vers la production n’est pas un produit. C’est un processus. Et ce processus doit être collaboratif et mené en parallèle chaque fois que possible afin d’accélérer la création de valeur et de garantir la réussite des déploiements d’applications.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie