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, les applications se sont sophistiquées et intégrées profondément à notre quotidien. Vous devez améliorer l'expérience applicative client en réduisant la latence et en offrant une bande passante accrue. Les règles du jeu ont cependant changé et évolué. Comme le climat et la géographie poussent la nature à s’adapter en permanence, les exigences du déploiement applicatif imposent des ajustements aux solutions que nous proposons. Les besoins modernes en matière de diffusion applicative dépassent largement le simple cas d’usage d’un CDN classique. Les cas d’utilisation actuels plus complexes exigent plus que la simple distribution de contenu statique ; ils requièrent aussi de la puissance de calcul et de l’interactivité. La vidéoconférence et le trading électronique illustrent ces besoins avancés. De manière plus large, l’orientation générale vers les applications monopages (Single Page Application, SPA), qui agrègent plusieurs services web distincts, nécessite des ressources distribuées plus robustes qu’un simple stockage statique pour garantir une expérience utilisateur riche. En s’adaptant à ces nouveaux usages, l’environnement voit converger plusieurs solutions éprouvées du marché, qui se réinventent pour mieux répondre à cette nouvelle « niche évolutive » profitable — une forme d’« évolution convergente » technologiquement parlant.
La première de ces solutions existantes est constituée des CDN mentionnés précédemment. Leur force repose sur une infrastructure réseau importante, constituée d'un grand nombre de nœuds CDN. Leur évolution consiste à transformer ces nœuds, qui étaient initialement orientés vers un simple stockage en cache, pour offrir un équilibre entre plusieurs technologies de stockage—fichiers, bases de données, magasins d’objets—associées à des ressources de calcul capables de les exploiter.
Le deuxième acteur du marché existant est constitué par les fournisseurs de cloud public. Ils excellent dans la fourniture d’un écosystème solide de ressources de calcul, de stockage et de bande passante, ainsi que dans des modèles de consommation flexibles pour ces ressources. Par exemple, AWS propose plusieurs technologies de bases de données, met le calcul à disposition via un modèle avec ou sans serveur, offre un ensemble complet de technologies pour gérer les identités et l’authentification, et fournit une variété de services annexes comme la journalisation, le reporting, la visualisation, et la modélisation de données. Toutefois, leur « écart évolutif » tient au fait qu’ils ne disposent pas d’autant de points de présence que les fournisseurs CDN historiques, limitant ainsi leur portée 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.