Du monolithique au distribué : L'impact de l'évolution des applications sur les ADC

Les premiers ordinateurs des années 1940 et 1950 n’utilisaient pas vraiment applications telles que nous les connaissons aujourd’hui. Ils étaient en grande partie programmés à l’aide d’un langage machine et de cartes perforées. Les premières applications— ce que nous pourrions appeler les Applications 1.0 — ont grandi à côté des ordinateurs centraux centralisés des années 1960 et 1970, qui exploitaient des applications monolithiques conçues pour gérer des tâches telles que la paie, l’inventaire et le traitement de données de base. Ces premières applications étaient limitées à une seule base de code, à de très gros blocs de code unitaires qui fonctionnaient dans des centres de données isolés ou des bureaux d'entreprise. Imaginez un château isolé sur une colline protégé par de hauts murs et des douves, où les travailleurs se rendent pour accéder à des ressources informatiques centralisées utilisant des langages informatiques comme FORTRAN et COBOL. 

Une avancée vers le modèle application monolithique est arrivée avec les applications à trois niveaux, qui divisaient les ressources informatiques en trois couches fonctionnelles distinctes, chacune avec des applications séparées mais interconnectées. La couche de présentation, ou l'interface utilisateur, était régie par des applications de bureau telles que des logiciels de productivité des travailleurs (bonjour, WordStar), tandis que la couche logique métier comprenait un serveur application qui traitait les demandes des utilisateurs et effectuait des calculs. La couche de données, ou base de données, stocke et gère les données.    

Bien que les applications à trois niveaux offrent davantage de modularité et de flexibilité que les applications monolithiques, ce modèle reste dépendant de l’infrastructure physique du centre de données et des ressources sur site. Les applications monolithiques et à trois niveaux restent la norme dans certains secteurs, notamment la santé, la banque et le gouvernement, où les systèmes existants répondent à des exigences réglementaires strictes et où les applications critiques ne peuvent pas se permettre de temps d'arrêt.  

L’essor du commerce électronique dans les années 1990 a marqué le début de l’ère des dot-com. Les fournisseurs de services application (ASP) proposaient des services d'hébergement Web de type cloud sur le World Wide Web où les entreprises pouvaient lancer des applications Web HTML sans avoir à mettre en place leur propre infrastructure. Les applications Web étaient disponibles dans le monde entier, partout où un utilisateur disposait d’un accès par ligne commutée ou à haut débit. Ces applications ont été divisées en trois couches : Les consommateurs utilisaient Internet et des logiciels de navigation Web sur leurs ordinateurs personnels pour visiter des applications Web hébergées sur des sites ASP, tandis que les serveurs de base de données de l'ASP géraient l'achat et le stockage des données clients. Les applications Web sont toujours dominantes dans le commerce de détail en ligne et ont joué un rôle déterminant dans la conduite des opérations de commerce électronique sur le Web.  

Le début des années 2010 a été l’ère des perturbations du cloud, de nombreux pronostiqueurs prédisant la mort du centre de données sur site et l’ascension de l’informatique basée sur le cloud. Alors que l’on parle de transférer l’ensemble de l’informatique vers le cloud, de nombreuses applications ont été modernisées pour vivre dans des environnements cloud ou développées dans le cloud lui-même : applications cloud natives. 

Ces applications cloud natives ont été optimisées pour l'évolutivité et les performances du cloud, construites dès le départ sur des architectures de microservices, qui ont introduit un autre changement de paradigme dans l'évolution des applications. Les applications basées sur les microservices n’étaient plus des blocs de code autonomes et unifiés, mais assemblées à partir de petits microservices déployables indépendamment, chacun exécutant une fonction unique et pouvant communiquer avec d’autres microservices via des API. Les microservices modulaires ont été orchestrés dans des applications au sein de conteneurs portables, qui sont des instances informatiques virtualisées, autonomes et capables de fonctionner de manière cohérente dans différents environnements. Les applications basées sur des microservices offrent de nombreux avantages par rapport aux applications monolithiques ou à trois niveaux, notamment un développement d'applications plus rapide, une évolutivité améliorée, une flexibilité accrue et la réutilisabilité des services. 

Cependant, ces microservices de composants sont extraits de bibliothèques de cloud public et d’autres plates-formes distantes et relayés via des API ou d’autres mécanismes de communication. Ces éléments dispersés étaient difficiles à gérer et l’exposition de l’API augmentait la surface d’attaque de l’application, ouvrant la porte à des intrusions sur le réseau lors de la transmission de données et à des vulnérabilités potentielles dans les bibliothèques tierces. 

Aujourd’hui, les applications connaissent un autre changement de paradigme. La mort annoncée du centre de données a été grandement exagérée et de nombreux portefeuilles d’organisations actuels conservent un mélange d’applications traditionnelles et modernes qui s’exécutent dans des environnements hybrides et s’appuient sur des ressources sur site, en périphérie et dans le cloud. Cela complique encore davantage la nécessité d’une plateforme cohérente pour consolider la livraison et la sécurité des applications et des API où qu’elles se trouvent.

De plus, les applications sont de plus en plus complexes et s’appuient non seulement sur des microservices basés sur le cloud, mais également sur des flux de données en temps réel et de nouvelles formes de saisie. Pensez à une application de site Web de voyage typique. En plus des photos et du contenu alléchants sur la destination que vous avez choisie, vous disposez de moteurs en temps réel accessibles via API pour réserver des chambres d'hôtel, des vols aériens et des locations de voitures, de liens vers des prévisions météorologiques en direct et de fonctionnalités de cartographie interactive. Ces applications modernes sont hautement interconnectées, multi-sources et dynamiques, s’appuyant sur des données provenant de clouds hybrides et d’environnements distribués pour offrir une expérience client robuste. 

La complexité – et la surface d’attaque – ne font qu’augmenter lorsque l’IA est ajoutée à ces applications déjà hautement intégrées. Les services basés sur l'IA, qui exploitent les données provenant de réseaux et d'appareils interconnectés, peuvent inclure des moteurs de recommandation ou des chatbots ; un site Web de voyage peut suggérer des destinations et des activités personnalisées en fonction de profils d'utilisateurs en temps réel et d'analyses prédictives, ou proposer de surveiller des algorithmes de tarification dynamique. 

Les applications d’IA gèrent des quantités massives de données et utilisent des modèles de trafic complexes, envoyant des demandes importantes et fréquentes aux magasins de données d’entreprise et aux modèles d’IA hébergés dans les usines d’IA. Les charges de travail d’IA sont généralement déployées sur des infrastructures distribuées, notamment des clouds publics, des appareils périphériques et des systèmes hybrides, exposant les applications à des risques de sécurité des données , à des attaques adverses sur les modèles d’IA et à des vulnérabilités de l’infrastructure. Ces défis rendent nécessaire de fournir une sécurité complète pour les applications riches en API unifiées avec des services de gestion du trafic et de diffusion d’applications hautes performances qui prennent en charge les applications et les charges de travail d’IA modernes, quel que soit l’endroit où elles sont déployées.