Combler le fossé : Architectures traditionnelles et modernes
Nous sommes au milieu d’un changement important dans les architectures d’application. Selon Cisco (Global Cloud Index : (2016-2021), 85 % des nouvelles instances de charge de travail d'application sont basées sur des conteneurs. Cela implique qu'ils sont conçus et développés à l'aide d'architectures d'applications modernes qui s'appuient fortement sur les principes API-first et les microservices. Cette architecture est nettement différente de l’architecture Web traditionnelle à trois niveaux qui domine l’espace applicatif depuis qu’Internet est devenu un moyen fiable de faire des affaires.
Mais les applications traditionnelles ne sont pas prêtes de disparaître. Des études ont montré que les applications traditionnelles (héritées) ont une durée de vie plus longue que de nombreuses carrières, atteignant jusqu’à 20 ans. En effet, une étude menée par BMC a révélé que plus de 51 % des personnes interrogées avaient plus de la moitié de leurs données résidant sur un mainframe. Les répondants ont également indiqué une augmentation des volumes de transactions (59 %), des volumes de données (55 %) et de la vitesse de changement des applications (45 %).
Ces architectures sont divisées par de nombreuses caractéristiques, notamment les choix technologiques.
Les applications traditionnelles s’appuient sur des serveurs Web, des serveurs d’applications et des bases de données relationnelles. Les conteneurs, les moteurs d’application et les bases de données NoSQL sont les choix incontournables pour le développement moderne. Les applications traditionnelles résident principalement sur site et tirent parti des ressources partagées. Les applications modernes sont dans le cloud et s'attendent à ce que des ressources leur soient dédiées uniquement.
Nous trouvons également un contraste dans les architectures utilisées pour fournir les services sur lesquels toutes les applications s’appuient pour renforcer la sécurité, garantir la disponibilité et améliorer les performances. Pour être clair, la fracture ne repose pas vraiment sur l’utilisation des services applicatifs, mais sur l’efficacité des plateformes qui les fournissent.
Capacité et connexions
L'efficacité est le premier résultat souhaité de la transformation numérique selon notre rapport State of Application Services 2019. 70 % des organisations ont cité l'optimisation informatique (efficacité) plutôt que des avantages plus « à la mode » comme l'avantage concurrentiel (46 %) et les nouvelles opportunités commerciales (45 %). Dans l'enquête 2019 sur l'état des DSI, 40 % des répondants ont déclaré que l'amélioration de l'efficacité opérationnelle serait l'initiative la plus importante qui stimulerait les investissements informatiques cette année.
L'efficacité est importante. Le problème est que, parallèlement au fossé entre architectures traditionnelles et modernes, s’ajoute un fossé dans la manière dont nous définissons l’efficacité.
Les architectures de distribution traditionnelles mesurent l’efficacité en fonction de valeurs transactionnelles telles que le coût par connexion. Les systèmes ont été construits sur le principe d’une infrastructure et de ressources partagées qui exigeaient des plates-formes hautement fiables et évolutives à partir desquelles fournir des services d’application. Une plate-forme de distribution d’applications unique sert de passerelle vers plus de 130 applications différentes en moyenne. Son efficacité est basée sur le coût par connexion (capacité), et en règle générale, plus il est bas, mieux c'est. La complexité est acceptable à condition qu’une capacité élevée soit atteinte.
L’approche actuelle des applications, basée sur le cloud et les conteneurs, laisse présager une explosion d’« applications » qui nécessitent la même sécurité et la même évolutivité que leurs prédécesseurs monolithiques. On ne s’attend plus à ce qu’une seule application puisse évoluer vers des millions de connexions. Au lieu de cela, ces millions de connexions seront réparties sur des centaines (ou des milliers) d’applications de plus petite taille. Les services d’application n’ont pas besoin d’évoluer vers des millions de connexions, car les « applications » ne s’adaptent plus verticalement, mais horizontalement. Chacun d’entre eux n’est responsable que d’une petite partie des connexions globales. Les services applicatifs qui distribuent ces connexions ne nécessitent donc pas non plus une capacité aussi élevée.
Rapidité, simplicité et sécurité
L’efficacité est plutôt mesurée en fonction de la simplicité et de la rapidité. Des changements rapides et fréquents doivent être apportés pour satisfaire l’appétit croissant de l’économie numérique. Pas moins de 62 % des personnes interrogées dans le rapport 2017 SDxCentral Container and Cloud Orchestration Report déploient des conteneurs pour une vitesse de « démarrage et de démarrage plus rapide ». Près de la moitié (47 %) déploient des conteneurs spécifiquement en raison d'une gestion plus facile. Les services applicatifs doivent donc être faciles et rapides à obtenir, à déployer et à exploiter au sein des architectures modernes. C'est pourquoi l'open source domine la chaîne d'outils CI/CD et fait de NGINX un outil si attrayant pour une grande partie des communautés de développeurs et DevOps.
Les plateformes de livraison modernes ne sont pas aussi efficaces dans les architectures traditionnelles, et les plateformes de livraison traditionnelles ne sont pas aussi efficaces dans les architectures modernes. Cela est particulièrement évident lorsque nous examinons la sécurité des applications. La sécurité des applications est principalement conçue pour empêcher les attaques externes (publiques) d’atteindre les applications, les serveurs et les sources de données. Une sécurité des applications efficace et efficiente s’effectue au plus près de la source de l’attaque. Au moment où une attaque ou une charge utile malveillante est détectée par une application, il est généralement trop tard. Les ressources ont été consommées. Le malware a été diffusé. Le code malveillant s'est déjà implanté.
En termes d'architecture, cela signifie généralement que la sécurité des applications est déployée plus efficacement dans une architecture traditionnelle (NS) pour empêcher le trafic malveillant d'atteindre les applications exécutées dans l'un ou l'autre type d'environnement (c'est-à-dire moderne ou traditionnel).
Combler le fossé
En bref, cela résume la fracture architecturale existante que nous souhaitons combler avec l’ acquisition de NGINX . Les clients ont besoin d’options pour les architectures de distribution traditionnelles et modernes afin de satisfaire leur propre équation d’efficacité. Nous voyons la nécessité des deux pour permettre aux clients de combler le fossé entre les architectures traditionnelles (NS) et modernes (EW).
Aujourd’hui, les deux architectures sont valables et nécessaires pour que les entreprises réussissent à fournir des capacités numériques plus rapidement et plus fréquemment et, surtout, de la manière la plus efficace possible pour prendre en charge leur atout le plus précieux : un portefeuille d’applications multigénérationnel. Nous pensons qu’il est temps de combler ce fossé en réunissant le meilleur des architectures de distribution traditionnelles et modernes.
Pour en savoir plus sur les avantages de l'association de F5 et de NGINX, consultez un article du PDG de F5 présentant la série de blogs « Bridging the Divide ».