Votre application mobile fonctionne bien dans votre environnement de test local. Les utilisateurs de Londres l'ouvrent et tout fonctionne rapidement. Les utilisateurs de Tokyo ouvrent la même version et se plaignent que le démarrage est lent, les mises à jour prennent trop de temps et certains contenus semblent retardés. Vous n'avez pas modifié l'application pour une région et pas l'autre. La différence est la distance.
C'est la raison pratique pour laquelle les développeurs finissent par demander Qu'est-ce qu'un réseau d'edge ?. Pas parce qu'ils veulent un nouveau buzzword, mais parce que les applications mondiales exposent les limites de l'envoi de chaque requête, de chaque ressource et de chaque mise à jour vers un endroit lointain.
Pour les équipes mobiles, cela devient douloureux pendant les mises à jour. Vous devez pousser une correction JavaScript, une mise à jour de la copie ou une petite modification d'actif. Certains utilisateurs le reçoivent rapidement. D'autres attendent plus longtemps, réessayent ou rencontrent des temps d'attente en fonction de leur emplacement et de la distance que la requête doit parcourir. Le réseau d'edge existe pour réduire cette lacune.
Table des matières
- Pourquoi votre application est-elle rapide à Londres mais lente à Tokyo
- La structure de base d'un réseau d'edge
- Réseau d'edge vs CDN vs calcul à l'edge
- Les avantages clés pour votre application
- Utilisations réelles de cas d'edge réseau
- Comment mettre en œuvre une stratégie d'edge
Pourquoi votre application est rapide à Londres mais lente à Tokyo
Un utilisateur appuie sur l'icône de votre application à Londres. L'application vérifie les configurations fraîches, télécharge quelques actifs et continue. Un utilisateur à Tokyo fait la même chose, mais chaque requête doit voyager plus loin pour atteindre votre infrastructure. Même si chaque requête ne ressent que légèrement plus lent, les applications mobiles effectuent souvent plusieurs requêtes de suite. C'est là que les utilisateurs commencent à décrire l'application comme « lente au hasard »
Le concept manquant est la latence de réseau. Si vous souhaitez une mise à jour pratique, ce guide sur la latence de réseau dans les applications mobiles connecte l'idée directement à la compréhension des développeurs de l'apparence de l'application. Un
réseau d'edge résout cela en déplaçant le traitement réseau et le traitement plus près de l'emplacement de l'utilisateur. Au lieu de forcer chaque appareil à communiquer avec un point d'origine lointain, le système peut servir les demandes à partir d'un emplacement proche. Intel décrit un réseau d'edge comme une architecture distribuée qui déplace les fonctions de calcul, de stockage et de réseau depuis un nuage central vers des points de présence géographiquement plus proches, réduisant ainsi la distance que les données doivent parcourir pour chaque demande, comme expliqué dans l'aperçu d'Intel sur l'architecture du réseau d'edge Pourquoi cela compte plus maintenant.
Ceci n'est plus un infrastructure de niche. Une projection dit que d'ici
2025, 75% des données générées par les entreprises seront créées et traitées à l'extérieur d'un centre de données centralisé ou d'un nuage 75%et que le marché du calcul à l'extrémité est projeté de croître de $47,0 milliard en 2023 à context:Page/area: Live updates product page. Role: Short UI label or navigation item. Message key `live_update_dynamic_label_to` (Live Update Dynamic Label To).$171,0 milliard par 2031 selon.
les prévisions de l'industrie de calcul à l'extrémité
Vos utilisateurs n'expérimentent pas « l'architecture ». Ils expérimentent l'attente, les retentements et le comportement incohérent par région.
Pour un développeur mobile, cela se traduit par une règle simple. Si votre application a des utilisateurs mondiaux, votre système de mise à jour, vos actifs et votre chemin d'actualisation doivent se comporter de manière mondiale également. Sinon, votre application n'est rapide que pour les personnes qui se trouvent près de votre infrastructure.
L'Architecture de Base d'un Réseau à l'Extrémité
La manière la plus simple de comprendre un réseau à l'extrémité est de cesser de penser aux serveurs et de commencer à penser à la logistique. Un système de cloud traditionnel fonctionne comme unEverything lives in un seul grand entrepôt.
Quoi qu'il en soit, où se trouve le client, chaque commande est expédiée à partir de cette localisation. C'est simple à gérer, mais ce n'est pas idéal lorsque les clients sont répartis sur plusieurs continents.Un réseau d'edge ressemble plus à un système de
magasins de détail ou entrepôts locaux.
Un nuage central versus des points de présence proches. Un diagramme illustrant l'architecture du réseau d'edge avec un centre de données central, des nœuds d'edge et des appareils de terminaison.Dans le réseau d'edge, ces emplacements locaux sont souvent appelés points de présenceou
PoPs. Ils sont géographiquement répartis et constituent des endroits où le trafic peut être reçu, traité, sécurisé et parfois mis en cache avant de nécessiter de frayer avec le système central.
Ceci compte également pour les mises à jour. Si votre application vérifie une nouvelle charge de bundle web, un fichier de configuration ou un package d'actifs à l'ouverture, chaque tour supplémentaire apparaît dans le comportement de démarrage. Les équipes qui surveillent cela bénéficient généralement de la mise en place de la surveillance de la performance dans les applications __CAPGO_KEEP_0__ performance monitoring in Capacitor apps Le cache, la routage et le traitement local
Trois pièces font le modèle cliquer pour la plupart des développeurs :
Le cache stocke du contenu fréquent à proximité.
- Si beaucoup d'utilisateurs demandent les mêmes actifs d'application ou le package d'actualisation, le lieu de l'edge peut conserver une copie prête au lieu de la récupérer à chaque fois de l'origine. La routage envoie les utilisateurs vers le meilleur point d'entrée proche.
- Imaginez-le comme un contrôle de circulation. Le réseau essaie d'éviter d'envoyer un utilisateur sur un chemin long ou congestionné lorsque un chemin plus proche existe. Le traitement local gère le travail simple avant que le nuage central ne soit impliqué.
- Cela peut inclure le filtrage, les vérifications d'authentification, la gestion des requêtes ou la préparation des données avant qu'elles ne soient envoyées vers le haut. Règle pratique :
Règle pratique: If le même objet est demandé à plusieurs reprises par les utilisateurs dans de nombreux endroits, il est probable qu'il ne devrait pas être récupéré à partir d'une origine lointaine pour chaque demande individuelle.
C'est la réponse de base à « qu'est-ce qu'un réseau de bord » en anglais simple. Il s'agit d'une façon distribuée de placer les fonctions réseau plus près des utilisateurs afin que les demandes courantes se terminent plus rapidement et avec moins de chances d'erreur.
Le cloud n'est pas supprimé. Le cloud devient le principal entrepôt, tandis que les emplacements de bord deviennent les magasins de proximité qui éliminent la distance de l'expérience utilisateur.
Réseau de bord vs CDN vs Edge Computing
Ces trois termes se mélangent constamment et la confusion est compréhensible car ils se chevauchent dans les produits réels.
Un développeur entend que le fournisseur a « livraison de bord », « calcul de bord » et « CDN mondial », et cela ressemble à la même chose. Ce n'est pas le cas.
Où les développeurs se mélangent généralement
A Un CDN est généralement le concept le plus facile. Sa tâche est principalement de mettre en cache et livrer du contenu comme des images, des fichiers JavaScript, des feuilles de style, des segments de vidéo et des actifs téléchargeables à partir de lieux proches des utilisateurs.
Calcul à l'extrémité est plus large. Cela signifie exécuter la logique d'application ou le traitement de données près de l'utilisateur ou de l'appareil, et non seulement stocker des fichiers de cache là.
Le réseau à l'extrémité est la couche de connectivité distribuée sous-jacente qui rend ces modèles possibles. Neos Networks décrit l'effet principal de performance comme le retard global inférieur, et explique que en traitant les données sur les serveurs d'extrémité avant qu'elles ne parviennent au nuage central, les réseaux à l'extrémité permettent aux charges de travail sensibles à la latence, telles que l'analyse temps réel et l'inference d'IA, dans son explication de réseau à l'extrémité et réduction de retard.
Cette distinction compte pour les équipes d'applications :
- Si vous voulez une livraison d'image ou de bundle plus rapide, vous pouvez ne pas avoir besoin que le cache soit de type CDN.
- If vous souhaitez que le traitement des requêtes ou la prise de décision se fasse près des utilisateurs, vous entrez dans le domaine de l'informatique de bord.
- If vous souhaitez que tout le chemin soit géographiquement plus proche et à faible latence, vous parlez de réseau de bord.
If vous travaillez sur le comportement de mise à jour, les chemins d'initialisation ou les temps de requête, cette collection d'articles sur performances réseau pour les équipes d'applications est un sujet de compagnie utile.
Edge Network vs. CDN vs. Informatique de bord en un coup d'œil
| Attribut | Réseau de bord | CDN (Réseau de diffusion de contenu) | Informatique de bord |
|---|---|---|---|
| Mission principale | Déplacer les fonctions réseau plus près des utilisateurs et des appareils | Cache et délivre du contenu de manière efficace | Exécutez code ou traitez les données près des utilisateurs ou appareils |
| Charge de travail typique | Gestion de la circulation de requêtes, gestion du trafic, services de réseau local | Actifs statiques, fichiers téléchargeables, livraison de médias | Logique API, filtrage, inférence, traitement en temps réel |
| Lieu où les travaux ont lieu | Au points distribués près des utilisateurs | Au emplacements de cache distribués | Au serveurs d'edge ou appareils près de la source |
| Meilleur modèle mental | Le réseau routier et les points d'entrée voisins | La tablette locale avec des articles populaires déjà en stock | Le travailleur local gérant les tâches sur place |
| Ce que les développeurs mobiles remarquent | Un délai inférieur tout au long du chemin de requête | Des chargements et téléchargements d'actifs plus rapides | Des décisions plus rapides sans appeler toujours l'origine |
Un CDN peut faire partie d'une stratégie d'edge, mais cela ne signifie pas automatiquement que votre application effectue du calcul d'edge.
Cette phrase clé clarifie la plupart des débats d'architecture.
Les avantages clés pour votre application
Une fois que l'architecture devient claire, les avantages deviennent plus faciles à évaluer. Vous n'achetez pas « edge » comme un étiquette. Vous choisissez une façon de réduire la distance, d'éliminer les déplacements inutiles et de garder les applications utilisables lorsque les réseaux ne sont pas parfaits.
Des réponses plus rapides que les utilisateurs peuvent ressentir
IBM décrit le réseau d'edge comme le déplacement de nombreuses tâches de calcul loin du traitement des centres de données vers les appareils d'edge, améliorant la vitesse, la bande passante et la fiabilité en réduisant la latence. Un exemple IBM note que les vitesses de téléchargement atteignent 384 Kbps, ou environ 2 à 3 fois plus rapide que les réseaux classiques pour ce scénario, comme l'explique IBM dans son explication de comment les réseaux de bord améliorent la vitesse.
Pour les applications mobiles, les utilisateurs ne pensent pas en Kbps. Ils pensent en moments :
- Le splash screen disparaît plus rapidement.
- La vérification des mises à jour se termine sans attendre embarrassant.
- L'application semble moins fragile sur les réseaux faibles.
- Un petit correctif arrive avant que les tickets de support ne s'accumulent.
Si votre équipe essaie de lancer des applications full-stack rapidementEn effet, il est utile de se rappeler que la vitesse de livraison n'est pas seulement un problème de flux de travail pour les développeurs. C'est aussi un problème de chemin d'infrastructure.
Plus de résilience lorsque les réseaux sont encombrés
Les systèmes distribués peuvent continuer à servir le trafic même lorsque l'un des chemins ou emplacements a des problèmes. En pratique, cela signifie que les utilisateurs ne sont pas aussi dépendants d'un origine lointaine étant atteignable, rapide et non encombrée à chaque moment.
Pour les équipes d'applications, cela se manifeste pendant les fenêtres de lancement et la réponse aux incidents. Si vous avez besoin de distribuer des actifs mis à jour ou des configurations à l'échelle mondiale, un emplacement d'edge proche souvent donne aux utilisateurs une meilleure chance de récupérer ce dont ils ont besoin sans un long trajet jusqu'au cœur.
Une bonne étape suivante est de passer en revue votre propre liste de vérification d'optimisation de la performance de l'application et marquez les parties qui sont vraiment des problèmes de distance réseau plutôt que code.
Les contrôles de sécurité plus proches du trafic
Les réseaux d'edge peuvent également améliorer la posture de sécurité car le filtrage et l'exécution peuvent se produire plus près de l'endroit où le trafic entre. Cela peut aider à stopper certains trafics non souhaités avant qu'ils ne parviennent au système central.
Conservez le travail simple près de l'utilisateur, et conservez les systèmes sources sensibles de traiter chaque demande directement.
Cela ne signifie pas que le networking d'edge fait de l'app magiquement sécurisée. Cela signifie que vous pouvez placer des protections plus tôt dans le chemin et réduire la zone d'impact sur les systèmes centraux.
Utilisations concrètes du réseau Edge dans le monde réel
La meilleure façon de rendre le réseau Edge concrètement tangible est de regarder les produits que les gens utilisent tous les jours.
Le streaming et le jeu rendent l'idée facile à voir
Les plateformes de streaming vidéo s'appuient sur une livraison proche pour que les utilisateurs puissent démarrer la lecture rapidement et éviter la surcharge. La bibliothèque de contenu centrale peut être centralisée, mais le contenu populaire est distribué plus près des spectateurs.
Les jeux en ligne ont un problème similaire avec un symptôme différent. Au lieu de la surcharge, les joueurs notent un retard, des réactions retardées ou un comportement multijoueur incohérent. Plus la distance du chemin de réseau est grande, plus ces retards peuvent être ressentis.
Ces exemples aident car ils sont visibles. Vous pouvez sentir le bénéfice immédiatement lorsque la vidéo démarre plus rapidement ou que le jeu ressent plus de réactivité.
Pourquoi les mises à jour des applications mobiles sont un problème Edge
Les mises à jour des applications mobiles sont moins évidentes, mais le même problème d'architecture est là.
Lorsque votre application vérifie une mise à jour en direct, télécharge les actifs web modifiés, les vérifie et les applique à la prochaine mise en route, le chemin de mise à jour devient partie de la qualité du produit. L'utilisateur ne s'intéresse pas à savoir si le retard est venu de la taille du paquet, de la géographie du réseau ou de la congestion de l'origine. Il sait simplement que la correction n'est pas arrivée quand il en avait besoin.
C'est pourquoi la livraison Edge compte pour les mises à jour en direct. Un service de mise à jour distribué à l'échelle mondiale peut obtenir les paquets modifiés plus près des appareils pour que le chemin de requête soit plus court et moins dépendant d'une origine.
Ainsi, un exemple pratique est Capgoqui fournit des mises à jour en temps réel pour les applications CapacitorJS et Electron à travers un réseau d'edge mondial et permet aux équipes de publier des paquets web signés, des canaux ciblés et de mettre en œuvre des correctifs sans attendre la revue des magasins d'applications. Les équipes travaillant sur des déploiements contrôlés peuvent associer cela à des mises à jour en temps réel en utilisant la segmentation des utilisateurs pour éviter d'envoyer chaque mise à jour à chaque utilisateur à la fois.
Un aperçu rapide aide à visualiser où la livraison d'edge s'insère dans le flux de mise à jour :
Lorsqu'une correction est petite mais urgente, le chemin réseau jusqu'à l'utilisateur compte presque autant que la correction elle-même.
C'est la réponse centrée sur le développeur que la plupart des articles génériques sur les réseaux d'edge manquent. Les réseaux d'edge ne sont pas seulement liés à des scénarios IoT futuristes. Ils résolvent un problème mobile très ordinaire : envoyer la mise à jour appropriée à l'utilisateur approprié rapidement, où que l'utilisateur se trouve.
Comment Mettre en œuvre une Stratégie d'Edge
Choisir une stratégie d'edge commence par les bouches de votre application, et non par la marketing du fournisseur. Si le principal problème est la livraison lente des actifs statiques, une approche axée sur le cache peut suffire. Si le problème est le retard des requêtes, l'incohérence régionale ou la fiabilité des mises à jour en temps réel, vous pouvez avoir besoin d'un ensemble d'edge plus large.
Qu'est-ce à évaluer avant de choisir un fournisseur
Utilisez une liste de sélection qui se rattache directement à votre comportement d'application :
- Emprise géographique : Votre fournisseur doit avoir une couverture où vos utilisateurs sont, et non seulement où votre équipe est basée.
- Gestion du trafic : Recherchez des contrôles de routage, de cache et de livraison qui correspondent à votre charge de travail. Les actifs d'application, les appels API et les lots de mise à jour ne se comportent pas de la même manière.
- Modèle de sécurité : Vérifiez comment le fournisseur gère le contrôle d'accès, l'encryption, les besoins de conformité et le filtrage côté bord.
- Visibilité opérationnelle : Vous avez besoin de journaux, de métriques et d'observabilité suffisante pour expliquer pourquoi une région est plus lente qu'une autre.
- Flux de travail du développeur : Les API, les intégrations CI/CD, les contrôles de retrait et la cible de version comptent autant que le design réseau brut.
Un bon processus de sélection commence par quelques questions concrètes :
- Où vivent nos utilisateurs les plus lents ?
- Quels requêtes se produisent lors du démarrage de l'application ?
- Qu'est-ce qui peut être mis en cache de manière sûre ?
- Quels éléments doivent encore être envoyés à l'origine ?
- Comment déboguerons-nous un problème de livraison régionale ?
Quand l'edge n'est pas la bonne réponse
Ne pas tous les applications ont besoin d'une infrastructure de réseau distribué à l'edge. Akamai note que le terme “edge” peut être flouet ce n'est pas une solution miracle . Le cas d'affaires dépend de la charge de travail, de la complexité opérationnelle et de la gouvernance, et pour certaines applications les gains de latence ne justifient pas la surcharge de gestion d'une architecture distribuée, comme discuté dans l'entrée du glossaire d'Akamai surce qu'est et ce n'est pas un réseau à l'edge Quand l'edge n'est pas la bonne réponse.
Une vérification utile de réalité.
Si votre application cible un public géographique restreint, a peu d'activité réseau au démarrage ou ne dépend pas de la livraison rapide d'actifs et de mises à jour, l'edge peut ajouter de la complexité sans suffisamment de gain. Plus de localisations signifient plus de composants en mouvement. Plus de composants en mouvement signifient plus de décisions à prendre sur le comportement de la cache, la cohérence de déploiement, la politique de sécurité et la surveillance.
La bonne question n'est pas « Utilisons-nous l'edge parce que les applications modernes le font ? » C'est « Quels requêtes sont actuellement trop éloignées de l'utilisateur, et est-il utile de réduire cette distance à un coût opérationnel ? »
Si votre équipe développe des applications avec CapacitorJS ou Electron et a besoin de livrer des correctifs JavaScript, CSS, config, copie ou actifs sans attendre la revue des magasins d'applications Capgo est une option conçue pour ce workflow. Elle utilise des bundles web signés, des déploiements basés sur des canaux, une protection de rollback et une livraison à l'edge pour aider les équipes à pousser des mises à jour contrôlées vers les utilisateurs à la prochaine mise à jour.
