Intégration à la périphérie des applications : une étude de l’évolution

Ken Arora

Le vol : l’évolution convergente en pratique

La plupart d’entre nous ont rêvé de pouvoir voler ; et il se trouve que l’évolution aussi. La capacité de voler — que ce soit pour échapper aux prédateurs, rechercher plus efficacement de la nourriture ou migrer sur de longues distances — s’est révélée à maintes reprises extrêmement utile à une grande variété d’animaux. À tel point, et si souvent, que l’évolution finit toujours par trouver une voie permettant d’atteindre cet objectif. Aujourd’hui, nous observons trois groupes distincts d’animaux ayant développé indépendamment la capacité de voler : les insectes, les oiseaux et les mammifères (les chauves-souris). Chacun de ces trois groupes a suivi une trajectoire évolutive différente menant au vol, dont la forme actuelle reflète celle de ses ancêtres avant qu’ils ne sachent voler. Prenons les insectes : leurs ancêtres possédaient un exosquelette externe, caractérisé par une faible densité et une structure stratifiée, ce qui lui conférait des résistances à la traction différentes selon les axes. L’évolution des insectes vers le vol s’est donc appuyée sur des ailes déformables, une approche tirant parti des éléments disponibles : faible densité et résistance à la traction variable. Chez les oiseaux, en revanche, le développement des plumes a constitué la « technologie » déterminante dans leur évolution vers le vol. Dans leur cas, les plumes sont apparues par un heureux hasard, en réponse aux besoins de certains dinosaures à sang chaud qui avaient besoin d’un matériau semblable à la fourrure pour conserver leur chaleur. Ce n’est que plus tard que les plumes se sont révélées être une « technologie » providentielle permettant le vol. Enfin, les chauves-souris, dernier groupe en date à avoir développé le vol, ont suivi une évolution progressive à partir de mammifères planeurs, mais ne bénéficient pas encore des effets de plusieurs éons d’adaptation évolutive.

Un complément intéressant et notable à cette histoire tient au constat que, lorsque les humains sont enfin parvenus à voler concrètement à l’aide de machines, ils ont adopté des approches totalement différentes : soit la sustentation par un gaz plus léger que l’air, soit des profils aérodynamiques se déplaçant rapidement et propulsés par des moteurs à essence.

C’était intéressant, mais quel rapport avec l’edge computing ?

Du point de vue de la pensée évolutionniste, les voies empruntées par la mise à disposition des applications au cours des 20 dernières années racontent également une histoire d’évolution convergente. Plus précisément, ces années ont vu le développement de multiples technologies de mise à disposition qui, avec le recul, se révèlent toutes avoir constitué les premières étapes embryonnaires de l’évolution vers ce qui est en train de devenir la périphérie applicative.

Les réseaux de diffusion de contenu (CDN) ont été les précurseurs de bon nombre de ces technologies ancestrales. Cette technologie répondait à la nécessité — sa « niche évolutive », pour ainsi dire — de fournir de grandes quantités de données relativement statiques, généralement des images volumineuses ainsi que des flux audio et vidéo, à une vaste communauté de clients. La solution consistait à placer des copies en cache des fichiers de données volumineux dans plusieurs sites géographiquement dispersés, au plus près des appareils clients. Cette approche permettait de répartir la charge de diffusion, tant en matière de calcul que de bande passante, au lieu de la concentrer dans un seul centre de données central, tout en offrant une latence plus faible et plus prévisible.

Aujourd’hui, alors que les applications ont progressé et se sont étroitement intégrées à notre quotidien, la nécessité d’améliorer l’expérience applicative des clients continue d’imposer une réduction de la latence et une augmentation de la bande passante. Cependant, les règles du jeu ont changé et évolué. Tout comme le climat et la géographie favorisent continuellement l’adaptation dans la nature, l’évolution des exigences en matière de fourniture d’applications entraîne celle des solutions nécessaires. Les besoins modernes en matière de fourniture d’applications vont bien au-delà du scénario CDN classique. Les cas d’usage plus sophistiqués d’aujourd’hui ne doivent plus se limiter à la diffusion de simples contenus statiques ; ils doivent également répondre à des exigences en matière de calcul et d’interactivité. La visioconférence et le trading électronique sont des exemples d’applications aux besoins plus avancés. Plus généralement, la tendance à adopter le modèle d’application monopage (Single Page Application, SPA), dans lequel une application résulte de l’agrégation de plusieurs services web distincts, nécessite un ensemble de ressources distribuées plus robuste qu’un simple stockage statique afin de préserver la richesse de l’expérience utilisateur. À mesure que l’environnement a « évolué » vers ces nouveaux cas d’usage, nous observons la convergence correspondante de plusieurs solutions établies sur le marché, qui s’adaptent pour mieux occuper cette nouvelle et lucrative « niche évolutive » — l’équivalent technologique du concept d’« évolution convergente ».

La première de ces solutions préexistantes est celle des CDN mentionnés précédemment. Leur « avantage » évolutif lié à leur position établie réside dans leur vaste infrastructure existante, composée d’un grand nombre de nœuds CDN ; leur trajectoire « évolutive » consiste à faire évoluer ces nœuds, jusqu’ici exclusivement axés sur un stockage de type cache, afin qu’ils offrent une combinaison plus équilibrée de plusieurs technologies de stockage — fichiers, bases de données et magasins d’objets — associées à des ressources de calcul capables d’exploiter ces données.

La deuxième catégorie de solutions déjà établies sur le marché est celle des fournisseurs de cloud public. Leur « point fort » réside dans leur solide écosystème de ressources de calcul, de stockage et de bande passante, ainsi que dans les modèles flexibles de consommation associés à ces ressources. Par exemple, AWS propose plusieurs types de technologies de bases de données, met à disposition des ressources de calcul selon un modèle avec ou sans serveur, dispose d’un riche éventail de technologies pour la gestion des identités et de l’authentification, et fournit divers services complémentaires, tels que la journalisation et la création de rapports, la visualisation, la modélisation des données, etc. Toutefois, leur « retard évolutif » tient au fait qu’ils ne disposent pas d’autant de points de présence que les fournisseurs de CDN historiques et ne bénéficient donc pas d’une couverture géographique aussi étendue.

À l’autre extrémité du spectre en matière de points de présence se trouvent les opérateurs de services mobiles (MSP), notamment à mesure qu’ils déploient leurs infrastructures 5G. Les grands MSP prévoient de disposer de dizaines de milliers de points d’accès mobiles, chacun constituant un point d’entrée vers le réseau cœur. Outre leur « atout » en matière de distribution et d’échelle, ils disposent de capacités de calcul et de stockage limitées au niveau de ces points d’accès. Toutefois, jusqu’à récemment, ces ressources étaient principalement destinées à répondre aux besoins propres de leur infrastructure. Ils doivent donc combler cette « lacune » en adoptant un modèle informatique qui ouvre leur infrastructure de calcul aux applications externes et en le complétant par des capacités de stockage supplémentaires.

Revenons au vol — et voyons pourquoi les humains ont adopté une approche différente

Le parcours qui vient d’être décrit correspond à un processus évolutif naturel et progressif. Cependant, il arrive que certains éléments « changent la donne^{[1] »} dans l’évolution — autrement dit, qu’ils perturbent celle-ci et conduisent à réévaluer sa progression linéaire. Dans le cas de la conquête de l’air par l’être humain, la mise au point de systèmes capables de fournir rapidement une grande puissance (par exemple, les moteurs à essence), associée à des technologies des matériaux et d’ingénierie permettant de fabriquer des alliages légers et résistants, nous a permis de repenser la manière de relever le défi du vol, « changeant ainsi la donne » par rapport à la façon dont la nature a développé le vol.

Si l’on rapproche cette histoire du concept d’edge computing, le récit de la fourniture d’applications s’est jusqu’ici concentré sur le délestage des tâches côté « serveur », c’est-à-dire la partie de la chaîne de fourniture qui commence lorsque le serveur reçoit une requête. 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’applications), l’accent a implicitement été mis sur le délestage et la distribution des calculs et de la fourniture de contenu effectués en réponse à la requête d’un « client ».

Cependant, voyons 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 à alléger la charge du serveur — des « proxys applicatifs » —, mais aussi comme des points de contrôle accordant autant d’attention aux requêtes entrantes des clients et les orientant vers l’infrastructure ainsi que vers les nœuds de calcul ou de cache adaptés aux exigences de l’application. Par exemple, une application tolérante à la latence mais nécessitant une bande passante élevée, telle que la sauvegarde de fichiers dans le cloud, pourrait être acheminée différemment d’une application à faible bande passante mais sensible à la latence, comme les jeux en ligne. Les applications bancaires nécessitant un centre d’échange de données centralisé pourraient être dirigées vers un centre de données central. Ce concept, que je qualifie d’« orchestrateur d’applications », découle naturellement d’une conception de la périphérie non pas comme un simple moyen d’alléger la charge du serveur, mais comme un élément dont le rôle est de servir de point d’accès à l’environnement généralisé de serveurs et de nœuds d’accès.

Construisons un avion, pas un ornithoptère

Tout comme l’être humain est finalement parvenu à voler de manière concrète, non pas en recourant à une approche mécanisée imitant l’oiseau (le célèbre « ornithoptère » de Léonard de Vinci), mais en cherchant à mieux exploiter les technologies les plus adaptées dont il disposait — des profils aérodynamiques associés à des moteurs à essence —, nous devons réfléchir à la manière de repenser l’infrastructure applicative avec l’avènement d’une périphérie omniprésente, distribuée et riche en services. À mesure que la puissance de cette nouvelle capacité deviendra plus manifeste et plus accessible, les propriétaires et les exploitants d’applications entameront la prochaine étape de leur parcours d’évolution applicative. L’événement décisif qui en résultera — l’évolution disruptive de la périphérie, qui ne sera plus un simple proxy pour le serveur d’applications ou un cache applicatif surpuissant, mais un véritable orchestrateur d’applications — ouvrira l’écosystème applicatif à une multitude de nouvelles possibilités, qui feront l’objet de prochains articles.

Pour donner un aperçu de la voie à suivre, je souhaite présenter une vision dans laquelle l’adoption du rôle d’orchestrateur d’applications de l’edge permettra de définir le comportement attendu de chaque application de manière plus déclarative et guidée par les intentions, afin d’optimiser à la fois l’infrastructure de l’application et l’expérience client qu’elle offre. Par exemple, une application axée sur la réalité augmentée pourrait définir une politique privilégiant la latence et la bande passante, tandis qu’une application financière pourrait donner la priorité à la fiabilité ou à la centralisation, et qu’une autre application IoT grand public pourrait se concentrer sur la gestion des dépenses d’exploitation. Plus largement, adopter une approche qui étend le rôle de l’edge et l’exploite comme orchestrateur d’applications fait également de l’edge l’emplacement logique pour mettre en œuvre les politiques de sécurité et la visibilité, concrétisant ainsi un autre rêve de nombreux propriétaires d’applications : disposer de contrôles applicatifs indépendants de l’infrastructure.

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

À propos de l’auteur

Ken Arora

Autres articles de Ken Arora