Pour produire des analyses plus riches et plus rapides, les entreprises utilisent des volumes croissants de données. Cette tendance devrait se poursuivre. Un modèle d’IDC prévoit que la sphère mondiale des données aura quasiment triplé de taille d’ici 2025.
Mais cette tendance n’est pas nouvelle. Après tout, le terme Big Data nous accompagne depuis déjà un certain temps. Ce qui change, c’est la provenance des données et leur fluidité. Autrement dit, les terminaux mobiles et l’IoT – la périphérie – vont stimuler la création de données.
En outre, le traitement et l’analyse s’effectueront à différents endroits : sur les terminaux, au niveau des passerelles et dans le cloud. Ne vaudrait-il pas mieux parler de données distribuées fluides plutôt que de Big Data ?
Quoi qu’il en soit, davantage de données se traduit à terme par davantage d’opportunités commerciales viables – notamment parce que ces nouvelles données sont générées au point d’action, par les humains et les machines.
Pour tirer pleinement parti des volumes croissants de données dont elles disposent, les entreprises ont besoin d’un moyen de les gérer plus efficacement sur différentes plateformes, de la périphérie au cloud et inversement. Elles doivent traiter, stocker et optimiser différents types de données provenant de sources diverses, avec des niveaux variables de propreté et de validité. Elles doivent connecter ces données aux applications internes et leur appliquer une logique de processus métier, de plus en plus assistée par des modèles d’intelligence artificielle et d’apprentissage automatique.
C’est un défi de taille. L’une des solutions actuellement étudiées par les entreprises consiste à adopter une architecture de données. Et, à mesure que les volumes de données continuent d’augmenter à la périphérie du réseau, cette solution évoluera pour prendre plus couramment la forme d’une architecture de données en périphérie.
- Qu’est-ce qu’une architecture de données ?
- Comment l’architecture de données s’applique à l’informatique en périphérie
- Éléments communs d’une architecture de données en périphérie
- L’architecture de données en périphérie à un tournant
- Cas d’utilisation de l’architecture de données en périphérie
- Transférer l’architecture de données cloud vers la périphérie
Qu’est-ce qu’une architecture de données ?
Une architecture de données permet d’accéder facilement et de manière transparente aux données distribuées dans différentes zones – en temps réel, au sein d’une couche de données unifiée et soumise à une gestion commune. Elle permet aux opérateurs de déplacer et d’accéder aux données sur différentes plateformes de déploiement, différents processus de données, différents emplacements géographiques et selon différentes approches structurelles.
Essentiellement, une architecture de données sert à la fois de tuyauterie et de traducteur pour les données qui entrent et sortent de différentes plateformes – notamment les centres de données, le cloud public, les clouds privés et les nombreux types de passerelles et de terminaux fonctionnant en périphérie.
Comment l’architecture de données s’applique à l’informatique en périphérie
L’informatique en périphérie présente un ensemble unique de défis pour les données générées et traitées en dehors du cœur du réseau. Les terminaux eux-mêmes, qui fonctionnent en périphérie, gagnent en complexité.
Des appareils intelligents comme des automates programmables industriels (API) connectés au réseau gèrent des solénoïdes qui, à leur tour, contrôlent les flux de production d’une usine chimique, ainsi que des capteurs de pression qui déterminent le poids et des étiquettes RFID actives qui déterminent l’emplacement d’un conteneur de fret. La plupart des traitements étaient auparavant effectués dans le centre de données, mais la situation a évolué au point qu’une part plus importante des traitements a lieu dans le cloud. Dans les deux cas, le traitement s’effectue d’un côté de la passerelle.
Le centre de données était fixe et non virtuel, tandis que le cloud est fluide. Si l’on considère la définition du cloud, on comprend pourquoi une architecture de données y serait nécessaire. Le cloud repose sur la fluidité et la suppression de la notion de lieu, mais, comme le centre de données, il sert à traiter les données associées aux applications.
L’emplacement réel du cloud Salesforce, du cloud Oracle ou de tout autre cloud nous importe peut-être peu, mais nous tenons à ce que nos données transitent entre différents clouds et persistent dans chacun d’eux afin d’être utilisées dans diverses opérations.
En raison de toute cette complexité, les organisations doivent déterminer quelles parties du traitement sont effectuées à quel niveau. Il existe une application pour chaque besoin, et chaque application implique une manipulation. Chaque manipulation nécessite à son tour un traitement des données et une gestion de la mémoire.
L’objectif d’une architecture de données est de gérer toute cette complexité. Spark, par exemple, serait un élément clé d’une architecture de données dans le cloud, car il est rapidement devenu le moyen le plus simple de prendre en charge la diffusion de données en continu entre différentes plateformes cloud de différents fournisseurs.
La périphérie devient rapidement un nouveau cloud, s’appuyant sur les mêmes technologies et normes cloud, combinées à de nouveaux réseaux spécifiques à la périphérie, comme la 5G et le WLAN 6. Et, comme dans le cloud central, des applications plus riches et plus intelligentes s’exécutent sur chaque terminal, sur les passerelles et dans ce qui aurait été l’équivalent d’un centre de données installé dans un placard au cœur de l’usine, dans un avion, sur un cargo, etc. Il est logique qu’une architecture de données en périphérie analogue à celle qui se consolide dans le cloud central soit nécessaire.
Éléments communs d’une architecture de données en périphérie
Pour gérer le nombre croissant d’exigences imposées par les terminaux en périphérie, une architecture de données en périphérie doit assurer plusieurs fonctions importantes. Elle doit pouvoir :
- Accéder à de nombreuses interfaces différentes : HTTP, mttp, réseaux radio, réseaux industriels
- Fonctionner dans plusieurs environnements d’exploitation : surtout, être conforme à POSIX
- Prendre en charge les principaux protocoles et API : notamment les plus récents avec l’API REST
- Fournir une connectivité aux bases de données JDBC/ODBC : pour les applications existantes et une connexion rapide et rudimentaire entre les bases de données
- Gérer les données en continu : grâce à des normes telles que Spark et Kafka
L’architecture de données en périphérie à un tournant
Bien que les origines de l’informatique en périphérie remontent aux réseaux de diffusion de contenu des années 1990, l’architecture de données en périphérie commence à atteindre un point de bascule sur le marché.
Les principaux moteurs de l’informatique en périphérie ont changé. Pour exploiter véritablement toute cette intelligence et tous ces traitements effectués en périphérie, nous devrons abandonner la mentalité client-serveur. L’époque de la centralisation des données en un lieu unique est révolue. La majorité des données restera en périphérie.
À mesure que l’intelligence augmente en périphérie, elle exécute directement des routines automatisées. Vous intégrez directement une politique régissant cette automatisation ainsi que des consignes indiquant ce que les routines de gestion des exceptions doivent faire, puis vous les faites évoluer au fil du temps afin que rien ne doive être fait manuellement et que le processus ne s’arrête pas. Pour cela, il faut associer l’apprentissage automatique (ML) à la politique et au processus concernés, ainsi qu’à la gestion des exceptions. Ce ML doit s’exécuter sans supervision en périphérie.
Pourquoi ne pas tout déplacer dans le cloud ? Cela nécessiterait beaucoup de bande passante. Nous avons constaté qu’à chaque passage de la 2G à la 3G, puis à la 4G, à la LTE et à la 5G, la bande passante augmente fortement ; à chaque fois, nous disposons donc de toute cette nouvelle bande passante, mais à chaque fois, il est possible d’en faire toujours moins dans le cloud. À chaque fois, les volumes de données augmentent plus vite que la nouvelle bande passante. Appelons cela le paradoxe de la bande passante.
Autre raison de ne pas renvoyer les données vers le cloud : la latence. Même s’il était possible d’y transférer toutes les données, l’exécution d’un processus automatisé exige de prendre des décisions en temps réel. Prendre cette décision et la renvoyer au point d’action créerait une latence trop importante – même avec la vitesse de la 5G.
Troisième raison : la confidentialité et la sécurité. Face à tous les risques auxquels les organisations sont confrontées, le mieux est de constituer votre référence historique, de l’exécuter localement, de supprimer progressivement la référence historique du back-end, de la limiter aux données dont vous avez besoin et de supprimer les données aussi vite que possible. Si vous comptez procéder ainsi, pourquoi tout transférer dans le cloud ? Faites simplement tout en local.
Cas d’utilisation de l’architecture de données en périphérie
Une architecture de données en périphérie permettra à des communautés ouvertes d’intégrer des fonctionnalités applicatives dans des réseaux et systèmes auparavant fermés. Il pourrait notamment s’agir d’équiper des réseaux sans fil 5G de l’informatique en périphérie multi-accès (MEC), afin d’ouvrir le réseau aux développeurs et intégrateurs tiers pour qu’ils créent des réseaux de diffusion de contenu.
Une architecture de données en périphérie pourrait également ouvrir des possibilités pour une grille IoT multicouche – avec des API sur une couche, la vision industrielle sur une autre et la robotique sur une troisième – afin de permettre le partage de données entre ces couches. Pour que des fournisseurs tiers conçoivent et commercialisent une telle grille, une architecture de données en périphérie serait nécessaire.
Transférer l’architecture de données cloud vers la périphérie
Bien entendu, les données historiques issues de la périphérie devront remonter en amont vers les développeurs d’algorithmes de ML pour la conception, le réglage et la correction de la dérive. Les données clés provenant de la périphérie, comme les transactions financières, remonteront vers le cloud central, tandis que des jeux de données pertinents mais relativement restreints, concernant par exemple les informations sur les pièces ou la planification de leur installation, iront des systèmes centraux vers la périphérie.
Cela illustre la fluidité des données et, plus fondamentalement, la nécessité de connecter de manière transparente l’architecture de données en périphérie à l’architecture de données du cloud central. Étant donné que des normes comme MEC font désormais migrer les technologies cloud vers la périphérie, les perspectives d’un simple transfert de l’architecture de données cloud vers la périphérie semblent prometteuses.
À propos de l’auteur :
Lewis Carr, directeur principal du marketing produit chez Actian