Informatique en périphérie et informatique en nuage : Un guide pour les développeurs modernes

L'évolution des réseaux de diffusion de contenu (CDN)

Initialement axés sur la mise en cache et la protection des serveurs d'origine, les CDN ont commencé à évoluer avec l' essor de l'informatique sans serveur. Une nouvelle idée s'est rapidement imposée : les développeurs pouvaient définir une "fonction" atomique qui s'exécute à la demande en réponse à un événement, tel qu'un nouveau téléchargement d'image ou un nouvel enregistrement dans une base de données, sans avoir à posséder et à entretenir l'infrastructure physique ou virtuelle sous-jacente.

AWS Lambda a été le premier exemple de ce nouveau paradigme en 2015. AWS Lambda@Edge a suivi en 2016, vous permettant d'adopter la même approche avec des fonctions s'exécutant au-dessus d'Amazon CloudFront - le service CDN d'AWS.

Les CDN populaires ont suivi le mouvement, en introduisant des services tels que CloudFlare Workers en 2017, Fastly Compute@Edge en 2019, et Akamai EdgeWorkers en 2019.

Et ils ne se sont pas arrêtés là ! Comme nous l'avons dit au début de cet article, l'informatique de périphérie ne consiste pas seulement à apporter des capacités de calcul à la périphérie. Dans la plupart des cas, vous avez également besoin d'une forme de stockage des données. Les CDN ont donc continué à évoluer et à proposer de nouveaux services de pointe tels que les magasins de valeurs clés, le stockage d'objets, les bases de données SQL, le redimensionnement d'images, l'inférence de l'IA, et bien d'autres encore !

Par exemple :

• La plateforme de développement de CloudFlarecomprend des servicespériphériques tels que Workers KV pour le stockage de valeurs clés, D1 pour les bases de données relationnelles SQL avec récupération ponctuelle, R2 pour le stockage d'objets sans frais de sortie, et Queues pour l'exécution de tâches asynchrones. 
• De même, sur Fastly, vous trouverez KV Store pour le stockage de paires clé-valeur, de secrets et de données de configuration, et Fanout pour le pub/sub asynchrone bidirectionnel à la périphérie.
• Et vous l'avez deviné, Akamai propose EdgeKV.
• Amazon CloudFront a introduit son CloudFront KeyValueStore en 2023.

Aujourd'hui, les CDN offrent des services dont vous vous attendez normalement à ce qu'ils ne fonctionnent que dans une région cloud (ou un centre de données), des fonctions sans serveur aux magasins de valeurs clés en passant par le stockage d'objets, les files d'attente et les bases de données relationnelles. Par coïncidence, les files d'attente, le stockage d'objets et la capacité de calcul ont été les tout premiers services du cloud annoncés en 2006, qui font aujourd'hui leur apparition à la périphérie, de manière distribuée à l'échelle mondiale.

Sous le capot, ces nouvelles plateformes de calcul utilisent différentes technologies et prennent en charge différents langages de programmation. Par exemple, CloudFlare utilise le moteur Chrome V8, qui ne prenait initialement en charge que JavaScript, mais qui a commencé à intégrer WebAssembly en 2018. D'autre part, Fastly a décidé d'utiliser WebAssembly dès le début pour son environnement sandboxing afin d'éviter certaines des limitations de latence de démarrage de V8. Cela permet à Fastly de prendre en charge de nombreux langages de programmation, tels que TypeScript, Rust, Go, .NET, Ruby et Swift.

Ouvrons une parenthèse rapide sur WebAssembly.

WebAssembly à la périphérie

WebAssembly (ou Wasm en abrégé) pourrait être le développement le plus intéressant dans ce domaine. Depuis qu'il a été annoncé en 2017 puis qu'il est devenu une recommandation du W3C en 2019, beaucoup de gens en parlent pour l'exécution dans le navigateur des binaires Wasm, mais il y a aussi beaucoup de potentiel pour l'exécution côté serveur, y compris l'edge.

Wasm vous permet d'écrire une logique commerciale dans divers langages pris en charge et de la compiler dans un fichier binaire qui s'exécute sur des runtimes Wasm tels que wasmtime de Bytecode Alliance.

Avec WASI (WebAssembly System Interface), il vous permet de composer des logiciels écrits dans différents langages avec une interface standardisée par le W3C.

Si cela vous semble familier à quelque chose de très populaire dans le monde du cloud, consultez ce tweet de 2019 du fondateur de Docker:

Les attentes à l'égard de Wasm + WASIsont donctrès élevées. Je vous encourage vivement à suivre de près la Bytecode Alliance et ses efforts pour créer des compilateurs, des moteurs d'exécution et des outils sécurisés et ouverts pour WebAssembly. L'organisation à but non lucratif a été fondée en 2019 par Mozilla, Fastly, Intel et Red Hat. Aujourd'hui, elle compte parmi ses membres d'autres acteurs du cloud et de la périphérie tels qu'Amazon, Arm, Cisco, Docker, Fermyon, Microsoft, Nginx, Shopify, Siemens et VMware.

Comparaison entre l'Edge Computing et le Cloud Computing

Revenons maintenant à notre exploration de l'informatique de pointe.

L'une des différences les plus intéressantes et les plus notables par rapport à l'informatique en nuage est que la périphérie est distribuée à l'échelle mondiale de par sa conception. Votre code et le stockage de vos données s'exécutent nativement sur des centaines de serveurs périphériques. C'est une grande différence par rapport aux architectures cloud qui commencent généralement par des applications centralisées s'exécutant dans un seul centre de données (ou dans 2 ou 3 zones de disponibilité au sein d'une région cloud).

Si de nombreuses applications peuvent facilement être exécutées de manière centralisée, si vous créez un site web ou un produit destiné à un public mondial, votre architecture impliquera certainement une certaine forme de mise en cache et de distribution du contenu. Grâce à l'informatique de périphérie, votre application de périphérie est distribuée globalement en un clic (ou une commande CLI) et s'exécute aussi près que possible de vos utilisateurs pour une latence optimisée.

Voici donc la question rhétorique.

Avez-vous encore besoin du cloud ?

En d'autres termes, le cloud est-il encore la meilleure option pour concevoir et réaliser des applications bien architecturées et évolutives en 2024 ?

Eh bien, oui !

En réalité, pour la plupart des cas d'utilisation, la périphérie a toujours besoin d'une certaine forme d'origine sur laquelle s'appuyer. L'origine est l'endroit où s'exécute la logique commerciale du code, qu'il s'agisse du backend de votre site web ou d'autres charges de travail complexes qui doivent rester centralisées (pour des raisons de commodité, de limitations techniques ou de coût).

Voyons quelles charges de travail sont susceptibles de rester dans le cloud (pour l'instant) :

• API dorsales + SGRD - Il s'agit généralement du cœur de vos bases de données d'origine et de production (il existe au moins 10 services de base de données différents rien que sur AWS).
• Stockage massif - Le cloud permet de réduire les coûts grâce au stockage à froid.
• Analyse des données - Votre entrepôt de données typique, votre lac de données et vos pipelines de données ont besoin d'un référentiel de données centralisé pour exécuter des requêtes et créer des rapports.
• IA/ML - La formation efficace et rentable nécessite des ensembles de données massifs (alors que l'inférence peut déjà s'effectuer à la périphérie).
• HPC/Simulations - Le calcul à haute performance est distribué par conception, mais généralement au sein d'un même centre de données ou d'une même région afin de réduire les frais généraux du réseau.
• Pipelines CI/CD - Celles-ci pourraient fonctionner n'importe où, mais il est probablement plus pratique et moins coûteux d'utiliser le cloud (y compris les pipelines pour déployer vos services périphériques).

En résumé, le cloud excelle dans les services à usage général, prenant en charge presque tous les types de charges de travail possibles, avec un stockage virtuellement infini et une évolutivité horizontale (au sein d'une région ou d'un petit nombre de régions pour la résilience et la reprise après sinistre).

À l'inverse, la périphérie simplifie les déploiements globaux, renforce la sécurité et permet la mise en cache pour les origines cloud tout en prenant en charge les fonctionnalités optimisées en termes de latence sans ajouter de complexité à votre application principale.

En d'autres termes, le cloud computing et l'edge computing se complètent. Ils continueront à coexister et à résoudre des problèmes techniques différents.

Architectures tenant compte des coûts

Un autre aspect intéressant à considérer est celui du coût. Comme c'est souvent le cas avec les services gérés, il faut choisir entre l'utilisation d'une solution prête à l'emploi et la conception, l'élaboration et la maintenance de votre propre solution distribuée à l'échelle mondiale.

La périphérie étant optimisée pour la distribution globale de contenu, elle permet souvent de réduire les frais de sortie. Cependant, le stockage des données en périphérie doit être réparti sur des centaines de serveurs en périphérie, ce qui fait que le stockage et les opérations de données semblent plus coûteux que les services de cloud régionaux, qui ne répliquent généralement les données que sur 2 ou 3 zones de disponibilité.

Examinons quelques chiffres, en nous concentrant sur le stockage de clés-valeurs pour 3 services de périphérie (CloudFlare Workers KV, Fastly KV, CloudFront KeyValueStore) et 2 services cloud (Redis serverless sur AWS et DynamoDB on-demand sur AWS) :

* pour chaque KB 

** les 25 premiers Go sont gratuits

Quelques différences et observations intéressantes :

1. CloudFlare ne facture pas le transfert de données, mais les opérations de suppression coûtent comme les opérations d'écriture.
2. Fastly ne facture pas les opérations de suppression, mais vous êtes limité à 250 000 écritures et 5 millions de lectures par mois (sauf si vous payez un supplément).
3. CloudFront KeyValueStore semble follement optimisé pour les lectures, mais les écritures sont incroyablement chères par rapport aux autres options.
4. Redis semble assez bon marché, mais vous devez garder à l'esprit que c'est 0,0038 $ par Ko, donc si vous lisez ou écrivez 5 Ko, ce sera 5 fois plus cher (ce qui reste assez bon marché).
5. DynamoDB n'est pas seulement un magasin de valeurs clés, mais il peut certainement être utilisé de cette façon, et il semble toujours un ordre de grandeur moins cher que les services de périphérie.

Bien que les services cloud puissent sembler moins chers, il est essentiel de noter qu'ils ne fonctionnent pas par défaut à l'échelle mondiale. Vous pouvez activer DynamoDB Global Tables ou Amazon ElastiCache Global Datastore (bien que cela ne soit pas compatible avec ElastiCache serverless, vous devrez donc également gérer plusieurs clusters).

Par exemple, si vous activez DynamoDB Global Tables sur 10 régions, le coût d'écriture et de stockage est multiplié par 10, il devient donc 7,60 $ pour 1M d'écritures et 3 $ pour 1Go/mois. C'est déjà plus cher que les solutions de périphérie et seulement pour 10 régions (par rapport aux centaines de serveurs de périphérie).

Cas d'utilisation du monde réel pour l'informatique en périphérie (Edge Computing)

Alors, que peut-on faire concrètement à la périphérie ? Il existe de nombreux cas d'utilisation intéressants et j'espère que cet article vous aidera à déterminer celui qui convient à votre produit.

Quelques exemples :

• Authentification: La mise en œuvre de CAPTCHA, d'une authentification sans mot de passe ou d'une validation JWT à la périphérie peut réduire la charge d'origine en effectuant des opérations sans état à la périphérie qui ne nécessitent pas d'accès à la base de données ou à d'autres ressources d'origine.
• Collecte des données: Intégrez des sources de données externes ou des destinations de données, en déchargeant le suivi côté client et côté serveur vers la périphérie afin d'éviter les SDK lourds dans les navigateurs ou les goulets d'étranglement des performances sur le serveur.
• Enrichissement basé sur la géographie: Améliorez votre site web avec un contenu "près de chez vous" stocké à la périphérie, mettez en place des redirections localisées (/en -> /fr ), le geofencing ou l'étranglement par pays à l'aide d'API de géolocalisation.
• Personnalisation du contenu: Stockez et affichez les articles récemment consultés ou les produits recommandés à la périphérie, mettez en place des murs payants pour le contenu premium ou utilisez les tests A/B pour fournir un contenu personnalisé et contextualisé tout en minimisant la complexité au niveau de l'origine.
• Optimisations SEO: Manipulez les en-têtes HTTP et les réponses HTML directement à la périphérie pour mettre en œuvre des politiques de mise en cache personnalisées, des assemblages de contenu ou des algorithmes de compression ad hoc.
• Sécurité: Intégrer des WAF (Web Application Firewalls) personnalisés ou mettre en œuvre des en-têtes secrets et une logique de contrôle d'accès personnalisée.

Vous pouvez également concevoir un produit entier ou une suite de produits qui fonctionne presque entièrement à la périphérie - exactementce que nous faisons à Edgee.

A retenir

J'espère que cet article a clarifié le fait que les CDN ne se limitent plus à la mise en cache et à la protection contre les attaques DDoS - ils fournissent désormais une multitude de services précieux aux développeurs. The Edge est une nouvelle façon de créer des applications ou d'intégrer de nouvelles fonctionnalités tout en conservant une origine rapide et simple.

WebAssembly a un grand potentiel, non seulement pour le navigateur, mais aussi pour l'exécution de binaires côté serveur et en périphérie. 

Le cloud est là pour rester. et la périphérie complète ses limites en permettant la création d'applications distribuées à l'échelle mondiale avec une latence et un coût optimisés. Je recommande personnellement de concevoir et d'élaborer des architectures tenant compte des coûts, car il s'agit d'une compétence clé pour devenir un développeur ou un architecte plus efficace.