Annonce de Layer0 par Limelight

Le travail d’un CDN est de servir des données depuis la périphérie aussi souvent que possible et aussi près que possible de l’utilisateur . Étonnamment, pour une technologie vieille de plus de deux décennies, les CDN d’aujourd’hui ont de la place à s’améliorer sur les deux fronts. Les équipes de développement doivent repenser la façon de faire entrer le CDN dans leur pile pour améliorer la vélocité de l’équipe et libérer les sites les plus rapides possibles.

Servez les données de la périphérie aussi souvent que possible

Dans la plupart des sites Web, le CDN est fortement utilisé pour la mise en cache des données statiques. Ces ressources telles que les images, CSS et javascript changent rarement et ne dépendent pas de la logique de l’application. Cependant, les données dynamiques, HTML et API sont rarement mises en cache. En effet, la mise en cache de ces données dépend de la logique de l’application et les CDN actuels sont déconnectés du flux de travail du développeur, ce qui rend difficile l’utilisation, le débogage et la maintenance pour les équipes.

Généralement, une équipe de développement dispose d’une « pile » de code frontal, de serveur principal et de base de données qu’elle peut développer localement, puis passe par un cycle de vie de développement logiciel (par exemple, QA, staging, etc) avant qu’il ne soit mis en production. Malheureusement, le CDN est la seule partie de la pile où cela ne se produit pas. Le CDN n’est introduit dans le processus de développement logiciel qu’à la toute fin lorsque les modifications apportées à un site sont mises en service. Cela n’est pas propice à tirer parti de la périphérie pour accélérer les applications et dans aucune autre partie de la pile (code front-end, code côté serveur ou schéma de base de données) nous n’acceptons cela.

Imaginez que vous deviez concevoir un changement de code de serveur, mais qu’on vous dise que vous ne pouviez développer que par rapport à la production – vous penseriez que c’était fou. Cependant, c’est ce que nous demandons aux développeurs de faire en ce qui concerne la périphérie. Compte tenu du risque élevé de rupture de site et de surcharge lié à la modification des configurations CDN, l’Edge est ignoré pour les données dynamiques.

En revanche, avec Layer0, les équipes peuvent tester, réviser et contrôler les versions de leur logique de périphérie tout au long du processus de développement. Cela signifie que les équipes peuvent développer localement à la périphérie et garantir des taux de réussite élevés pour les données dynamiques liées au code de l’application. La gestion de la périphérie est encore simplifiée avec EdgeJS, un langage de configuration de périphérie basé sur JavaScript, performant, déclaratif et indépendant du framework. EdgeJS peut être intégré dans l’application frontend et comme il est déclaratif, les développeurs n’ont qu’à décrire leurs objectifs plutôt que d’écrire toute la logique. Cela le rend facile à utiliser et à entretenir.

En fait, le CDN est maintenant un citoyen de première classe dans le processus de développement. Par conséquent, davantage de données sont mises en cache et les équipes sur la plate-forme sont plus productives. Justin Metros, responsable de la technologie chez Universal Standard, a partagé que Layer0 a contribué à l’agilité des développeurs et aux performances des sites Web lors de JAMstack Conn 2021, une conférence populaire pour les développeurs Web. « Grâce à Layer0, notre vitesse de développement a considérablement augmenté », a-t-il déclaré. Un autre développeur nous a dit : « C’est ce dont j’avais besoin et je ne savais pas que je le voulais. » La plateforme est pratique, expressive et fiable, ce qui en fait le CDN que les équipes de développement adorent.

Servez les données de la périphérie aussi près que possible de l’utilisateur

En plus de servir les données de la périphérie aussi souvent que possible, les CDN doivent également les servir aussi rapidement que possible. (Bien que techniquement, ils doivent le servir avec la latence la plus faible possible, pour cette discussion, nous supposerons que la distance est approximativement corrélée avec la latence.) Historiquement, les CDN mettent en cache le contenu sur un ensemble géographiquement distribué de nœuds de cache appelés points de présence ou POP.

Comme les autres CDN, Limelight Networks possède de nombreux POP. En fait, avec plus de 135 POP à travers le monde, Limelight possède le deuxième plus grand réseau mondial de POP et est très susceptible d’avoir une présence proche de vos utilisateurs. Sur Layer0 de Limelight, ces POP vont au-delà des fonctions moyennes d’un CDN et coordonnent les données entre elles. Si un POP ne contient pas de données, il le demandera intelligemment à un autre POP, avant même que la demande ne soit transférée au serveur d’origine.

Pour comprendre comment cela aide, considérez un jour typique où la côte est des États-Unis se réveille avant la côte ouest. Généralement, cela signifie que les POP de la côte est recevront une cache chaude, mais les POP de la côte ouest ne seront pas réchauffés jusqu’à ce que leurs utilisateurs commencent à circuler sérieusement. Grâce à la coordination DES POP, la côte ouest peut profiter des tendances du trafic de la côte est alors que leur cache commence à se réchauffer.

En outre, Limelight Networks est unique parmi les CDN en ce sens que nous exploitons notre propre backbone privé. Cela signifie que lors du routage du trafic, Limelight n’a pas à utiliser les autoroutes publiques encombrées sur Internet et peut exploiter son propre réseau privé rendant les transferts de données plus rapides et plus sécurisés.

Même alors avec tout ce réseau, il est possible de se rapprocher encore plus de l’utilisateur — et c’est ce que Layer0 fait. Grâce aux technologies de navigateur modernes, en particulier avec les travailleurs de service , notre plate-forme a un contrôle direct et programmatique du cache sur l’appareil de l’utilisateur. Layer0 utilise cette technologie de service worker pour diffuser des données dans le navigateur avant même que l’utilisateur ne les demande.

Cette technique est souvent appelée préchargement prédictif et comporte généralement quelques mises en garde. En particulier, il peut être difficile à gérer et à maintenir, et cela peut causer un trafic excessif sur le serveur puisque le navigateur demande maintenant plus de données à l’origine. Ce trafic supplémentaire peut augmenter les coûts ou, pire encore, faire tomber le serveur d’origine. Cependant, le préchargement intégré de Layer0 hiérarchise le trafic utilisateur sur le trafic prévu et comprend la configuration EdgeJS. Cela garantit que les données sont diffusées uniquement à partir de nos POP et n’imposera aucune charge supplémentaire sur le serveur d’origine.

Créez des sites mieux, plus rapidement et plus forts sur la plateforme Edge de Layer0

Lorsque toutes ces technologies sont réunies, c’est comme si le réseau avait soudainement une bande passante infinie et une latence nulle. Les données dynamiques sont non seulement mises en cache au niveau du POP, mais également disponibles sur l’appareil avant même que l’utilisateur ne les demande. Les chargements de pages sont instantanés, aussi vite que 400 millisecondes — la vitesse d’un clin d’œil. Cette vitesse est une différence de nature, pas de degré.