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…

Puis le Cloud a émergé. Rapidement, les processus de déploiement sont devenus un frein dans un système par ailleurs très dynamique. À la même époque, GitHub et d’autres plateformes collaboratives ont facilité la coopération des développeurs, qu’ils soient dans la même équipe ou engagés dans des projets open source. Les nouvelles architectures applicatives ont considérablement amélioré l’efficacité des développeurs en limitant les risques de conflits entre différentes parties de l’application, une source majeure de travail inutile, de retours en arrière et de délais. Les architectures Microservices et Service Mesh diminuent les dépendances entre les composantes de l’application, tandis que les Conteneurs et les architectures Serverless libèrent l’infrastructure sous-jacente, permettant aux développeurs et aux équipes d’avancer à leur rythme. Vous pouvez désormais déployer vos applications en quelques minutes au lieu de plusieurs mois. Au départ, ces déploiements se limitaient aux projets de développement et de test, mais la demande pour un accès plus rapide aux systèmes de production a rapidement explosé.

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.)