Pourquoi Edge dévore le monde

En 1998, cinq stagiaires du MIT ont observé cela et ont eu un concept simple : dispersons les fichiers dans de nombreux centres d’information autour de la planète, se conformant aux fournisseurs de services de télécommunications pour tirer parti de leur réseau. Le concept d’un soi-disant réseau d’expédition de matériel (CDN) est né.

Les CDN ont commencé non seulement à enregistrer des images, mais également des fichiers vidéo et vraiment toutes les informations que vous pouvez imaginer. Ces points d’existence (PoP) sont au bord, soit dit en passant. Ce sont des serveurs qui sont dispersés sur la planète – parfois des centaines ou d’innombrables serveurs dans le but de conserver des copies des informations fréquemment consultées.

Alors que l’objectif initial était de fournir la bonne infrastructure et de « juste faire ça marche », ces CDN ont été difficiles à utiliser pendant plusieurs années. Une transformation de l’expérience de conception (DX) pour les CDN a commencé en 2014. Au lieu de publier les fichiers de votre site à la main et de devoir ensuite les connecter à un CDN, ces deux parties ont été regroupées. Des solutions telles que surge.sh, Netlify et Vercel (fka Now) ont vu le jour.

À l’heure actuelle, c’est une exigence absolue du marché de distribuer les actifs statiques de votre site Web au moyen d’un CDN.

D’accord, nous avons donc déplacé les propriétés statiques vers le bord. Mais qu’en est-il de l’informatique ? Et qu’en est-il des données dynamiques conservées dans des bases de données ? Pouvons-nous réduire les latences pour cela également, en le rapprochant de l’utilisateur ? Si oui, comment ?

Invitez à la périphérie

Regardons 2 éléments de la périphérie :

1. Calculez

et

2. Informations.

Dans les deux endroits, nous assistons à des innovations incroyables qui changeront complètement le fonctionnement des applications de demain.

Calculez, nous devons

Et si un entrant La requête HTTP n’a pas à aller jusqu’au centre d’information qui vit très, très loin ? Et s’il pouvait être servi directement à côté de l’utilisateur ? Invitez au calcul en périphérie.

Plus nous nous éloignons d’un centre de données central vers de nombreux centres d’information décentralisés, plus nous devons gérer un nouvel ensemble de compromis.

Au lieu de ayant la possibilité de faire évoluer un appareil robuste avec de nombreux Go de RAM pour votre application, à la périphérie, vous n’avez pas ce haut de gamme. Imaginez que vous souhaitiez que votre application s’exécute dans 500 emplacements périphériques, tous à proximité de vos utilisateurs. Acheter un appareil costaud 500 fois ne sera tout simplement pas abordable. C’est juste trop cher. Le choix est pour une configuration plus petite et plus petite.

Un modèle d’architecture qui se prête bien à ces contraintes est Serverless. Plutôt que d’héberger une machine vous-même, vous composez simplement une fonction, qui est ensuite exécutée par un système intelligent lorsque cela est nécessaire. Vous n’avez plus besoin de vous soucier de l’abstraction d’un serveur individuel : vous écrivez simplement des fonctions qui s’exécutent et évoluent essentiellement à l’infini.

Comme vous pouvez l’imaginer, ces fonctions devraient être petites et rapides. Comment pourrions-nous atteindre cela ? Qu’est-ce qu’un bon environnement d’exécution pour ces petites fonctions rapides ?

Aujourd’hui, il existe 2 réponses populaires à cette question dans l’industrie : l’utilisation d’isolats JavaScript V8 ou l’utilisation de WebAssembly (WASM).

Les isolats JavaScript V8, promus dans Cloudflare Employees, vous permettent d’exécuter un moteur JavaScript complet en périphérie. Lorsque Cloudflare a présenté les travailleurs en 2017, ils ont été les tout premiers à proposer ce nouveau modèle de calcul simplifié pour la périphérie.

Depuis, de nombreux fournisseurs, dont Stackpath, Fastly et notre bon vieux Akamai, ont lancé leurs plates-formes de calcul en périphérie également – une toute nouvelle révolution a commencé.

Un modèle de calcul alternatif au moteur JavaScript V8 qui se fournit entièrement pour la périphérie est WebAssembly. WebAssembly, qui est apparu initialement en 2017, est une innovation en croissance rapide avec de grandes entreprises comme Mozilla, Amazon, Arm, Google, Microsoft et Intel qui y investissent massivement. Il vous permet de composer du code dans n’importe quel langage et de l’assembler dans un binaire portable, qui peut s’exécuter n’importe où, qu’il reste dans un navigateur Web ou dans divers environnements de serveur.

WebAssembly est sans aucun doute l’un des développements les plus cruciaux pour le web au cours des vingt dernières années. Il alimente déjà les moteurs d’échecs et les outils de conception dans le navigateur Web, fonctionne sur la Blockchain et remplacera probablement Docker.

Information

Bien que nous ayons déjà quelques offres de calcul de pointe, le le plus grand bloqueur pour que la révolution des bords prospère est. Si vos informations se trouvent toujours dans un centre de données éloigné, vous n’obtenez rien en déplaçant votre système informatique à côté de l’utilisateur – vos informations restent le goulot d’étranglement. Pour satisfaire la principale garantie de la périphérie et accélérer les choses pour les utilisateurs, il n’y a aucune chance de trouver des solutions pour disperser également les informations.

Vous vous demandez probablement : « Ne pouvons-nous pas simplement dupliquer le des informations sur toute la planète dans nos 500 centres d’information et assurez-vous qu’elles sont à jour ? »

Bien qu’il existe des techniques uniques pour répliquer les données dans le monde entier, comme Litestream, qui a récemment signé avec fly.io , malheureusement, ce n’est pas si facile. Imaginez que vous disposez de 100 To de données qui doivent être exécutées dans un cluster partitionné de plusieurs machines. Copier ces données 500 fois n’est tout simplement pas abordable.

Des approches sont nécessaires pour pouvoir stocker de nombreuses informations tout en les ramenant à la périphérie.

En d’autres termes, avec un contrainte sur les ressources, comment pouvons-nous disperser nos données de manière intelligente et efficace, afin que nous puissions toujours disposer de ces informations rapidement à la périphérie ?

Dans un tel scénario de ressources limitées, il existe 2 approches l’industrie utilise déjà (et le fait depuis des années) : le sharding et la mise en cache.

Sharder ou ne pas sharder

Dans le sharding, vous avez divisé vos données en plusieurs ensembles de données par un certain critère. Par exemple, choisir la nation de l’utilisateur comme méthode pour décomposer les informations, afin que vous puissiez enregistrer ces données dans différentes géolocalisations.

Réaliser une structure de partitionnement de base qui fonctionne pour toutes les applications est plutôt difficile. De nombreuses recherches ont en fait eu lieu dans ce domaine au cours des dernières années. Facebook, par exemple, a développé son framework de partage appelé Shard Manager, mais même cela ne fonctionnera que sous certaines conditions et nécessite de nombreux chercheurs pour le faire fonctionner. Nous verrons encore beaucoup d’innovations dans ce domaine, mais ce ne sera pas la seule solution pour amener les données à la périphérie.

Le cache est roi

L’autre méthode est la mise en cache . Plutôt que de conserver tous les 100 To de ma base de données à la périphérie, je peux fixer une limite de 1 Go, par exemple, et ne conserver que les informations auxquelles on accède le plus régulièrement. Le simple fait de conserver les données les plus populaires est un problème bien compris en informatique, l’algorithme LRU (le moins récemment utilisé) étant l’une des options les plus populaires ici.

Vous vous demandez peut-être : « Pourquoi nous ne nous contentons pas de mettre en cache toutes les utilisations avec LRU pour nos informations à la périphérie et de l’appeler un jour ? »

Eh bien, pas si vite. Nous souhaitons que ces informations soient correctes et fraîches : Finalement, nous voulons que les informations soient cohérentes. Mais attendez! Dans la cohérence des données, vous avez une variété de ses points forts : allant de la cohérence la plus faible ou de la « cohérence éventuelle » à toute la méthode jusqu’à la « cohérence forte ». Il existe également de nombreux niveaux intermédiaires, par exemple « Lire ma propre cohérence de composition ».

La périphérie est un système dispersé. Et lorsqu’il s’agit de données dans un système distribué, les lois du théorème CAP s’appliquent. Le concept est que vous devrez faire des compromis si vous voulez que vos données soient très constantes. En termes simples, lorsque de nouvelles données sont écrites, vous ne souhaitez plus jamais voir les données plus anciennes.

Une telle cohérence dans une configuration globale n’est possible que si les différentes parties du système dispersé sont réunies par consensus sur ce qui vient de se passer, au moins quand. Cela indique que si vous avez réellement une base de données distribuée à l’échelle internationale, il faudra toujours au moins un message envoyé à tous les autres centres de données du monde entier, ce qui présente une latence inévitable. Même FaunaDB, une toute nouvelle base de données SQL fantastique, ne peut pas gérer ce fait. Honnêtement, il n’y a pas de déjeuner gratuit : si vous souhaitez une cohérence forte, vous devrez accepter qu’il s’agisse d’une surcharge de latence particulière.

Maintenant, vous pourriez vous demander : « Mais avons-nous toujours besoin forte cohérence ? » La réponse est : ça dépend. Il existe de nombreuses applications pour lesquelles une cohérence forte n’est pas nécessaire pour fonctionner. L’un d’eux est, par exemple, cette petite boutique en ligne dont vous avez peut-être entendu parler : Amazon.

Amazon a créé une base de données appelée DynamoDB, qui fonctionne comme un système dispersé avec des capacités d’échelle sévères. Néanmoins, ce n’est pas toujours totalement cohérent. Bien qu’ils l’aient rendu « aussi constant que possible » avec de nombreuses techniques intelligentes comme expliqué ici, DynamoDB ne garantit pas une cohérence forte.

Je crois qu’une génération entière d’applications aura la capacité de fonctionner très bien avec une éventuelle cohérence. En fait, vous avez probablement déjà pensé à certains cas d’utilisation : les flux de médias sociaux sont souvent un peu obsolètes, mais normalement rapides et disponibles. Les blogs et les articles fournissent quelques millisecondes ou peut-être quelques secondes de retard pour les articles publiés. Comme vous le voyez, il y a beaucoup de cas où la cohérence ultime est appropriée.

Supposons que nous sommes d’accord avec la cohérence éventuelle : qu’est-ce que nous en obtenons ? Cela signifie que nous n’avons pas besoin d’attendre qu’une modification ait été reconnue. Avec cela, nous n’avons plus de surcharge de latence lors de la distribution de nos données dans le monde entier.

Atteindre une « grande » cohérence éventuelle, néanmoins, n’est pas facile non plus. Vous devrez gérer ce petit problème appelé « invalidation du cache ». Lorsque les données sous-jacentes changent, le cache doit être mis à jour. Oui, vous l’avez pensé : c’est un problème exceptionnellement difficile. Si difficile qu’il a fini par devenir un bâillon courant dans la communauté informatique.

Pourquoi est-ce si difficile ? Vous devez garder un œil sur votre mise en cache et vous devrez l’invalider ou la mettre à jour correctement une fois que la source d’informations sous-jacente aura changé. Parfois, vous ne gérez même pas cette source d’information sous-jacente. Par exemple, pensez à utiliser une API externe comme l’API Stripe. Vous devrez développer une solution personnalisée pour révoquer ces informations.

En termes simples, c’est pourquoi nous construisons Stellate, rendant ce problème difficile plus supportable et même réalisable en équipant les concepteurs des meilleurs outils . Si GraphQL, un protocole et un schéma d’API hautement typés, n’existait pas, je vais être franc : nous n’aurions pas créé cette entreprise. Ce n’est qu’avec de fortes contraintes que vous pourrez gérer ce problème.

Je pense que les deux s’adapteront davantage à ces tout nouveaux besoins et qu’aucune entreprise privée ne peut « résoudre les données », mais plutôt nous.

Il y a beaucoup plus à dire sur ce sujet, mais pour l’instant, je sens que l’avenir de cet endroit est intense et je suis excité par ce qui va arriver.

Le futur : c’est ici, c’est maintenant

Avec toutes les avancées technologiques et les restrictions énoncées, regardons vers l’avenir. Il serait présomptueux de le faire sans mentionner Kevin Kelly.

En même temps, je reconnais qu’il est difficile d’anticiper où va notre révolution technologique, ni de savoir quels éléments concrets ou entreprises mèneront et gagner à cet endroit dans 25 ans. Il se peut que nous ayons de toutes nouvelles activités à la pointe, qui n’ont même pas encore été développées.

Il y a quelques tendances que nous pouvons anticiper, cependant, en raison du fait qu’elles ont déjà lieu aujourd’hui. Dans son livre de 2016 Inescapable, Kevin Kelly a parlé des douze principales forces technologiques qui façonnent notre avenir. Semblable au titre de son livre, voici 8 de ces forces :

Cognitive : la cognification des choses, c’est-à-dire rendre les choses plus intelligentes. Cela nécessitera de plus en plus de calculer directement là où c’est nécessaire. Il ne serait pas pratique d’exécuter la classification routière d’une voiture et d’un camion autonomes dans le cloud, n’est-ce pas ?

Flux : nous aurons un nombre croissant de flux de données réelles -les détails temporels dont dépendent les individus. Cela peut aussi être crucial pour la latence : imaginons gérer un robot pour terminer un travail. Vous ne voulez pas acheminer les signaux de contrôle sur la moitié de la planète si cela n’est pas nécessaire. Néanmoins, un flux d’infos cohérent, une application de chat, un panneau de contrôle en temps réel ou un jeu vidéo en ligne ne peut pas avoir de latence importante et nécessite donc d’utiliser la périphérie.

Filtrage : de plus en plus de choses dans nos vies auront des écrans. Des montres intelligentes aux réfrigérateurs et même à votre balance numérique. Avec cela, ces appareils seront souvent connectés à Internet, formant la nouvelle génération de la périphérie.

Partage : le développement de la collaboration à grande échelle est inévitable. Imaginez que vous traitez un document avec votre ami qui est assis dans la même ville. Eh bien, pourquoi renvoyer toutes ces données à un centre d’information à l’opposé du monde ? Pourquoi ne pas enregistrer le document juste à côté de vous deux ?

Filtrage : nous allons exploiter une personnalisation extrême afin d’attendre nos désirs. Cela pourrait vraiment être l’un des moteurs les plus importants pour le calcul des bords. Comme la personnalisation concerne un individu ou un groupe, c’est un meilleur cas d’utilisation pour exécuter Edge Calcul à côté d’eux. Cela va accélérer les choses et les millisecondes correspondent aux revenus. Nous voyons déjà cela utilisé dans les médias sociaux, mais nous constatons également une plus grande adoption dans le commerce électronique.

Engager : en nous immergeant un nombre croissant de dans notre système informatique pour tirer pleinement parti de la engagement, cette immersion sera inévitablement personnalisée et se déroulera directement ou très près des gadgets de l’utilisateur.

Suivi : Big Brother est là. Nous serons plus suivis, et c’est imparable. Plus d’unités de détection dans tout collecteront des tonnes et des tonnes de données. Ces données ne peuvent pas toujours être transportées vers le centre d’information central. Les applications du monde réel devront prendre des décisions rapides en temps réel.

Démarrer : ironiquement, le dernier mais non le moindre, est le facteur de « démarrage ». Les 25 dernières années ont fonctionné comme une plate-forme essentielle. Ne misons pas sur les tendances que nous observons. Acceptons-les afin que nous puissions produire le plus grand bénéfice. Pas seulement pour nous, les designers, mais pour l’ensemble de l’humanité. Je prévois que dans les 25 prochaines années, la merde deviendra réelle. C’est pourquoi j’affirme que la mise en cache de périphérie dévore le monde.

Comme je l’ai souligné précédemment, les problèmes auxquels nous, développeurs, sommes confrontés ne seront pas la responsabilité d’une seule entreprise, mais auront plutôt besoin de l’aide de l’ensemble de notre industrie. Vous voulez nous aider à résoudre ce problème ? Juste dire bonjour? Connectez-vous à tout moment.

.

.

Toute l’actualité en temps réel, est sur L’Entrepreneur