Améliorer le délai de rentabilisation : Processus et parallélisation

Il y a une complainte courante à la période de Noël. On le crie du haut des toits et de dessous les branches épineuses des pins.

« Quand une lumière s'éteint, elles s'éteignent toutes ! »

C'est le cri de quelqu'un qui se retrouve coincé avec des lumières branchées sur un circuit en série. Je ne vais pas m'étendre sur les raisons pour lesquelles il en est ainsi, mais je dirai simplement qu'une seule ampoule grillée est un facteur bloquant.

Ce n’est pas le cas pour ceux qui ont la chance d’avoir des lumières branchées sur un circuit parallèle. Une ampoule peut tomber en panne tandis que les autres continuent de briller.

Qu'est-ce que cela a à voir avec le temps, la valeur et les applications? Tout. Car il s'avère que l'informatique traditionnelle fonctionne en réalité sur un circuit sériel, tandis que le développement des applications modernes se fait à toute heure sur un circuit parallèle.

Processus

Dans un blog récent , James Urquhart, directeur technique de Pivotal Global Field, présente une image importante de l'informatique continue qui se concentre, à juste titre, sur le processus plutôt que sur le produit. Il l’appelle le chemin vers la production.

L’idée d’un chemin vers la production concerne en réalité le processus et, pour l’informatique traditionnelle, la parallélisation. Ce concept est au cœur du développement application et d’architectures modernes. La décomposition même des applications en composants individuels et ciblés (parfois appelés microservices) conduit naturellement à un développement parallèle. Cela est dû au fait que des équipes plus petites travaillent sur différents composants en même temps. C'est en fin de compte ce qui fait qu'Agile fonctionne comme un mécanisme permettant d'atteindre une plus grande vélocité et de réduire le temps de rentabilisation des applications. Ce ne sont pas des équipes plus petites. Ce ne sont pas des applications plus petites. Il s’agit de la parallélisation obtenue en exploitant ces concepts dans le développement et la livraison d’ applications.

La même approche s’applique au chemin vers la production. Autrement dit, les composants de production (services) nécessaires pour mettre en œuvre l’évolutivité et garantir la sécurité des applications font partie d’un processus beaucoup plus vaste et certains d’entre eux peuvent être développés et livrés en parallèle.

Ce qui fait obstacle, c’est l’informatique traditionnelle. Série informatique. Des méthodologies de développement en cascade qui ont débordé sur le bassin de production. Nous construisons des réseaux comme des canaux série, car les données circulent en série à travers le réseau. Du routeur au pare-feu en passant par l'équilibrage de charge, le serveur d'applications et la base de données. Les données circulent selon un chemin prévisible d’un bout à l’autre du réseau. Nous mettons donc en œuvre et fournissons ces services application de la même manière : dans un processus prévisible et sérialisé qui suit naturellement le chemin des données.

Ça ne marchera plus.

Tout d’abord, parce qu’il existe désormais plusieurs chemins de données . Il ne s’agit pas uniquement des chemins de données qui traversent NS et EW, mais également de ceux qui bifurquent dans d’autres directions cardinales. NE vers un cloud pour récupérer un script. SW pour récupérer les sprites et les polices Web. WSE pour récupérer une carte et l'intégrer dans notre application.

Mais ce n’est pas seulement la distribution des chemins de données qui rend aujourd’hui nécessaire la parallélisation du chemin vers la production. C'est la recherche de l'efficacité et de la rapidité, autrement dit l'optimisation.

Parallélisation

Pour atteindre la vitesse nécessaire pour répondre aux attentes actuelles en matière de valeur, un développement parallèle est nécessaire. Pas seulement dans le développement d'applications, mais également dans l'informatique de base. Si nous examinons l’ étendue des services application utilisés par les organisations aujourd’hui , nous pouvons voir plusieurs domaines dans lesquels la parallélisation peut contribuer à accélérer le déploiement.

Ce n’est pas tant que l’informatique traditionnelle est cloisonnée. Après tout, le résultat d’une architecture de microservices est constitué de dizaines ou de centaines de petites équipes cloisonnées, chacune concentrée sur un ensemble très ciblé de fonctions application . L’informatique traditionnelle est déjà cloisonnée. Le problème est que les pratiques de développement Agile encouragent le développement parallèle au sein de ses silos, et l’informatique traditionnelle continue d’enchaîner les processus de production de manière méthodique et sérialisée.

C'est le transfert entre les équipes qui pose problème ainsi que la manière dont nous reflétons le trafic réseau sur notre chemin vers la production. Il ne s’agit pas d’un processus sériel, et chaque fois que nous pouvons paralléliser le développement et la fourniture de services, nous devrions le faire.

Cela signifie des structures d’équipe interfonctionnelles qui encouragent la collaboration le plus tôt possible.

En parallélisant les processus grâce à l’adoption de pratiques plus agiles dans toutes les entreprises, les organisations peuvent atteindre une plus grande rapidité et une plus grande efficacité sur leur chemin vers la production.

Le processus est le produit

Comme James le fait allusion, le chemin vers la production est en réalité un processus. Et les processus sont composés d’étapes. Comme vous le dira tout ninja du processus Six Sigma doté d’une ceinture noire, accélérer ce processus consiste à trouver et à éliminer les inefficacités. En production, ces inefficacités apparaissent sous forme de temps d’attente (transferts) entre les étapes rigides et sérialisées du processus de déploiement.

Les outils peuvent aider. Mais en fin de compte, l’amélioration nécessitera un examen long et approfondi des processus et une recherche d’opportunités pour paralléliser la fourniture de services application dans le cadre de votre chemin vers la production.

La culture – et plus particulièrement la culture de collaboration – n’est pas facultative. Cela a un impact très réel sur les comportements et les pratiques. La structure de l'équipe à elle seule modifie radicalement l'automatisation du pipeline, les équipes traditionnelles à fonction unique prenant du retard par rapport à leurs homologues contemporaines axées sur DevOps. Encourager des structures d’équipe plus collaboratives. Dans la même veine, une équipe collaborative doit être alignée sur des indicateurs clés. Les métriques partagées permettent à NetOps et à la sécurité de travailler vers un déploiement continu sans pénalité. À l’heure actuelle, près des trois quarts des NetOps sont mesurés en fonction du TEMPS DE DISPONIBILITÉ DU RÉSEAU. La fréquence de déploiement est à peine perceptible pour eux. Ils vont se concentrer sur le maintien du réseau, car c'est sur cela qu'ils doivent se concentrer. Les métriques partagées donnent à NetOps la permission de se concentrer sur les besoins de l'entreprise : des déploiements plus rapides et plus fréquents. 

Enfin, l’empathie est nécessaire. Vous faites tous partie de la même équipe et – cela pourrait vous surprendre – vous appréciez les mêmes choses. Les NetOps sont tout aussi susceptibles d’accorder une grande importance à l’automatisation des pipelines que les DevOps. N’oubliez pas que DevOps a dix ans d’avance sur NetOps pour surmonter les obstacles liés à l’intégration, aux outils et aux compétences. Les équipes collaboratives peuvent aider en promouvant la standardisation des outils qui s’étendent de la livraison au déploiement (comme Jenkins et GitHub/GitLab).

Le chemin vers la production n’est pas un produit. C'est un processus. Il s’agit d’un processus qui doit être collaboratif et exécuté en parallèle chaque fois que possible pour améliorer le délai de rentabilisation et permettre des déploiements application réussis.