Edge computing : les quatre configurations possibles

Types d’architectures Edge

Une machine Edge traite les données au niveau ou à proximité des équipements qui génèrent et consomment des données. En clair, il s’agira d’un ordinateur qui exécute une application (généralement conçue pour le cloud) de traitement pour les PC des utilisateurs, leurs téléphones mobiles ou des objets connectés (IoT).

Exécuter une application cloud sur une machine Edge réduit la latence du réseau, diminue l’exposition des données aux risques de sécurité du réseau et, dans certains cas, réduit les coûts en déchargeant le traitement sur les appareils des utilisateurs finaux.

Pour l’utilisateur de cloud qui se demande s’il serait rentable de déplacer une application cloud sur site, il convient d’abord de se demander quel type d’architecture est disponible sur site. Il existe plusieurs types d’équipements Edge :

1. Des appareils finaux. Les données qui sont normalement traitées dans le cloud sont traitées directement sur les appareils des clients. Par exemple, un capteur IoT dans un véhicule autonome pourrait traiter les données localement afin d’éviter les retards qui pourraient survenir si les données devaient être déplacées vers un centre de données en cloud et inversement.
2. Une extension du cloud à proximité du site. Dans ce scénario, des serveurs traitent les données dans des datacenters qui sont gérés par des fournisseurs de services en cloud, mais qui sont géographiquement plus proches des appareils clients que les centres de données principaux des hébergeurs de cloud. Par exemple, des services en cloud comme AWS Edge Locations offrent des options de centre de données qui peuvent offrir une meilleure latence que les centres de données AWS standard.
3. Des serveurs sur site. Dans ce modèle, l’entreprise exploite des serveurs sur site pour héberger des applications cloud. Prenons l’exemple d’un détaillant qui utilise des serveurs locaux à l’intérieur d’un magasin pour exécuter une application de traitement des paiements, éliminant ainsi la nécessité de faire transiter les données vers le cloud et de les renvoyer lors du passage en caisse du client.
4. Un cache local pour un réseau de diffusion de contenu (CDN). Les CDN mettent en cache les données dans des serveurs plus proches des utilisateurs finaux. Certains diront que les CDN sont distincts des équipements Edge parce qu’ils mettent généralement les données en cache plutôt que de les traiter. Néanmoins, l’architecture CDN est un moyen d’obtenir les avantages de l’informatique en Edge, comme une latence plus faible et une exposition réduite des données au sein du réseau.

Chaque type de modèle de périphérie présente des avantages et des inconvénients. Par exemple, le modèle des appareils finaux fonctionne bien si les appareils clients sont capables de gérer cette charge de traitement de manière uniforme. Les PC ou les ordinateurs portables standard sont équipés pour cela, mais les capteurs IoT de faible puissance peuvent ne pas disposer des ressources de calcul et de stockage nécessaires pour traiter efficacement les données.

En outre, l’utilisation d’un modèle basé sur des appareils finaux peut s’avérer difficile pour les entreprises qui dépendent de nombreux types d’appareils et de systèmes d’exploitation périphériques, dont les capacités et les configurations peuvent varier.

Dans le modèle de l’extension du cloud dans un datacenter de proximité, les appareils finaux ne sont plus un facteur majeur dans l’élaboration de l’architecture, puisque les entreprises ne déchargent pas le stockage ou le traitement des données du cloud central vers les appareils des utilisateurs finaux. Au lieu de cela, elles déchargent les données vers des serveurs qui fonctionnent à la périphérie du cloud. Ces serveurs se trouvent généralement dans un centre de données plus proche des utilisateurs finaux que le cloud central.

Un modèle CDN en périphérie est facile à mettre en œuvre en raison de la variété des fournisseurs CDN qui proposent de répliquer les données sur des serveurs éparpillés dans le monde entier. L’inconvénient majeur, cependant, est que les CDN ne peuvent généralement que mettre en cache les données au lieu de les traiter, de sorte qu’ils ne sont pas idéaux pour héberger des applications géographiquement plus proches des utilisateurs finaux.

Exemples de cas d’usage pour le Edge

Pour illustrer les compromis énumérés ci-dessus, voici quelques exemples de cas où l’informatique de périphérie convient ou ne convient pas.

Parmi les bons exemples d’informatique de périphérie, on peut citer les cas suivants :

• Véhicules autonomes. Les voitures autonomes collectent de grandes quantités de données et doivent prendre des décisions en temps réel pour assurer la sécurité des passagers et des autres personnes se trouvant sur la route ou à proximité. Les problèmes de latence qui entraînent des retards de quelques millisecondes seulement peuvent avoir des conséquences profondes, comme un accident.
• Thermostats intelligents. Ces appareils génèrent relativement peu de données. En outre, certaines des données qu’ils collectent, comme les heures auxquelles les gens rentrent chez eux et ajustent le chauffage, peuvent avoir des implications en matière de protection de la vie privée. Il est pratique de conserver les données à la périphérie et cela peut contribuer à atténuer les problèmes de sécurité.
• Feux de circulation. Un feu de circulation présente trois caractéristiques qui en font un bon candidat pour l’informatique de périphérie : la nécessité de réagir aux changements en temps réel, une production de données relativement faible et des pertes occasionnelles de connectivité Internet.

Voici quelques exemples de domaines dans lesquels l’informatique en Edge ne fonctionne pas très bien :

• Sites web. Peu de sites web ont besoin des performances ou de la réactivité d’une infrastructure périphérique. Il peut être intéressant de gagner quelques millisecondes sur le temps de chargement d’une page web, mais cette amélioration vaut rarement le coût. L’exception concerne les sites web qui contiennent de grandes quantités de données ou un contenu en temps réel, comme un site qui héberge des vidéos en continu.
• Systèmes de caméras vidéo. Les vidéos génèrent beaucoup de données. Le traitement et le stockage de ces données à la périphérie ne sont pas pratiques, car cela nécessiterait une infrastructure importante et spécialisée. Il est beaucoup moins coûteux et plus simple de stocker les données dans une installation centralisée en cloud. Un système vidéo nécessitant une analyse en temps réel constitue une exception. Prenons l’exemple d’un système qui utilise la reconnaissance faciale pour déverrouiller une porte. Dans ce cas, la capacité de traiter la vidéo localement serait bénéfique pour éviter les retards qui pourraient gêner les utilisateurs.
• Systèmes d’éclairage intelligents. Les systèmes qui permettent aux utilisateurs de contrôler l’éclairage de leur maison ou de leur bureau via Internet ne génèrent pas beaucoup de données. Mais les ampoules électriques, même intelligentes, ont généralement une capacité de traitement minimale. Les systèmes d’éclairage n’ont pas non plus d’exigences en matière de latence ultra-faible ; s’il faut une ou deux secondes pour que les lumières s’allument, ce n’est probablement pas grave.

Les limites de l’informatique en Edge

Les administrateurs doivent évaluer l’efficacité de la prise en charge d’un modèle Edge avant de déplacer une charge de travail cloud au plus proche d’un site de production. Ces limites pourraient pousser les équipes à revenir à une architecture cloud traditionnelle, ce qui entraînerait une perte de temps et de ressources.

La sécurité en dehors du cloud. L’informatique Edge réduit certains risques de sécurité en minimisant le temps de transit des données, mais elle introduit également des enjeux plus complexes.

Les entreprises ne peuvent pas garantir la sécurité des données qu’elles stockent ou traitent sur des appareils d’utilisateurs finaux qu’elles ne contrôlent pas. Les attaquants peuvent exploiter toutes les vulnérabilités de ces appareils. Même dans le cas d’un modèle de cloud étendu dans un datacenter de proximité, où les entreprises conservent le contrôle de l’infrastructure Edge, le fait d’avoir plus d’infrastructures à gérer augmente la surface d’attaque.

Il est généralement plus facile de sécuriser des données en transit sur un réseau – où elles peuvent être chiffrées – que de sécuriser des données en cours de traitement sur un appareil. N’importe quelle faille de sécurité sur l’appareil pourrait exposer ces données. C’est pourquoi les inconvénients de l’informatique de périphérie en matière de sécurité pourraient l’emporter sur ses avantages.

L’informatique en Edge n’est donc pas idéale pour les charges de travail présentant des exigences élevées en matière de sécurité. Un modèle standard d’informatique en cloud, avec ses serveurs centralisés, pourrait être moins risqué pour les données sensibles ou les charges de travail soumises à des exigences de conformité particulières.

Une différence de latence en dizaines de millisecondes. L’informatique Edge améliore les performances et la réactivité des applications, car les données n’ont pas à faire d’aller-retour entre les centres de données et les clouds. Il s’agit d’un avantage clé pour les charges de travail qui nécessitent des flux de communication instantanés ou en temps réel.

Les fournisseurs de cloud continuent d’ajouter des centres de données, mais leurs installations massives sont souvent situées dans des endroits éloignés des grands centres de population. La latence est souvent un problème lorsque les charges de travail se trouvent dans des centres de données traditionnels.

Cela dit, toutes les charges de travail ne nécessitent pas une latence ultra-faible, et les avantages en matière de latence offerts par les architectures périphériques peuvent ne pas être intéressants pour toutes les charges de travail. Par rapport à une architecture en cloud traditionnelle, un réseau local n’améliore la réactivité des communications que de quelques dizaines de millisecondes.

Pour les cas d’utilisation standard, comme l’hébergement de sites web, il est peu probable que cette différence soit perceptible par les utilisateurs. Elle n’est importante que pour les cas d’utilisation qui requièrent des performances en temps réel, comme les véhicules à conduite autonome ou les dispositifs qui contrôlent les machines dans une usine.

Il convient de s’assurer que les améliorations de latence apportées par la périphérie sont nécessaires et que leurs avantages l’emportent sur des facteurs tels que le coût supplémentaire et la charge de gestion liés à l’utilisation d’une architecture de périphérie.

La quantité des données. Les entreprises doivent tenir compte de la quantité de données que leurs charges de travail vont traiter et de la capacité de leur infrastructure à les traiter efficacement.

Les charges de travail qui génèrent de gros volumes de data ont besoin d’une infrastructure étendue pour analyser et stocker ces données. Pour traiter celles-ci, un centre de données en cloud public sera probablement moins cher et, du point de vue de la gestion, plus facile à utiliser qu’une architecture périphérique.