Pourquoi la distribution application devrait ressembler davantage à une usine (et moins à une boutique d'artisan)

À l’époque…

À l’époque pré-cloud, la distribution application était très différente de ce qu’elle est aujourd’hui. C’est parce que rien n’évoluait plus vite que la vitesse à laquelle l’informatique pouvait se procurer et provisionner les serveurs sur lesquels les applications s’exécutaient. La planification de nouvelles applications ou de mises à jour majeures application prenait plusieurs mois, voire plusieurs années. Dans le même temps, les applications d’entreprise sont devenues de plus en plus complexes avec des listes croissantes d’interdépendances difficiles à suivre et à gérer. Des menaces de sécurité sont apparues, susceptibles de paralyser des systèmes entiers pendant plusieurs jours ou de provoquer des fuites de données mettant fin à une carrière. Même sans acteurs extérieurs malveillants, le risque de mettre en œuvre un changement qui mettrait le réseau (et les applications qu’il supportait) à genoux continuait d’augmenter parallèlement à l’indice de complexité.

Pour gérer ces risques et garantir la sécurité et la fiabilité de chaque application dont ils ont la charge, les équipes réseau et sécurité ont développé des processus et des politiques qui requéraient une révision manuelle et impliquaient généralement des politiques élaborées à la main, conçues pour répondre aux besoins uniques de chaque application. Bien que lourdes, ces procédures ne constituaient pas nécessairement des goulots d’étranglement. Ils ont souvent rythmé le processus d’approvisionnement.

Sorti d'un ciel bleu clair…

Et puis le Cloud est arrivé. Soudain, les processus de déploiement ont commencé à apparaître comme un frein dans un système pourtant en évolution rapide. À la même époque, GitHub et d’autres plateformes de codage social ont facilité la collaboration entre les développeurs sur le code, que ce soit au sein de la même équipe ou sur des projets open source. Les nouvelles architectures application ont considérablement augmenté l'efficacité des développeurs en réduisant les risques de conflit entre le travail effectué dans une partie de l' application et d'autres parties, une source majeure de travail, de reprise et de retard. Les architectures de microservices et de Service Mesh réduisent les dépendances entre les parties de l' application elle-même, tandis que les conteneurs et les architectures sans serveur réduisent les dépendances sur l'infrastructure sous-jacente, ce qui permet aux développeurs individuels et aux équipes application d'évoluer à leur propre rythme. Les développeurs peuvent désormais déployer des applications en quelques minutes plutôt qu’en plusieurs mois. Au départ, ces déploiements étaient limités aux projets de développement et de test, mais la demande pour un accès plus rapide aux systèmes de production a rapidement augmenté.

Transformation numérique: Un travail en cours

Les administrateurs réseau et les ingénieurs en sécurité ont eu du mal à suivre le rythme, en partie parce que, contrairement aux développeurs, leur expérience professionnelle était centrée sur la sécurité de l’entreprise plutôt que sur l’optimisation des flux de travail. Pour les développeurs, de nombreux concepts fondamentaux à l’origine de ce que l’on appelle le mouvement DevOps étaient déjà une seconde nature : automatisation des processus, rationalisation des systèmes, réduction des dépendances entre les systèmes et exploitation de processus et de code réutilisables lorsque cela est possible. Les administrateurs réseau et les ingénieurs en sécurité, en revanche, ont été formés comme des artisans. La nature critique de leur travail exigeait que chaque application soit traitée avec des révisions manuelles, maintenue avec des comités d'examen des modifications et gérée via des politiques élaborées à la main qui pouvaient être mises à jour (manuellement) en réponse aux conditions changeantes.

La bonne nouvelle est que, même si elles ont démarré la course loin derrière les développeurs en termes de compréhension des processus de déploiement automatisé , les équipes réseau et sécurité rattrapent leur retard .

L'usine application : Appliquer une mentalité systémique à la distribution application

Une bonne façon de penser à la transition est d’imaginer une usine application . Au lieu de politiques élaborées à la main et de processus de révision manuels, les experts en réseau et en sécurité doivent définir des politiques réutilisables, puis les transmettre aux développeurs pour qu'ils les déploient avec leurs applications dans le cadre d'un pipeline de déploiement automatisé .

Certes, c’est plus facile à dire qu’à faire. Tout comme le passage des produits artisanaux aux produits fabriqués en usine n’était pas simplement une question d’achat d’équipement lourd et de réaffectation des travailleurs à de nouveaux rôles, le passage à une approche systémique est autant une question d’état d’esprit et de culture que d’outillage et de processus. Au lieu de comités d'examen des changements et d'équipes de sécurité qui enquêtent laborieusement sur tous les vecteurs de menace de sécurité et risques de performance possibles, un système de distribution application automatisé bien conçu maintient les domaines de défaillance de petite taille pour minimiser l'impact et intègre des boucles de rétroaction efficaces pour permettre une détection et une réponse précoces. Les décisions en matière d’outillage et de pipeline doivent équilibrer la liberté du développeur et la valeur d’efficacité des services cohérents. Le système idéal offre aux développeurs une liberté maximale pour prendre des décisions concernant les outils qui ont un impact sur le développement des fonctionnalités, mais fournit un ensemble cohérent de services d'infrastructure et de sécurité compatibles multi-cloud. L’intégration de services cohérents au cœur du pipeline de distribution application réduit la dette technique et améliore l’efficacité opérationnelle et de conformité. Cela permet ensuite aux développeurs de se concentrer sur la création d’une plus grande valeur d’innovation pour l’entreprise.

(Voir l'infographie complète de F5 Application Factory en cliquant sur l'image ci-dessous.)