Intégration d'applications Edge : Une étude sur l'évolution

Vol: L'évolution convergente en pratique

La plupart d’entre nous ont rêvé de pouvoir voler ; et il s’avère que l’évolution aussi. La capacité de voler – que ce soit pour échapper aux prédateurs, chercher plus efficacement de la nourriture ou migrer sur de longues distances – a été démontrée à maintes reprises comme étant d’une grande utilité pour une grande variété d’animaux. En fait, à tel point et si fréquemment que l’évolution continue de trouver un moyen d’atteindre l’objectif du vol. Aujourd’hui, nous voyons trois groupes distincts d’animaux qui ont développé indépendamment la capacité de voler : les insectes, les oiseaux et les mammifères (chauves-souris). Chacun de ces trois groupes a suivi des chemins évolutifs différents qui ont conduit au vol, la forme actuelle de vol reflétant leurs formes ancestrales d'avant le vol. Prenons l’exemple des insectes : les insectes ancestraux avaient des exosquelettes externes, qui ont la propriété d’être de faible densité et laminés, ce qui entraîne des résistances à la traction différentes selon les dimensions. En conséquence, l’évolution des insectes vers le vol a tiré parti de l’utilisation d’ailes déformables, une approche qui a tiré parti de la faible densité et de la résistance à la traction variable des éléments constitutifs disponibles. Les oiseaux, en revanche, ont développé des plumes comme « technologie » cruciale dans leur voyage vers le vol ; dans ce cas, les plumes étaient une heureuse coïncidence, motivée par les besoins d'un groupe de dinosaures à sang chaud nécessitant un matériau semblable à de la fourrure pour retenir la chaleur. Ce n’est que plus tard que les plumes se sont révélées être une « technologie » fortuite permettant de voler. Enfin, les chauves-souris, qui sont le groupe le plus récent à avoir développé le vol, utilisent une approche basée sur l’évolution progressive des mammifères planeurs, mais ne bénéficient pas encore de millénaires d’adaptation évolutive.

Un complément intéressant et remarquable à cette histoire est l’observation selon laquelle, lorsque les humains ont finalement réussi à voler de manière pratique, en utilisant des machines, ils ont appliqué un ensemble d’approches complètement différentes : soit des appareils plus légers que l’air, soit des profils aérodynamiques rapides propulsés par des moteurs à essence.

C'était intéressant, mais qu'est-ce que cela a à voir avec le bord ?

D’un point de vue de la pensée évolutionniste, les chemins empruntés par la fourniture d’applications au cours des 20 dernières années sont également une histoire d’évolution convergente. Plus précisément, ces années ont vu le développement de multiples technologies de livraison qui, avec le recul, ont toutes été ces premières étapes évolutives naissantes vers ce qui est en train de devenir l'edge applicatif. 

Les précurseurs de bon nombre de ces technologies ancestrales étaient les réseaux de diffusion de contenu (CDN). Cette technologie a été motivée – sa « niche évolutive », pour ainsi dire – par la nécessité de fournir une grande quantité de données assez statiques, généralement de grandes images et du streaming audio/vidéo, à une communauté de clients consommateurs importante. La solution consistait à placer des copies en cache des fichiers de données volumineux dans plusieurs emplacements géographiquement dispersés, plus proches des appareils clients. Cette approche a permis de répartir la charge de travail de livraison à partir d’un seul centre de données central, en termes de calcul et de bande passante, tout en offrant simultanément une latence plus faible et plus prévisible.

Aujourd’hui, à mesure que les applications évoluent et s’intègrent étroitement à nos routines quotidiennes, la nécessité d’améliorer l’expérience applicative du client continue d’entraîner un besoin de réduire la latence et de fournir une bande passante supplémentaire. Cependant, les règles de base ont changé et évolué. Tout comme le climat et la géographie entraînent en permanence une adaptation de la nature, les changements dans les exigences de fourniture d’applications entraînent des changements dans les solutions requises. Les besoins de diffusion d’applications plus modernes s’étendent bien au-delà du scénario CDN de base. Les cas d’utilisation plus sophistiqués d’aujourd’hui doivent faire plus que simplement fournir du contenu statique simple ; ils ont également des exigences dans les domaines du calcul et de l’interactivité. Des exemples d’applications ayant des besoins plus avancés sont la vidéoconférence et le commerce électronique. Plus généralement, la tendance générale vers un paradigme d’application à page unique (SPA), dans lequel une application est composée de l’agrégation d’un certain nombre de services Web disparates, nécessite un ensemble de ressources distribuées plus robuste qu’un simple stockage statique afin de maintenir une expérience utilisateur riche. À mesure que l’environnement a « évolué » vers ces nouveaux cas d’utilisation, nous observons la convergence correspondante de multiples solutions de marché existantes s’adaptant pour mieux s’adapter à cette nouvelle et lucrative « niche évolutive » — l’analogue technologique du concept d’« évolution convergente ».

La première de ces solutions préexistantes sont les CDN susmentionnés. Leur « force » évolutive réside dans leur infrastructure existante substantielle composée d'un grand nombre de nœuds CDN existants ; leur chemin « évolutif » consiste à améliorer les nœuds existants en les faisant passer d'une concentration pure sur le stockage de type cache à une offre plus équilibrée de plusieurs technologies de stockage (fichiers, bases de données, magasins d'objets) couplées à des ressources de calcul pouvant fonctionner sur ce stockage.

Le deuxième marché en place est celui des fournisseurs de cloud public. Leur « point fort » réside dans l’écosystème robuste de ressources de calcul, de stockage et de bande passante, ainsi que dans les modèles de consommation flexibles correspondants pour ces ressources. Par exemple, AWS propose plusieurs formes de technologie de base de données, rend le calcul disponible à l'aide d'un modèle basé sur un serveur ou sans serveur, dispose d'un riche ensemble de technologies pour la gestion des identités et de l'authentification, et fournit un ensemble diversifié de services auxiliaires tels que la journalisation/création de rapports, la visualisation, la modélisation des données, etc. Cependant, leur « écart évolutif » est qu’ils n’ont pas autant de points de présence que les fournisseurs CDN existants, ils ne bénéficient donc pas de la même ampleur de distribution.

À l’autre extrémité de l’échelle des points de présence se trouvent les fournisseurs de services mobiles (MSP), en particulier lorsqu’ils déploient leurs infrastructures 5G. Les grands MSP prévoient d’avoir des dizaines de milliers de points d’accès mobiles, chacun d’entre eux étant un point d’entrée sur le réseau central. En plus de la « force » de la distribution et de l’échelle, ils disposent de capacités de calcul et de stockage limitées à ces points d’accès ; cependant, la portée du calcul et du stockage a été, jusqu’à récemment, limitée pour se concentrer sur les propres besoins d’infrastructure des MSP. Par conséquent, le « fossé » qu’ils doivent combler consiste à migrer vers un paradigme informatique qui expose l’infrastructure informatique à des applications externes et à l’augmenter avec des capacités de stockage supplémentaires.

Retour au vol et pourquoi les humains ont adopté une approche différente

Le voyage a simplement esquissé les cartes comme un processus évolutif progressif naturel. Cependant, il arrive parfois que des « facteurs de changement ^{[1] »} de l’évolution surviennent : des événements qui perturbent l’évolution et provoquent une réévaluation de la progression linéaire. Pour les humains développant le vol, le développement de systèmes capables de fournir rapidement une grande quantité d'énergie (par exemple, des moteurs à essence) couplés à des matériaux et à des technologies d'ingénierie capables de fabriquer des alliages légers et résistants nous a permis, à nous les humains, de réimaginer la manière dont le défi du vol pourrait être relevé, « changeant la donne » par rapport à la façon dont la nature a développé le vol. 

En ramenant cette histoire au concept de périphérie, le récit de la livraison d'applications s'est jusqu'à présent concentré sur le déchargement du travail côté « serveur », c'est-à-dire la partie de la chaîne de livraison qui commence avec le serveur recevant une demande. Plus précisément, en raison de la « prédisposition évolutive » des solutions préexistantes (dont la valeur résidait dans l’allègement de la charge du serveur d’application), l’accent a été implicitement mis sur le déchargement et la distribution du calcul et de la livraison de contenu en réponse à la demande d’un client « client ». 

Cependant, réfléchissons maintenant à ce qui se passe lorsque nous considérons ces points de présence géographiquement dispersés non seulement comme des nœuds de calcul et des caches destinés à décharger le serveur (des « proxys d’application »), mais également comme des points de contrôle qui accordent une attention égale aux demandes entrantes des clients, en mappant ces demandes sur l’infrastructure et les nœuds de calcul/cache adaptés aux exigences de l’application. Par exemple, une application tolérante à la latence mais à bande passante élevée, telle que la sauvegarde de fichiers dans le cloud, peut être acheminée différemment d'une application à faible bande passante et sensible à la latence, telle que les jeux en ligne. Les applications bancaires qui nécessitent un centre d’échange de données central peuvent être dirigées vers un centre de données central. Ce concept, que je considère comme un « orchestrateur d’application », découle naturellement une fois que vous considérez la périphérie non pas comme quelque chose qui décharge simplement le serveur, mais comme un élément dont le rôle est d’être la rampe d’accès vers l’environnement généralisé de serveur/nœud d’accès.

Construisons un avion, pas un ornithoptère

Tout comme les humains ont finalement réussi à voler de manière pratique, non pas en utilisant une approche mécanisée de type oiseau (le célèbre « Ornithoptère » de Léonard de Vinci), mais plutôt en réfléchissant à la manière de mieux exploiter les technologies les plus appropriées à portée de main (des profils aérodynamiques couplés à des moteurs à essence), nous devrions réfléchir à la manière dont l’infrastructure des applications peut être repensée avec l’avènement d’un edge omniprésent, distribué et riche en services. À mesure que la puissance de cette capacité émergente devient plus évidente et plus utilisable, les propriétaires et les opérateurs d’applications entameront la prochaine étape du parcours d’évolution des applications. L'événement « révolutionnaire » qui en résultera – l'évolution perturbatrice de la périphérie, qui passera d'un simple proxy pour le serveur d'applications ou d'un cache d'applications sous stéroïdes à un orchestrateur d'applications à part entière – ouvrira l'écosystème des applications à une explosion de nouvelles possibilités, qui feront l'objet de futurs articles. 

En prévisualisant cette voie à suivre, j’ai l’intention de partager une vision de la manière dont l’adoption du rôle d’orchestrateur d’applications de pointe permettra une spécification plus déclarative et axée sur l’intention du comportement prévu de chaque application, favorisant ainsi les optimisations de l’infrastructure de l’application et également de l’expérience client de l’application. Par exemple, une application, mettant peut-être l’accent sur la technologie de réalité augmentée, peut spécifier une politique qui donne la priorité à la latence et à la bande passante, tandis qu’une application financière peut donner la priorité à la fiabilité ou à la centralisation, et pourtant une autre application IoT grand public peut se concentrer sur la gestion des dépenses d’exploitation. Plus largement, l’adoption d’un état d’esprit qui élargit le rôle de la périphérie et l’utilise comme orchestrateur d’applications, positionne également la périphérie comme l’emplacement logique pour mettre en œuvre des politiques de sécurité et de visibilité, réalisant ainsi un autre rêve de nombreux propriétaires d’applications : l’objectif de contrôles d’application indépendants de l’infrastructure.
 

^[1] Le développement du métabolisme basé sur l’oxygène est un bon exemple, mais je devrai garder cette histoire pour une autre fois.