Ralentissez la distance entre votre application Web et Volterra App Delivery Network (ADN)

Ce blog est le début d’une nouvelle série de blogs sur des exemples réels de problèmes rencontrés par les entreprises et décrit comment le réseau de diffusion d’applications (ADN) de Volterra répond aux problèmes décrits. Ce blog spécifique détaille un défi clé en matière de performances des application Web auquel les entreprises en ligne du monde entier sont confrontées chaque jour. Ce défi est encore plus exacerbé dans la mesure où la plupart des consommateurs travaillent à domicile. Je décris comment Volterra peut aider les entreprises à « dé-distancer » leur application Web pour obtenir une amélioration de 77 % des performances de application sans nécessiter de réécriture de leur application.

Qu'est-ce que la performance des applications Web ?

Les performances d'une application Web sont généralement mesurées par le temps nécessaire pour que le contenu de la page soit visible, tel que perçu par l'utilisateur final. Les développeurs Web utilisent plusieurs mesures pour évaluer les performances de leurs applications Web, telles que First Contentful Paint, Largest Contentful Paint ou Document Complete. Dans ce blog, j'ai utilisé la mesure « Document complet » pour évaluer les performances de mon application Web. Les développeurs Web mesurent ces mesures à l'aide d'outils tels que Web Page Test, Google Lighthouse ou Rigor.

Pourquoi les performances des applications Web sont-elles importantes ?

Une légère dégradation des performances de l’application Web a un impact énorme sur l’expérience utilisateur et par conséquent sur les ventes via le portail en ligne. Le géant du commerce électronique Amazon a signalé qu'une dégradation d'une seconde des performances application entraîne une perte de revenus de 1,6 milliard de dollars. Un impact économique similaire est observé par les entreprises en ligne dans de nombreux secteurs verticaux, comme le rapporte Akamai dans ce rapport légèrement plus ancien . Google et Microsoft rapportent des chiffres d’impact économique similaires.

Ces données confirment clairement que les performances des application Web sont une priorité pour les entreprises en ligne.

Quel est le défi?

Prenons un exemple spécifique d’une entreprise en ligne dans le secteur du commerce électronique. De nombreuses entreprises de commerce électronique ont leur application Web dans un ou quelques centres de données et ces centres de données n'existent pas dans tous les pays où vivent les utilisateurs des entreprises de commerce électronique. Lorsque l'utilisateur se trouve dans un pays/une région différent du centre de données, la latence élevée du réseau entre l'utilisateur et le centre de données entraîne des temps de chargement des pages lents de près de 6 à 12 secondes. Comme mentionné ci-dessus, lorsque les temps de chargement des pages dépassent 5 secondes, la probabilité de rebond augmente à 90 %.

Déconstruisons le chargement d’une page d’application Web comme indiqué dans la figure 2

• Tout d’abord, une session SSL sécurisée est établie, ce qui nécessite 6 messages aller-retour entre le navigateur de l’utilisateur et l’application Web.
• Ensuite, l’application Web utilisera généralement les cookies du navigateur de l’utilisateur pour déterminer si l’utilisateur possède un compte auprès du fournisseur de commerce électronique.
• En fonction du cookie, si l'utilisateur possède un compte, une page de connexion lui est présentée, sinon une page de paiement en tant qu'invité lui est présentée.

Six messages juste pour configurer la session SSL sécurisée lors de la transmission sur des liens à forte latence (potentiellement des liens transatlantiques/transpacifiques) ont sûrement un impact sur les temps de chargement des pages et entraînent par conséquent une mauvaise expérience utilisateur

Comment Volterra ADN peut-il améliorer les performances des applications ?

Il existe de nombreuses techniques pour améliorer les performances des applications Web en optimisant l' application , comme la compression des images ou l'optimisation des dépendances pour réduire les temps de chargement des pages. Souvent, ces optimisations peuvent ne pas être possibles en raison des exigences commerciales qui déterminent la conception des application . Même si ces optimisations sont possibles, cela pourrait ne pas être une option envisageable car les développeurs qui ont écrit l’application ne font plus partie de l’organisation ou ne sont plus occupés à développer de nouveaux services. Par conséquent, les équipes DevOps des organisations de commerce électronique apprécient les solutions qui peuvent améliorer les performances des applications mais ne nécessitent pas de modifications de l' application.

Volterra propose deux produits VoltMesh et VoltStack, qui, combinés à l'ADN de Volterra, peuvent améliorer les performances des application jusqu'à 75 % (voir la démonstration dans la section suivante). Le produit VoltMesh de Volterra est un produit de réseau et de sécurité distribué à l'échelle mondiale qui, lorsqu'il est configuré sur l'ADN de Volterra, fournit également des capacités d'accélération des application . Le produit VoltStack de Volterra fournit un déploiement application distribuées et une gestion du cycle de vie qui permet aux utilisateurs de décharger des parties de leurs applications vers l'ADN de Volterra pour améliorer encore les performances des application .

VoltMesh et VoltStack améliorent les performances des application Web des entreprises de commerce électronique des trois manières suivantes

Solution 1 : Résiliation SSL (également appelée Déchargement TLS) sur l'ADN de Volterra

La solution la plus simple pour améliorer les performances des applications Web consiste à effectuer la terminaison de session SSL sur l’ADN global de Volterra. L'ensemble des six messages permettant de configurer la session SSL est envoyé localement au réseau mondial du pays et ne traverse pas les liaisons transatlantiques ou transpacifiques. Il y aura une session SSL persistante entre le site distant du réseau mondial Volterra et le serveur d'origine, améliorant encore les performances. Ceci peut être visualisé comme indiqué dans la figure 3.

Solution 2: Déplacer le traitement sensible à la latence, tel que le traitement des cookies, sur Volterra ADN

Pour améliorer encore les performances, les entreprises peuvent déployer des parties sensibles à la latence de leurs applications sur l'ADN. Les exemples de parties sensibles à la latence de l'application Web incluent le traitement des cookies, graphQL ou backend-for-front-end. Dans un exemple d'entreprise de commerce électronique, ils traitent généralement les cookies pour déterminer la page à afficher pour l'utilisateur, par exemple, si l'utilisateur a un compte, ils peignent la page de connexion, sinon ils peignent une page d'invité. Le traitement des cookies sur notre ADN améliore considérablement les performances par rapport au traitement des cookies dans des centres de données centralisés ou dans un cloud à l'autre bout du monde. Ceci peut être visualisé comme indiqué dans la figure 4.

Solution 3 : Déplacer le front-end de l'application Web (par exemple, le catalogue de produits) vers la périphérie, c'est-à-dire le magasin physique

De nombreux fournisseurs de commerce tels que Macy’s, Home Depot et Target disposent également de magasins physiques où les consommateurs parcourent le catalogue de produits en ligne, à l’intérieur du magasin physique, pour vérifier l’emplacement des articles et accéder aux offres/coupons. Pour améliorer l'expérience utilisateur, ils pourraient choisir de déplacer uniquement le front-end de leur application Web vers le calcul en magasin. Tous les composants restants de leur application, c’est-à-dire les bases de données, pourraient rester dans le centre de données principal, car celui-ci ne sera pas consulté aussi fréquemment que le catalogue de produits principal. Ceci peut être visualisé comme indiqué dans la figure 5.

Principes architecturaux clés à prendre en compte dans toute solution

Ce problème est fondamentalement un problème de calcul distribué sur plusieurs clouds hétérogènes. Les équipes DevOps peuvent emprunter la voie du bricolage en assemblant des solutions fragmentaires provenant de différents fournisseurs tels que des fournisseurs de cloud public, des fournisseurs de CDN ou des fournisseurs de périphérie, ou acheter une solution packagée auprès de fournisseurs de plateformes de services cloud distribués. Les défis sont mis en évidence dans la figure 6.

Voici les principes architecturaux clés que les équipes DevOps doivent prendre en compte lors de l’évaluation d’une solution.

1. Environnement d'exécution application cohérent sur plusieurs clouds : L' application des équipes DevOps sera distribuée sur leur cloud back-end, qui peut être un centre de données privé ou un cloud public, ainsi que sur leur emplacement périphérique et leur emplacement de magasin physique, qui peuvent tous être des environnements d'exécution application complètement différents. Les équipes DevOps doivent sérieusement envisager des solutions qui exploitent Kubernetes pour fournir un environnement d’exécution application cohérent sur tous ces clouds distribués. Kubernetes homogénéise les clouds et facilite le déplacement de parties d' applications à travers les clouds.
2. Routage du trafic de proximité géographique : Étant donné que le front-end de l' application peut être déployé à différents endroits (cloud, edge ou magasin physique), chaque solution doit garantir que le trafic de l'utilisateur est redirigé vers l'emplacement le plus proche où le service front-end est déployé. Et quelle que soit la solution envisagée, les équipes DevOps ne devraient pas avoir à modifier les politiques de routage Internet.
3. Équilibrage de charge global : Toute solution envisagée doit offrir un équilibrage de charge global, car les services back-end peuvent se trouver à plusieurs endroits dans le monde.
4. Politiques de sécurité uniformes des application et du réseau sur plusieurs clouds : Bien que l'emplacement des composants de l' application puisse varier en fonction de la région, toute solution envisagée doit permettre d'appliquer une politique de sécurité uniforme des application et du réseau, quel que soit le cloud dans lequel le service frontal est déployé.
5. Observabilité à partir d'un seul panneau de verre sur plusieurs clouds et sur l'ensemble des application et de la connectivité réseau : Dans un environnement cloud distribué, il est extrêmement difficile de résoudre les problèmes liés aux applications et à la connectivité dans plusieurs clouds. Toute solution envisagée doit fournir une vue unique sur la connectivité, la sécurité et les déploiements application sur plusieurs clouds.

Résultats obtenus grâce aux solutions Volterra

Configuration de test

La configuration de test décrite ci-après a été utilisée pour démontrer les améliorations de performances offertes par chacune des solutions Volterra décrites dans la section précédente : 

• L'application Web utilisée était Online Boutique , une application de démonstration de microservices cloud native de Google. L'application Web se compose de 11 microservices comme indiqué dans la figure 7

• Les performances de l'application Web ont été mesurées à l'aide de webpagetest.org
• La mesure utilisée pour déterminer les performances des applications Web dans webpagetest.org était « Document complet »
• L'entreprise est une société européenne de commerce électronique dont les centres de données sont situés à Paris
• L'utilisateur (ou client) est toujours situé à San Francisco.

Scénario de test et résultats

Les quatre scénarios suivants ont été testés et les améliorations de performances sont décrites pour chaque scénario.

Scénario de référence : Tout d’abord, je compare les performances de l’application Web avec l’utilisateur à San Francisco et l’application Web exécutée entièrement dans le centre de données de Paris, comme indiqué dans la figure 8. Les performances de l'application Web pour le scénario de base ont été mesurées à 3,5 secondes.

Solution 1 Scénario de test : Dans le test de la solution 1, l'utilisateur est toujours à San Francisco, l'application Web fonctionne toujours dans le centre de données de Paris, cependant, la session SSL est terminée sur le proxy inverse VoltMesh exécuté sur Volterra ADN à San Jose. Ce scénario est illustré dans la figure 9.

VoltMesh crée automatiquement une session SSL persistante entre le proxy inverse exécuté dans le PoP de San Jose et l'application Web exécutée dans le centre de données de Paris. Les performances de l'application Web ont été améliorées à 2,9 secondes , soit une amélioration d' environ 18 % .

Solution 2 Scénario de test : Dans le test de la solution 2, le front-end et le microservice monétaire sont déployés sur l'ADN à San Jose. Les microservices et bases de données restants fonctionnent toujours dans le centre de données de Paris. Ce scénario est illustré dans la figure 10.

La raison pour laquelle seuls les microservices frontaux et monétaires sont déplacés est que seuls ces microservices sont impliqués lors de l'activité de navigation occasionnelle des utilisateurs. Les performances de l'application Web s'améliorent à 2 secondes , soit une amélioration de 31 % par rapport aux résultats de la solution 1.

Solution 3 Scénario de test : Dans le test de la solution 3, le microservice frontal et monétaire a été déployé sur un Intel NUC standard (4 cœurs virtuels) dans un magasin physique.

La raison pour laquelle seuls les microservices frontaux et monétaires sont déplacés est que seuls ces microservices sont impliqués lors de l'activité de navigation occasionnelle des utilisateurs dans le magasin physique. Les performances de l'application Web s'améliorent à 0,8 seconde , soit une amélioration de 60 % par rapport aux résultats de la solution 2.

Résultats sommaires et valeur économique

Un résumé des résultats des tests et de la valeur économique qui en résulte est présenté dans la figure 12. La valeur économique peut être déterminée en extrapolant les améliorations en secondes avec la valeur de chaque seconde d’amélioration pour l’organisation. Par exemple, Amazon évalue chaque amélioration d'une seconde comme une valeur économique de 1,6 milliard de dollars ; par conséquent, la solution 3 fournit une valeur économique de 4,3 milliards de dollars par rapport à la valeur de référence.

Comme le montrent ces résultats, les équipes DevOps peuvent obtenir des améliorations de performances significatives sans réécrire l’ application en utilisant les trois options proposées dans ce blog tout en maintenant le même niveau de protection de sécurité pour leur application. Pour en savoir plus sur les cas d'utilisation réels de clients qui peuvent être résolus par une plate-forme cloud distribuée ou pour avoir des cas d'utilisation réels de clients à partager avec moi, n'hésitez pas à me contacter via LinkedIn ou Twitter .