BLOG

Combler le fossé : Architectures traditionnelles et modernes

Miniature de Lori MacVittie
Lori MacVittie
Publié le 17 avril 2019

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’application et des bases de données relationnelles. Les conteneurs, les moteurs d’applications et les bases de données NoSQL dominent le développement moderne. Les applications traditionnelles résident principalement sur site et exploitent des ressources partagées. Les applications modernes évoluent dans le cloud et exigent des ressources dédiées.

Nous observons aussi un contraste clair dans les architectures qui assurent les services essentiels à la sécurité, la disponibilité et la performance de toutes les applications. Pour être précis, la différence ne vient pas de l’usage des services applicatifs, mais de l’efficience des plateformes qui les délivrent.

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

L’efficacité des architectures traditionnelles de prestation se mesure par des valeurs transactionnelles telles que le coût par connexion. Nous construisons les systèmes sur le principe d’une infrastructure et de ressources partagées qui exigent des plateformes fiables et évolutives pour fournir les services applicatifs. Une seule plateforme de distribution applicative sert de passerelle à plus de 130 applications en moyenne. Nous évaluons son efficacité en fonction du coût par connexion (capacité), et plus ce coût est faible, mieux c’est. La complexité reste acceptable dès lors qu’une capacité élevée est garantie.

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é

Nous mesurons l’efficacité par la simplicité et la rapidité. Vous devez apporter des changements fréquents et rapides pour répondre à la croissance de l’économie numérique. Pas moins de 62 % des répondants au rapport 2017 SDxCentral Container and Cloud Orchestration utilisent des conteneurs pour « accélérer la mise en service et l’arrêt ». Près de la moitié (47 %) choisissent les conteneurs pour faciliter leur gestion. Vous devez pouvoir obtenir, déployer et exploiter les services applicatifs facilement et rapidement dans des architectures modernes. C’est pourquoi le logiciel libre domine la chaîne d’outils CI/CD et fait de NGINX un outil très prisé des communautés de développeurs et DevOps.

Les plateformes de livraison modernes fonctionnent peu efficacement dans les architectures traditionnelles, et les plateformes classiques ne sont pas adaptées aux environnements modernes. Ceci est particulièrement visible en matière de sécurité applicative. La sécurité applicative sert d’abord à empêcher les attaques externes (publiques) d’atteindre applications, serveurs et sources de données. Nous obtenons une sécurité efficace en agissant le plus près possible de la source de l’attaque. Quand l’attaque ou la charge utile malveillante parvient à l’application, il est souvent trop tard. Vous avez déjà consommé des ressources. Le malware est déjà distribué. Le code malveillant s’est déjà implanté.

Architecturalement, le plus efficace consiste à déployer la sécurité applicative dans une architecture traditionnelle (N-S) pour bloquer le trafic malveillant avant qu’il n’atteigne les applications, qu’elles s’exécutent dans un environnement 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 ».