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, avec l’évolution des applications qui se sont profondément intégrées dans nos routines quotidiennes, vous devez réduire la latence et offrir une bande passante supplémentaire pour améliorer l’expérience applicative client. Pourtant, les règles du jeu ont changé. Comme le climat et la géographie dictent constamment l’adaptation dans la nature, les exigences de diffusion des applications font évoluer les solutions à adopter. Les besoins modernes en matière de diffusion d’applications dépassent largement le simple cadre des CDN classiques. Aujourd’hui, les cas d’usage sophistiqués demandent bien plus que la simple livraison de contenu statique : ils requièrent des capacités de calcul et d’interaction. Parmi les applications aux besoins avancés figurent la visioconférence et les opérations de trading électronique. Plus globalement, la tendance vers le modèle des Applications Monopage (SPA), dans lequel une application regroupe plusieurs services web disparates, nécessite des ressources distribuées bien plus robustes qu’un simple stockage statique pour garantir une interaction utilisateur riche. Face à cette évolution, nous observons la convergence de nombreuses solutions établies qui s’adaptent pour mieux répondre à cette nouvelle et rentable « niche évolutive » — un équivalent technologique du concept d’« évolution convergente ».
La première solution préexistante est constituée des CDN mentionnés plus haut. Leur avantage évolutif réside dans leur infrastructure déjà en place, avec un grand nombre de nœuds CDN opérationnels ; leur évolution consiste à faire évoluer ces nœuds, en passant d’un simple stockage de type cache à un équilibre entre plusieurs technologies de stockage — fichiers, bases de données, stockages d’objets — couplées à des ressources de calcul capables d’exploiter ces données.
Les fournisseurs de cloud public représentent la deuxième solution dominante sur le marché. Ils excellent grâce à un écosystème solide de ressources de calcul, de stockage et de bande passante, ainsi qu’à des modèles de consommation flexibles pour ces ressources. Par exemple, AWS propose plusieurs technologies de bases de données, offre des capacités de calcul via des modèles avec ou sans serveur, dispose d’un large éventail de technologies pour gérer les identités et les données d’authentification, et met à disposition divers services complémentaires comme la journalisation, la visualisation ou la modélisation des données. Toutefois, ils accusent un « retard évolutif » : ils ont moins de points de présence que les fournisseurs de CDN historiques, ce qui limite leur couverture 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.