Table des matières
Introduction
La définition de l'Edge a toujours été étroitement liée à l’évolution de l’architecture des centres de données. Au cours de la dernière décennie, l’architecture de l’infrastructure des entreprises a connu une transformation rapide, passant des centres de données sur site aux architectures distribuées dans le cloud d’aujourd’hui. Nous considérons la technologie Edge 2.0 comme un changement technologique qui permettra aux applications de tirer parti d’une architecture distribuée dans le cloud.
Chaque personne, organisation ou entité a une interprétation différente de l'Edge. Certains peuvent considérer que l'Edge est une tour de téléphonie mobile, d’autres peuvent dire que leur appareil mobile est l'Edge. Pour les fournisseurs de services cloud, l'Edge est une empreinte d’infrastructure gérée qui s’intègre de manière transparente dans leur back-end. Pour les applications militaires, l'Edge est le théâtre d’opérations, que ce soit sur terre, sur mer ou dans les airs. Chaque fois que nous lisons quelque chose à propos de l'Edge, l’interprétation se résume généralement aux capacités de calcul, de mise en réseau et de stockage de l’infrastructure et/ou de son emplacement.
Mais nous considérons également la technologie Edge 2.0 de par l’expérience qu’elle offre à toutes les parties prenantes de l’écosystème, et pas seulement à l’infrastructure ou à son emplacement.
Ce document décrit ce que devrait être la fonctionnalité Edge 2.0, indépendamment de son infrastructure physique ou virtuelle, ou de l’endroit où elle est située ou instanciée. L’objectif n’est pas d’expliquer comment construire une meilleure application distribuée, mais de mettre en lumière les capacités qui doivent être présentes dans l'Edge 2.0 pour permettre la création d’applications distribuées optimales répondant à un besoin particulier.
Edge 2.0, qu’est-ce que c’est ?
Du point de vue d’une entité qui réside dans ce cloud distribué, l'Edge se situe là où l’entité se trouve actuellement. Ainsi, nous proposons une définition de l'Edge 2.0 qui est centrée sur l’expérience et n’est pas uniquement liée à l’emplacement de l’infrastructure, au type d’infrastructure ou à l’entité qui la contrôle.
L’objectif de l'Edge 2.0 est d’améliorer les expériences centrées sur les applications, les opérations et les développeurs. Edge 2.0 doit prendre en compte les méta-propriétés (comme les SLA et les SLO) de l’application en s’adaptant à l’évolution des besoins de l’application. Edge 2.0 doit être simple à utiliser et éviter aux équipes d’exploitation de créer de nouvelles automatisations pour chaque application distribuée. Edge 2.0 doit réduire les frictions auxquelles sont confrontés les développeurs lorsqu’ils développent et déploient des applications distribuées évolutives, en prenant en charge de manière transparente les objectifs de sécurité, de gouvernance et de niveau de service.
Prenons l’exemple d’une application bancaire. L’objectif de l'Edge 2.0 n’est pas d’améliorer la logique commerciale de la transaction. Il s’agit de la rendre plus sûre, plus rapide, plus privée, utilisable dans toutes les zones géographiques (si nécessaire), et évolutive en fonction des besoins pour soutenir les objectifs de l’entreprise.
Concepts et assertions
Voici les principaux concepts et assertions de ce document :
- Edge centré sur l’expérience : établit une base pour l'Edge 2.0 autour de l’expérience qu’il fournit, plutôt qu’un actif ou ses emplacements.
- Considérations de conception : spécifie les principales considérations de conception pour une mise en œuvre réussie de l’architecture Edge 2.0.
- Infrastructure hétérogène : souligne que la conception d’un cloud distribué implique d’envisager un contrôle décentralisé de l’infrastructure.
- La télémétrie comme base : la télémétrie est considérée comme un élément fondamental qui doit être pris en charge par toutes les couches de l’infrastructure. Sans télémétrie, une stratégie axée sur les données se dilue.
- Enjeux inter-clusters : souligne un enjeu fondamental de l'Edge 2.0, à savoir être inter-clusters plutôt qu’intra-clusters.
- Interfaces adaptatives : introduit les interfaces adaptatives, offrant une comparaison distincte avec les interfaces déclaratives et impératives.
- Plateforme d’applications Edge 2.0 (EAP) : présente l'EAP comme un cadre permettant à l'Edge 2.0 de s’adapter aux besoins des applications.
Sujet(s) non traité(s)
Il y a plusieurs sujets que nous n’avons pas encore abordés dans ce document :
- Distribution des données d’application : il existe de nombreux sous-sujets ici, comme les réseaux de diffusion de contenu (CDN), la distribution du stockage, la distribution des données, la mise en cache, etc. Il existe également des technologies émergentes comme le CRDT (Conflict-free Replicated Datatype). Un cadre Edge 2.0 devrait inclure dans sa portée la prise en charge de la distribution des données d’application.
- Distribution des fonctions : l’avancement de l’informatique de périphérie peut être considéré comme le déplacement des fonctions et de la logique de base du cloud vers l’endroit où l’événement est généré ou les données résident. En raison de l’importante quantité de compute disponible à l'Edge, nous devons maintenant résoudre des problèmes similaires à ceux qui sont généralement résolus dans les architectures de cloud traditionnelles si nous voulons tirer parti de ce compute. Par exemple, les réseaux superposés, les workloads de middleware et d’autres types de workloads qui sont entrelacés et plus complexes que les cas d’utilisation naïfs que nous avons vus au début de l'Edge — par exemple les storlets, qui sont des flux simples sans état à exécuter à côté des données.
- Il existe probablement d’autres domaines qui n’ont pas été abordés. L’objectif du framework est d’être extensible de sorte que les responsabilités puissent être ajoutées selon les besoins.
Évolution de l'Edge
La figure 1 illustre le mieux la coévolution des architectures Edge et datacenter. Edge 1.0 et 1.5 étaient basées sur la notion de site d’origine et sur le déplacement des données et des services de l’origine vers le consommateur. Edge 1.0 était un déploiement de l’infrastructure Internet principalement axé sur l’optimisation de l’utilisation de la bande passante avec la mise en cache distribuée du contenu, c’est-à-dire les réseaux de distribution de contenu. Les CDN sont un modèle de conception fondamental puisque le contenu global à transférer sera toujours supérieur à la bande passante disponible.
Les coûts des processeurs et de la mémoire ayant chuté, des fermes de calcul sont apparues, ainsi que des nœuds CDN. Les applications ont été consommées comme des services par le biais d’architectures orientées services (SOA). D’où la référence à Edge 1.5 en tant que réseau de distribution de services.
Une caractéristique commune à Edge 1.0 et Edge 1.5 est l’idée d’un site d’origine. Avant la croissance du mobile, les personnes, les appareils et les objets téléchargeaient principalement du contenu ou agissaient en tant que consommateurs du service. Le site d’origine du service était encore différent de celui du consommateur.
Dans Edge 2.0, cependant, toute entité peut agir comme un site d’origine ou comme un consommateur. Le flux de trafic a changé. Les êtres humains, les téléphones et les appareils produisent activement des données en téléchargeant du contenu ou en générant des données périodiques. Les applications deviennent des consommateurs car elles dépendent d’autres applications. Toutes les entités peuvent agir en tant que producteurs ou consommateurs d’un service : API, humains, appareils IoT ou applications web, back-end et sans affichage. De son propre point de vue, chaque entité de l’infrastructure pense qu’elle se trouve à l'Edge.
Le cloud distribué est la dernière étape de l’évolution du centre de données. Le compute est devenue véritablement omniprésente, des appareils mobiles aux objets quotidiens connectés au réseau. Il s’accompagne d’architectures logicielles permettant de mettre en œuvre des applications distribuées et évolutives.
Conséquences de l'Edge : une complexité accrue
L’abondance et l’hyper-distribution de compute et de stockage partout ont créé une opportunité de transformation numérique rapide de l’entreprise. Mais cette évolution rapide n’est pas sans conséquences.
La plupart des entreprises se composent généralement d’infrastructures hétérogènes, avec des environnements non uniformes. La mise à l’échelle efficace de tels environnements exige une orchestration et une automatisation complexes des systèmes déployés. Les changements rapides des besoins de l’application, tels que les modifications des exigences en matière de CPU et de bande passante, augmentent la complexité des opérations dans un cloud distribué. Cela ajoute du stress aux équipes d’exploitation, qui peuvent ne pas être bien équipées pour répondre efficacement aux besoins changeants de l’application ou du client final.
De ces problèmes découle une complexité opérationnelle qui neutralise tout gain potentiel pour une entreprise en pleine transformation numérique.
Certains des problèmes et artefacts imbriqués qui résultent de la complexité sont mis en évidence ci-après.
Les clouds hybrides entraînent une augmentation de la surface susceptible d’être compromise en raison de divers vecteurs d’attaque. Les différents cas d’usage créent de multiples défis en matière de sécurité, et à mesure que l’infrastructure évolue, on court constamment après le ballon. Ainsi, le problème que nous anticipons est le suivant : est-ce que seules les recommandations technologiques changeront souvent, ou les modèles de conception pour mettre en œuvre la sécurité changeront-ils également ?
Voici quelques problèmes rencontrés avec les approches existantes :
- Le Software Defined Perimeter (SDP) n’évolue pas facilement, car les solutions les plus courantes sont basées sur des agents, ce qui ne se prête pas à des déploiements opérationnels simples.
- La mise en œuvre du Sero Trust Network Access (ZTNA) est souvent peu pratique, car les solutions ZTNA nécessitent une constellation de services de production déployés tels que l’inspection du trafic, la gestion centralisée des journaux, la gestion globale de la PKI et des identités, etc.
- Le Secure Access Service Edge (SASE) combine le réseau en tant que service (NaaS) et la sécurité en tant que-service (SECaaS ou SaaS), une soupe d’acronymes de plusieurs technologies non triviales à mettre en œuvre. En outre, le SASE tend à être centré sur le Software Defined WAN (SD-WAN), ce qui ne concerne qu’un petit segment des cas d’usage des réseaux à l'Edge.
- La disparité entre les infrastructures des différents fournisseurs de clouds publics et les modèles de sécurité déjà complexes, par exemple la gestion des identités et des accès (IAM), conduisent souvent les équipes à un durcissement disparate des fournisseurs et à des configurations multi-clouds lourdes.
L’un des principaux défis posés par l’hyperdistribution de compute à faible puissance et à faible coût disponible à l'Edge est la capacité d’orchestrer et de planifier l’infrastructure de manière uniforme. Les équipes d’exploitation ont du mal à mettre à l’échelle et à prendre en charge les applications qui exploitent le cloud distribué, car ces applications comprennent généralement des technologies hétérogènes avec des exigences d’administration différentes.
Bien que les plateformes d’automatisation telles que Terraform offrent un moyen sophistiqué de personnaliser l’automatisation, les équipes d’exploitation doivent toujours maintenir des scripts pour de multiples permutations : par exemple, cinq variantes différentes de compute, quatre types différents de pare-feu et trois types d’équilibreurs de charge. Le coût humain lié à la gestion et à la maintenance des scripts d’automatisation n’évolue pas.
Il en résulte que le client de l’infrastructure continue d’interagir avec les équipes d’exploitation par le biais de systèmes axés sur les tickets, qui constituent un obstacle à l’automatisation des workflows existants. Le service d’assistance est submergé de tickets et doit donner la priorité à la sécurité et à la stabilité plutôt qu’à l’agilité.
Les architectures microservices sont déjà devenues la méthode de facto pour créer de nouvelles applications avec l’évolution vers le multi-cloud. Les API sont publiées et peuvent être instanciées à tout moment et partout, ce qui entraîne une prolifération d’API. La découverte, la connectivité et la gestion de ces API de manière autonome deviennent un défi majeur.
Un changement de paradigme est nécessaire pour faire face à la prolifération des API. Nos modèles internes démontrent que même des hypothèses modérées de paramètres, comme le nombre de développeurs d’API dans le monde, le nombre d’API développées par développeur et par an, et la durée de vie des API, font que plusieurs centaines de millions (voire des milliards) d’API seront simultanément actives d’ici 2030 (figure 2). Le rapport 2021 API Sprawl (rapport sur l’expansion du marché des API) offre une vue d’ensemble de ce sujet émergent.
Cette complexité accrue exige des entreprises qu’elles permettent une visibilité granulaire et significative de bout en bout du système. Dans les environnements de cloud distribué, les applications transcendent plusieurs stacks d’infrastructures hétérogènes gérées par des entités distinctes.
En outre, aucun des opérateurs actuels n’est incité à exposer la télémétrie native de son infrastructure aux entreprises clientes. Les entreprises fonctionnent essentiellement à l’aveugle lorsqu’elles déploient des applications dans un cloud distribué et doivent recourir à de multiples outils d’observabilité. Pour combler ces lacunes en matière de visibilité, les outils proviennent généralement de différents fournisseurs qui travaillent à différents endroits de l’infrastructure ou des stacks applicatives.
Des mesures d’infrastructure non standard ajoutent aux difficultés d’une entreprise. En général, les mesures ne sont pas unifiées en raison des silos opérationnels et d’autres facteurs tels que l’absence d’uniformité dans les différents environnements d’infrastructure. Par exemple, les mesures sont différentes selon les fournisseurs de clouds publics, et les technologies de centres de données sur site ne suivent pas non plus de mesures standard.
Résultat commercial : une expérience amoindrie
Les workloads générateurs de revenus et les systèmes critiques utilisent généralement la plupart des ressources opérationnelles et du budget disponibles dans une entreprise. Parallèlement, les projets plus petits, bien que moins complexes, tendent à constituer le volume des applications de l’entreprise. La figure 3 illustre cette situation sous la forme d’une distribution à longue queue du nombre de projets qu’une entreprise est susceptible d’avoir par rapport à sa complexité opérationnelle.
Même si les petites applications sont moins complexes sur le plan opérationnel, les processus et workflow d’exploitation restent souvent manuels, et il faut parfois des semaines pour que les tickets transitent par plusieurs équipes opérationnelles. Par exemple, le déploiement d’une application qui nécessite des ressources réseau dédiées avec des politiques de sécurité granulaires peut d’abord nécessiter l’approbation des équipes de sécurité globale. Ensuite, le ticket peut être transmis à l’équipe chargée de la mise en réseau pour planifier les configurations de sous-réseau et de route nécessaires. Enfin, la validation des règles du pare-feu peut être demandée à une autre équipe opérationnelle responsable de la gestion du pare-feu.
Imaginons maintenant que la complexité ci-dessus doive être prise en compte pour chaque application déployée sur un cloud distribué où l’entreprise ne possède aucune partie de l’infrastructure sous-jacente. Le simple volume de petits projets ou d’applications qui doivent être intégrés et pris en charge fait qu’il n’est pas réaliste pour les équipes d’exploitation de prendre en charge chaque projet, ce qui crée un problème de hiérarchisation et une opportunité de libre-service.
Ce problème de priorisation est particulièrement visible lorsque les investissements des équipes d’infrastructure se concentrent sur les systèmes critiques et générateurs de revenus, laissant peu de temps ou de budget pour les nouveaux projets qui impliquent leur propre cycle de vie de développement, de test et de stagging avant la production. Il en résulte une diminution des capacités et des investissements en matière de développement de fonctionnalités, de personnalisation et d’innovation pour les nouveaux produits, ce qui aboutit à une stagnation de l’entreprise et de ses offres
Espace de solution Edge
L’évolution de l’écosystème Edge élargit considérablement l’espace des solutions en offrant la possibilité de relever ces défis grâce à une plateforme d’applications.
La figure 4 montre l’espace de solution Edge 2.0. Nous affirmons ici que tout ce qui relève d’une architecture de cloud ditribué constitue la totalité de l’espace de solutions.
Ainsi, dans le contexte de l’espace de solution, Edge 2.0 doit offrir l’expérience souhaitée par tous les éléments suivants :
- Toutes les entités qui résident dans le périmètre de la solution : les applications, les personnes et les équipements qui agissent en tant que consommateurs, ou les applications dorsales Web et sans interface qui constituent les services.
- Les équipes SRE et les propriétaires d’applications de ces applications, tout en préservant la sécurité et les garde-fous réglementaires attendus de l’infrastructure.
Sur le plan opérationnel, l'Edge 2.0 sera simple, sécurisé, conforme, et offrira une expérience de haute qualité à toutes les entités de l’écosystème qui y participent.
Considérations relatives à la conception de l'Edge 2.0
Sécurité par défaut
Un cloud distribué amplifie ce problème de sécurité à l’échelle, car le nombre de points d’extrémité augmente de façon exponentielle. Avec une telle ampleur, la complexité de la mise en œuvre d’une solution augmente également. La posture de sécurité devrait être que l’application suppose que l’environnement dans lequel elle est actuellement déployée est déjà compromis. De même, l’infrastructure ne doit faire confiance à aucune application qui s’y exécute.
La base de ces idées est capturée dans les concepts de l’état d’esprit de Zero Trust, et l’exemplaire BeyondCorp1 démontre ces concepts pour le cas d’utilisation de l’accès aux applications. Pour l’avenir, Edge 2.0 étend ce modèle en se fondant sur les cinq principes fondamentaux suivants :
- L’identité est fondamentale : dans Edge 2.0, l’identité est primordiale, chaque instance d’entité ayant sa propre identité unique au monde, mais aussi sa place dans la hiérarchie de l’organisation ainsi que son niveau de privilège. L’identité doit être un élément clé non seulement pour le trafic nord-sud, mais aussi en interne pour l’accès est-ouest.
- Le moindre privilège : les actions autorisées par un acteur doivent être limitées à celles dont il a besoin pour jouer son rôle dans le système. Par exemple, on peut limiter le sous-ensemble de charges de travail autorisées à communiquer avec le serveur de base de données en fonction des spécifications de conception.
- Authentification continue : toute attestation faite par un acteur du système doit avoir un moyen de vérification et doit être explicitement vérifiée chaque fois qu’une telle attestation se produit. L’authentification ne doit pas être uniquement explicite par le biais de secrets partagés ou d’une chaîne de confiance, mais doit également tenir compte des modèles de comportement implicites et des métadonnées contextuelles.
- Surveillance et évaluation constantes : les actions de tous les acteurs du système doivent être surveillées, ce qui renforce le rôle clé des technologies de collecte et de stockage des données dans une architecture Edge 2.0. En outre, ces activités doivent être évaluées en permanence pour détecter et atténuer les tentatives d’exécution d’actions interdites ou dangereuses. L’évaluation doit se faire en temps quasi réel, à l’échelle, ce qui implique une utilisation généreuse de l’automatisation et des techniques d’apprentissage automatique (ML).
- Présomption de violation : compte tenu des ressources dont disposent les adversaires sophistiqués d’aujourd’hui, il faut supposer que tout système a été compromis d’une manière ou d’une autre. Par conséquent, les politiques entièrement déterministes ancrées dans le workload et les identités des utilisateurs, qui appliquent un accès basé sur les privilèges représenté par a et b, sont souvent insuffisantes pour prévenir toutes les attaques. Par conséquent, un système Edge 2.0 pleinement mature doit également être capable d’évaluer en temps réel les risques et les avantages en se basant sur une surveillance et une évaluation continues.
Fournit une observabilité native
Edge 2.0 doit intégrer la télémétrie en tant que citoyen de première classe au sein de la stack d’infrastructure, fournir un moyen simple et évolutif de collecter la télémétrie multicouche au sein de l’infrastructure et la faire remonter vers une plateforme commune. Cela permet aux équipes chargées de l’observabilité d’interroger en surface l’« état de l’infrastructure » selon les besoins. Les équipes chargées des applications peuvent ainsi se concentrer sur la logique métier sans avoir à instrumenter explicitement leurs stacks applicatives.
L’état actuel de la technologie d’observabilité s’est révélé largement spécifique aux fournisseurs et propriétaire. Cela a conduit à la collecte de signaux similaires par de nombreux agents propres aux fournisseurs, qui se bousculent pour obtenir de la mémoire et du CPU coûteux.
La prochaine étape logique réside dans l’utilisation d’un collecteur de télémétrie indépendant du fournisseur, qui permet de transmettre les données d’infrastructure et de trafic à une plateforme de données centralisée.
De nombreuses équipes de produits ont du mal à justifier l’investissement dans l’instrumentation, cet effort devant correspondre à une opportunité de revenu. L’infrastructure doit être instrumentée comme toute autre fonction ou processus métier, car l’équipe doit comprendre son comportement pour l’optimiser en fonction des objectifs de l’entreprise. Ainsi, le débat devrait porter davantage sur quoi instrumenter en priorité, plutôt que sur la nécessité de le faire.
Pour obtenir des mesures granulaires et plus précises du comportement de l’application, nous prévoyons que l’instrumentation fasse du « Shift Left » en l’invoquant dans le code — Figure 5.
Prise en charge des interfaces adaptatives
Conformément au cloud distribué, chaque cloud dans son environnement (local ou global) possède son propre gestionnaire, administrateur, orchestrateur, etc. Chacun se comporte indépendamment, prend ses propres décisions, mais fournit des interfaces que d’autres entités peuvent utiliser au besoin.
Ainsi, la notion de cloud distribué, par essence, caractérise une administration et un contrôle décentralisés. On ne peut y échapper, et il est important de le reconnaître pour mieux comprendre les nuances des interfaces adaptatives par rapport aux interfaces déclaratives et impératives.
Pour utiliser efficacement l’infrastructure Edge 2.0, les interfaces impératives et déclaratives ne suffisent pas, car elles reposent toujours sur des artefacts artisanaux qui sont essentiellement des constructions statiques et ne s’adaptent pas assez rapidement à des conditions en évolution rapide.
Les systèmes doivent être suffisamment intelligents pour ajuster les politiques à travers l’infrastructure (de bout en bout) afin d’atteindre ces résultats. C’est ce que nous appelons des interfaces adaptatives.
Pour dire les choses clairement, les interfaces impératives, déclaratives et adaptatives ne s’excluent pas mutuellement :
Impératif : est très prescriptif et définit en détail une série d’actions pour atteindre l’état souhaité. La configuration d’un routeur, par exemple, est une action impérative. Dans le scénario ci-dessus, les actions prescriptives seront précises : quel centre de données, quelle quantité de CPU/mémoire, la bande passante requise, les routes spécifiques, etc. La qualité d’entrée du modèle de données est très élevée et nécessite donc une connaissance et une expertise plus approfondies de l’infrastructure. On s’attend à connaître à la fois le modèle et la structure de l’infrastructure.
Déclaratif : la nuance du déclaratif est qu’il se concentre sur la description de l’état souhaité, par opposition aux actions qui permettent d’atteindre l’état souhaité. La qualité de l’entrée est moindre, bien qu’elle exige toujours que l’application connaisse au moins la structure de l’infrastructure sous-jacente.
Adaptatif : se distingue de l’impératif ou du déclaratif. Une interface adaptative se concentre sur l’objectif ou le but recherché, plutôt que sur l’état. Le but de l’interface adaptative est de capturer l’objectif de la partie prenante qui veut déployer l’application plutôt que de se concentrer sur une connaissance préalable du système sous-jacent. L’adaptatif est différent car il n’a aucune notion des capacités de l’infrastructure sous-jacente. Il n’y a aucune contrainte sur la façon de « faire le travail » et, par conséquent, il est autonome.
Avec l’adaptatif, la qualité de l’entrée est faible et se rapproche du langage naturel. Les propriétaires d’applications peuvent envoyer une requête pour indiquer au contrôleur d’infrastructure le résultat qu’ils attendent, au lieu de devoir déclarer la capacité requise ou configurer spécifiquement une ressource.
Résout le problème des inter-clusters
Un cloud distribué, par définition, accueille tous les types d’architectures d’applications : monolithiques, microservices ou sans serveur. Quelle que soit l’architecture, les applications utilisent des API pour offrir les services.
Les problèmes de découverte d’API, de connectivité et de sécurité du réseau sont en grande partie résolus par l’utilisation d’un maillage de services, mais celui-ci ne résout ces problèmes qu’au sein du cluster (intra-cluster).
Les applications Edge 2.0, quant à elles, tirent parti des API dans une infrastructure de cloud hyperdistribuée, en fait un environnement multi-clusters. Les nouvelles applications sont écrites avec des API qui traversent les frontières organisationnelles et géographiques. Certaines de ces API peuvent être des API privées ou des API de partenaires situées derrière plusieurs couches de pare-feu, sans route explicite entre elles, même si elles peuvent être découvertes. Ce problème de cluster hétérogène (inter-clusters) est sans solution élégante, légère, évolutive et sécurisée qui soit pratique.
| Scénario/Propriétés | Impératif | Déclaratif | Adaptatif |
|---|---|---|---|
| Définition | L’interface impérative définit le flux de contrôle détaillé en fonction des capacités spécifiques de la ressource sous-jacente. |
L’interface déclarative définit la logique mais pas le flux de contrôle. En langage programmatique, c’est le pseudo-code. |
L’interface adaptative exprime l’état désiré comme une exigence sans faire de suppositions sur les capacités des ressources sous-jacentes. Une interface adaptative appartient à l’infrastructure et permet à celle-ci de répondre dynamiquement aux besoins changeants de l’application. |
Scénario 1 : le colis doit aller de San Francisco à New York |
Jane dit à Mark : (a) d’imprimer l’étiquette d’expédition, (b) de se rendre sur la boutique UPS, (c) de choisir la livraison en 72 heures, (d) de payer et d’expédier Mark : doit suivre une série d’étapes très spécifiques |
Jane demande à Mark : (a) de faire parvenir ce paquet par courrier à cette adresse, (b) le paquet doit arriver dans les 72 heures. Mark : peut choisir n’importe quel service de transporteur (UPS, FedEx, DHL, etc.). |
Jane indique à Mark : (a) ce paquet doit arriver à New York avant samedi. Mark : peut faire ce qu’il veut. Il pourrait même prendre le paquet lui-même, prendre l’avion pour New York et le livrer en main propre. |
Scénario 2 : exemple d’équilibreur de charge |
L’équilibreur de charge existe déjà. Tâche : doit être configuré avec cette politique. Ici, la tâche est spécifique à la marque, au modèle, à la version de l’équilibreur de charge, etc. |
Il n’existe pas d’équilibreur de charge. Tâche : équilibrer la charge de l’application avec une politique ouverte donnée. La tâche suppose qu’une couche d’orchestration |
Aucune hypothèse sur l’infrastructure sous-jacente. Veuillez vous assurer que l’application évolue selon les besoins, avec une latence maximale de 10 ms. |
Propriété |
Propriété commune : application et infrastructure |
Propriété commune : application et infrastructure |
L’infrastructure seule |
Qualité de l'entrée |
Extrêmement élevé : nécessite une connaissance approfondie du périmètre sous-jacent. Par exemple, il faut savoir quel est l’équilibreur de charge F5, quelle est la version de logiciel, etc. Une CLI ou un NMS serait un exemple d’interfaces impératives. |
Élevé : nécessite la connaissance de ce dont l’infrastructure est capable. Par exemple, dans l’exemple ci-dessus, il y a une connaissance préalable de l’infrastructure supportant un équilibreur de charge. |
Faible : ne nécessite aucune connaissance des capacités de l’infrastructure. La qualité de l’entrée se rapproche de l’équivalent en langage naturel. |
Niveau de compétence (Persona) |
Compétences propres à une fonction. Par exemple, administrateur réseau, administrateur informatique, administrateur stockage. Chaque aspect de l’infrastructure exige de l’utilisateur qu’il soit un expert dans ce domaine. |
Compétences en matière de déploiement d’applications. L’utilisateur connaît le type de fonction nécessaire au déploiement de l’application. Comme dans le cas ci-dessus, le responsable de l’application sait qu’un équilibreur de charge est nécessaire, ainsi que les politiques de haut niveau sur lesquelles l’équilibreur de charge doit être configuré pour prendre en charge la mise à lʼéchelle automatique. |
Ingénieur d’application. Peut juste signaler à l’infrastructure quelles sont les exigences non fonctionnelles de l’application. Dans le cas présent, la rapidité à laquelle l’application doit répondre à la demande d’un client. D’autres facteurs comme la situation géographique, le coût, etc., peuvent être ajoutés si nécessaire. |
Pérmiètre |
Les interfaces impératives ont |
Le périmètre déclaratif est plus large. Généralement, il est associée à un moteur d’orchestration qui communique avec plusieurs interfaces impératives pour obtenir le résultat souhaité. |
Périmètre très large car le résultat de |
Exemple |
- name: update web servers hosts: webservers remote_user: root tasks: - name: ensure apache is at the latest version yum: name: httpd state: latest - name: write the apache config file template: src: /srv/httpd.j2 dest: /etc/httpd.conf |
apache-server: version: “latest” |
application-latency: - lt: 10ms infrastructure-cost: - lt: $200 - billing: monthly |
Nous avons largement couvert les API dans le rapport 2021 API Sprawl2 (rapport sur l’expansion du marché des API) et y abordons de nombreuses questions susceptibles de se poser. La figure 6 montre la différence entre inter-cluster et intra-cluster.
Intra-cluster : dans une architecture monolithique, il peut y avoir très peu d’API exposées avec une communication interne entre les modules via d’autres méthodes de communication interprocessus. Alors qu’une architecture de microservices se décompose en dizaines, voire en centaines, d’API.
Quel que soit le cas, chaque cluster d’applications est développé et géré avec un parti pris. Par exemple, dans le cas d’une architecture de microservices, une équipe peut utiliser n’importe quel type de maillage de services : Istio, Linkerd, Aspen Mesh ou autres. Chaque approche a ses propres moyens de gérer et de contrôler les API au sein de son cluster, en d’autres termes, intra-cluster.
Il existe de nombreuses solutions dans ce domaine, et l’objectif de l'Edge 2.0 n’est pas de réinventer ou de forcer les organisations ou les équipes de développement à adopter une nouvelle technologie.
Inter-cluster : à mesure que le nombre de services fournis via les API augmente, les nouvelles applications sont construites en utilisant des services déjà développés ou adoptés par différentes équipes d’application au sein de l’entreprise, car il n’est pas nécessaire de réinventer la roue.
De nouvelles applications sont également créées grâce à différentes combinaisons d’API publiques et privées. Du point de vue de l’architecture, les applications modernes exploitent les services fournis par d’autres clusters. Dans un cloud distribué, ces clusters sont déployés à l’échelle mondiale et peuvent donc se situer sur n’importe quel bien immobilier pouvant héberger l’application ou faire partie du cluster d’application.
Pour réitérer, le périmètre d’un cluster d’applications ne se limite pas seulement à l’intérieur d’une organisation. Les clusters peuvent se situer entre deux réseaux, applications, silos organisationnels ou même entre deux entreprises.
Le périmètre couvre toute la gamme de toutes les permutations et combinaisons, ce qui augmente de façon exponentielle la complexité des opérations. La figure 7 montre les permutations du trafic dans le cadre du déploiement de l’application.
Une entreprise typique aura différentes architectures d’application. Il peut s’agir de différentes déclinaisons de services mesh, d’une application Web 2.0 basée sur une architecture orientée services ou d’un déploiement de logiciels monolithiques, selon l’équipe qui les développe et les déploie. Les API sont donc dispersées dans toute l’entreprise, qu’il s’agisse d’API privées ou de l’utilisation d’API publiques. Ce problème n’est pas encore résolu. La communication des API entre plusieurs sites est essentielle et constitue un problème dont la solution est insaisissable dans les entreprises de toute taille.
Il existe plusieurs solutions pour gérer les API au sein d’un cluster (par exemple, contrôleur d’entrée, passerelle API, etc.), mais la communication API inter-clusters n’est pas résolue de manière pratique, évolutive et sécurisée. Par conséquent, nous concentrons le périmètre du contrôle et de la gestion unifiés des API pour ne traiter que les problèmes inter-clusters.
Offre de l’autonomie
Une valeur sous-estimée du cloud est l’autonomie qu’il offre au « consommateur de cloud ». Les entreprises et les entrepreneurs peuvent instancier leurs propres infrastructures à la demande tout en ayant un semblant de contrôle total.
Le principe fondamental que doit suivre le design d'une plateforme Edge 2.0 consiste à fournir une expérience autonome au client du cloud tout en mettant en œuvre les garde-fous appropriés. Dans la mesure où les entités peuvent apparaître dans n’importe quelle infrastructure (de confiance ou non), les garde-fous doivent être mis en œuvre de manière à ne pas alourdir l’unité opérationnelle ou l’équipe DevOps responsable de la construction de l’application.
Le défi émergeant avec l'Edge 2.0 sera celui de la découverte, de l’identité, de la confiance et de l’observabilité entre les différents services.
Même dans les entreprises de taille moyenne, le nombre d’API produites chaque année est important. Comment les équipes découvrent-elles ces services au sein de l’entreprise ? Ou encore, comment peuvent-elles savoir si les services sont toujours valides et qui en est le propriétaire ? Peuvent-elles être sûres qu’il s’agit d’un service validé avec une confiance établie ? Le problème est aggravé lorsque les équipes veulent consommer des services créés par des clusters résidant à l’extérieur des limites de l’entreprise, par exemple des fournisseurs de SaaS ou des applications qui fonctionnent sur des appareils périphériques échappant totalement au contrôle administratif des équipes chargées de l’infrastructure de l’entreprise.
Plateforme d’application Edge 2.0
Compte tenu des défis présentés dans les sections précédentes, nous devons considérer l’ensemble du cloud distribué comme une plateforme. À un niveau supérieur, nous articulons l’objectif de la solution : découvrir de manière autonome (sans intervention humaine), mettre à l’échelle et sécuriser les applications distribuées sur une infrastructure décentralisée.
En substance, nous pouvons décrire la responsabilité de la plateforme d’application Edge 2.0 (EAP) comme suit :
- Découverte, identité et confiance des API
- Planification et orchestration de l’infrastructure
- Connectivité sécurisée aux applications
Portée de l'EAP
L’infrastructure est la totalité de l’espace de solution où des éléments d’infrastructure peuvent continuellement apparaître et disparaître. La propriété de l’infrastructure et de ses ressources, et l’administration et le contrôle de ces ressources, sont deux concepts distincts. Un propriétaire d’infrastructure peut attribuer une infrastructure spécifique ou une instance de celle-ci à une organisation différente qui la gère et la configure, ou le propriétaire de l’infrastructure peut reprendre le contrôle si nécessaire. L’organisation qui gère et configure les éléments peut ensuite les affecter à des projets ou des applications individuels. Cette notion n’est pas nouvelle ; par exemple, les fournisseurs de services de cloud offrent un contrôle administratif hiérarchique qui peut être utilisé par les équipes informatiques d’une entreprise pour offrir une infrastructure en tant que service (IaaS) aux unités commerciales internes, aux équipes, etc. La principale préoccupation pour l'Edge 2.0 est de savoir comment réaliser cette opération de manière extensive dans un cloud hyperdistribué, qui est l’état actuel et futur de l’infrastructure à l'Edge.
C’est là qu’apparaît le périmètre de l'EAP. La figure 8 ci-dessous montre le périmètre de l'EAP dans le contexte de différents types d’interfaces. Chaque EAP s’orchestre avec son périmètre local en utilisant des interfaces déclaratives et impératives. Dans cet exemple :
- Les interfaces déclaratives / impératives seraient les API d’AWS, d’Azure, etc.
- Les interfaces adaptatives seraient des nouveautés quʼil convient de définir au cas par cas.
Pour tirer parti du cloud distribué, l'EAP doit avoir la capacité d’exploiter tous les nœuds et entités disponibles dans un cloud distribué. L’objectif est que l'EAP individuelle devienne l’équivalent du concept de système autonome (AS)3 dans les réseaux IP, mais pour la couche application.
En combinant tous ces éléments (figure 9 ci-dessous), nous pouvons maintenant construire une vue de haut niveau de la manière dont plusieurs EAP peuvent être déployées dans une infrastructure de cloud décentralisée et interagir les unes avec les autres de manière autonome.
Les interfaces adaptatives facilitent également l’intégration du CI/CD et d’autres applications du cycle de vie des applications dans le cloud distribué. Les plateformes CI/CD peuvent s’interfacer directement avec l'EAP avec des interfaces adaptatives simples indiquant uniquement le résultat souhaité.
Il est important de noter que la communication inter-EAP peut également être réalisée à l’aide d’interfaces adaptatives.
Framework de l'EAP
Le framework de l'EAP, comme le montre la figure 10, organise les responsabilités en fonction des capacités de chaque instance de l'EAP. Le rôle de l'EAP est de s’interfacer avec les contrôleurs de l’infrastructure sous-jacente (qu’il s’agisse d’une infrastructure en tant que service [IaaS], d’une plateforme en tant que service [PaaS] ou d’un logiciel en tant que service [SaaS]) et d’orchestrer et de planifier les ressources appropriées en fonction des besoins.
Contrôle et gestion unifiés des API
L’avenir sera une économie axée sur les API, où les API sont plus qu’une simple approche de l’architecture logicielle simplifiée par le maillage des services. Une API deviendra le principal moyen par lequel toute entité participant à un cloud distribué fournit son service.
Comme cela a été établi, le nombre global d’API publiques et privées qui seront disponibles se chiffrera en centaines de millions, voire en milliards, au cours de la décennie. Les API vont remodeler notre économie et exigent donc un examen plus approfondi de ce que l'EAP doit mettre en œuvre pour soutenir cette économie.
La prolifération des API exige que chaque API puisse être découverte à l’intérieur et à l’extérieur de l'EAP. Avec le cloud distribué, les API peuvent se trouver n’importe où sur plusieurs clusters.
L’hypothèse sous-jacente est que le problème de découverte des API est véritablement un problème inter-clusters. La portée d’un EAP peut couvrir de nombreux clusters d’applications qui utilisent différentes approches logicielles (des microservices aux monolithiques), chacun mettant en œuvre sa propre stratégie de passerelle API. Un EAP fournit un référentiel commun pour toutes les API à enregistrer et à découvrir dans son périmètre, et pas seulement à l’intérieur d’un cluster. Cette distinction est essentielle pour déduire les limites des stratégies de passerelle API existantes, par exemple, comme dans le maillage de services.
Le défi pour l'EAP est de permettre la découverte d’une API, de fournir la bonne documentation sur son utilisation et de gérer le cycle de vie de l’API pour en assurer la cohérence, la précision et la gestion des versions. L'EAP met en œuvre un moyen d’informer les entités qui utilisent ses API de l’état actuel des API spécifiques utilisées. Cela peut se faire simplement en fixant des dates d’expiration ou en informant explicitement via un système de messagerie.
La posture de sécurité adoptée est celle où une application suppose que l’infrastructure dans laquelle elle est actuellement déployée est déjà compromise.
Le pilier essentiel pour mettre en œuvre cette posture de sécurité est axé sur l’identité. Chaque point de terminaison (endpoint) d’API doit avoir une identité unique au monde. Les politiques et les contrôles de sécurité sont maintenus séparément dans un référentiel central.
Les API doivent être marquées « public » ou « privé », ce qui déclenche la configuration automatique des composants de sécurité de l’infrastructure sous-jacente pour l’API spécifique.
Toutes les conversations entre une application et une autre commencent par une politique de refus d’accès. Ce n’est pas parce qu’une API est visible qu’une autre application peut l’appeler. Cela doit être configuré explicitement dans la politique de sécurité de l’application.
L'EAP doit veiller à ce que toutes les API relevant de sa portée soient fiables et que, parallèlement, toutes les API externes utilisées par les services relevant de sa portée le soient également.
« La confiance ne se prouve pas, c’est ce qui la rend “fiable” » — Citation de la série Traîtres, sur Netflix
La confiance repose essentiellement sur une « réputation dans le temps », et vous devez continuellement revalider cette confiance pour vous assurer qu’elle n’est pas tombée en dessous d’un niveau acceptable. Cette approche est devenue de plus en plus courante dans la modélisation et la mise en œuvre de la confiance dans les systèmes, exigeant que la confiance soit évaluée en permanence au lieu d’être affirmée de manière statique lors de l’exécution initiale.
La fluidité de la confiance dans le temps peut être un défi pour certaines entreprises qui n’ont pas le luxe du temps pour établir une réputation mutuelle entre leurs systèmes et ceux des tiers. L’infrastructure comme les API peuvent faire des ravages si la réputation n’est pas surveillée de près.
Dans l’hypothèse où un service de la portée de l'EAP accède à une API externe, la plateforme doit mettre en œuvre un mécanisme par lequel le service appelant peut être assuré de l’exactitude de la réponse reçue de l’API externe. Ce n’est pas parce que la réponse de l’API semble valide qu’elle est digne de confiance. Soit la réponse peut être inexacte en raison de problèmes de qualité, soit des inexactitudes peuvent avoir été explicitement insérées pour rendre l’entreprise moins compétitive. La possibilité d’attribuer un facteur de confiance à chaque API, qu’elle soit interne ou externe, est unique à la construction de l'EAP.
Une stratégie pour instaurer la confiance consiste à établir une moyenne sur la « période » la plus récente au lieu de l’historique complet du service. Cela revient à consulter les « meilleures évaluations » par rapport aux « plus récentes » pour un produit sur Amazon. Le produit peut bien avoir quatre étoiles, mais si la plupart des évaluations négatives datent des six derniers mois, cela indique une rupture récente de la confiance, tandis qu’un afflux de commentaires positifs au cours des six derniers mois indiquerait une réparation ou un rétablissement de la confiance.
Le facteur de confiance n’est pas seulement spécifique au fait qu’une API soit une source connue de données fausses ou trompeuses ou non. La réputation d’un EAP dépendra également de la manière dont il gère et met à jour les API relevant de sa compétence. En outre, la « confiance » est également relative. Le service A peut faire confiance au service C, mais le service B peut avoir une expérience différente avec le service C.
Gestion de l’infrastructure à l'Edge
Un cloud Distribué étant la base de l’infrastructure Edge 2.0, il devient impératif que les ressources relevant d’un EAP soient faciles à découvrir, sécurisées et instrumentées. Ce qui suit peut être lu comme un ensemble de recommandations requises des capacités du gestionnaire de l’infrastructure Edge.
Au sein d’un EAP, les ressources peuvent être programmées selon les besoins. De nouvelles ressources peuvent arriver ou partir dynamiquement en raison de la mobilité. Un EAP peut également envoyer ou recevoir des demandes d’autres EAP pour découvrir et programmer des ressources en son nom.
Pour réitérer la posture de sécurité : l’infrastructure sur laquelle l’application est déployée est déjà compromise. L'EAP doit donc assurer la sécurité de l’application déployée dans son périmètre.
Quel que soit le niveau d’administration, le cadre de l'EAP doit prendre en compte plusieurs aspects de la sécurité, tels que (mais sans s’y limiter) :
Menaces externes : par exemple, les attaques par déni de service distribué (DDoS) et les menaces persistantes avancées (APT). Ces menaces peuvent être atténuées en utilisant les meilleures pratiques existantes en matière de sécurité, comme la prévention des DDoS, le pare-feu, etc. Il est recommandé de l’exiger pour tout le trafic.
Attaque de l’homme du milieu (man-in-the-middle) : tout le trafic doit être crypté et l’on ne peut pas supposer que la couche application fera ce qu’il faut. Cela garantit la confidentialité des données de base contre tout dispositif d’espionnage du trafic et protège l’intégrité des données contre toute manipulation pendant la transmission.
Menaces internes : le périmètre de la couche d’infrastructure doit être limitée et principalement orientée pour se protéger elle-même. Il est recommandé d’empêcher une ressource de l’infrastructure de lancer une attaque interne contre le gestionnaire de l’infrastructure.
Si l'Edge 2.0 est axé sur l’expérience qu’il offre et non sur le bien ou son emplacement, il va de soi que la télémétrie doit également être axée sur l’expérience.
La question est de savoir à quelle expérience nous faisons référence ? L’expérience est celle de toute entité qui réside dans une infrastructure ou qui l’utilise pour produire ou consommer un service : applications, appareils, humains, applications dorsales, bases de données, etc. Le point de vue expérientiel est donc celui de l’entité. Un service qu’une entité produit ou consomme est directement lié aux ressources de calcul, de stockage et de réseau qui lui sont allouées.
Mais il ne faut pas s’arrêter à la mesure de l’expérience ; il faut aussi trouver un moyen d’y remédier.
Toute entité consommant ou fournissant un service peut déterminer si elle obtient l’expérience qu’elle a demandée. Cependant, dans les environnements de cloud distribué, il peut être quasi impossible d’expliquer ce qui s’est passé dans la couche d’infrastructure et qui a conduit à une mauvaise expérience.
Les mesures de haut niveau comme l’utilisation du CPU, de la mémoire, de la bande passante et la latence ne suffisent pas à déterminer pourquoi une application n’obtient pas l’expérience demandée3. Les mesures doivent être granulaires dans le temps et être collectées au plus profond de la pile applicative et, chaque fois qu’elles sont disponibles, à partir de différentes couches de la pile d’infrastructure.
Une stratégie de télémétrie et de données robuste, évolutive et extensible est au cœur de l'EAP. Les stratégies d’apprentissage machine (ML) et d’intelligence artificielle (AI) peuvent ensuite être exploitées pour prendre la meilleure décision sur la réservation de nouvelles ressources ou l’optimisation de l’utilisation des ressources existantes.
Software Defined Application Connectivity
Alors que la connectivité et l’accessibilité sont censées être des problèmes résolus, de nombreuses équipes réseau ont encore du mal à rationaliser leur réseau en fonction des besoins dynamiques de la couche applicative. Une plateforme doit également relever ces défis.
Le problème des approches existantes est que nous traduisons les besoins de connectivité des applications en connectivité WAN d’entreprise, en particulier dans un cloud distribué. Les approches pour traiter un réseau de cloud distribué pourraient utiliser différentes stratégies SDN ou des méthodes purement basées sur le routage. Mais ces solutions dépendent fortement de l’homogénéité de l’infrastructure et ne permettent donc pas d’obtenir un comportement cohérent.
Le seul moyen d’obtenir un réseau globalement évolutif, sécurisé et stable pour l’application est de séparer le plan de connectivité de l’application du réseau sous-jacent, comme nous le verrons plus loin.
Dans l’évolution vers une architecture de cloud distribué, le modèle SDN émergent consiste à orchestrer conjointement les réseaux sous-jacents et superposés et à permettre la programmabilité de bout en bout du chemin d’application.
Avec l'Edge 2.0, nous devons apporter ce semblant de stabilité même en connectant les réseaux d’entreprise. Nous proposons que le plan de connectivité des applications soit séparé de la connectivité du réseau d’entreprise. Le modèle de connectivité des applications peut ou non suivre la même connectivité SDN que celle observée dans les centres de données superposés (par exemple, VXLAN, NVGRE ou autres) ou les modèles SDN basés sur BGP.
Tous les réseaux n’ont pas été séparés en superposés et sous-jacents. Les équipes chargées des réseaux considèrent désormais la nécessité de cette programmabilité conjointe comme une exigence importante pour permettre l’automatisation de bout en bout, pour laquelle la séparation du réseau sous-jacent et du réseau superposé est essentielle.
En séparant le plan d’application du réseau sous-jacent et du transport, les équipes réseau n’ont plus besoin de répondre activement à chaque demande d’application. Sa portée se limite alors à fournir des chemins robustes, stables et bien définis, en se concentrant sur l’optimisation de l’utilisation de la bande passante globale aux latences les plus faibles.
Modèle d’interface adaptatif
Le principe essentiel d’un EAP est qu’il est indépendant, autonome et qu’il gère un sous-ensemble de l’espace global des solutions. Mais les EAP ont besoin d’un moyen pour communiquer et offrir leurs ressources ou demander des ressources aux autres EAP. Cette approche présente plusieurs avantages.
Une interface basée sur les résultats annule la nécessité pour l'EAP de connaître les détails de l’autre infrastructure. Supposons qu’il y ait deux EAP : A et B. Chaque EAP dispose d’une portée locale de son infrastructure pour programmer et réserver des ressources. L'EAP-A n’a pas besoin de connaître les ressources fournies par l'EAP-B. Si, par exemple, l'EAP-A ne peut pas satisfaire les besoins de l’application et demande des ressources dans l’infrastructure qui sont dans la portée de l'EAP-B, elle peut simplement exprimer son objectif souhaité à l'EAP-B. Il incombe alors à l'EAP-B d’invoquer des interfaces déclaratives ou impératives pour réserver, allouer et configurer à partir de son pool de ressources libres. Il incombe également à l'EAP-B de s’assurer que les SLO de ce service au sein de son infrastructure sont respectés.
Bien qu’une syntaxe commune soit utile pour amorcer un ensemble initial d’API adaptatives, la mise en œuvre devient plus sophistiquée et mature au fil du temps, avec l’utilisation du traitement du langage naturel et de l’IA pour réduire la qualité requise des entrées.
Les différents modèles opérationnels deviennent également simples lorsque seul l’état souhaité doit être spécifié. Les schémas de résilience, par exemple, peuvent simplement être basés sur un SLO attendu. Il devient de la responsabilité de l'EAP fournissant le service de s’assurer que les ressources dans sa portée sont allouées pour atteindre les objectifs de niveau de service. L'EAP appelant n’a pas à s’en soucier, mais il devra probablement surveiller les paramètres du service pour savoir s’ils sont atteints ou non.
Caractéristiques de l'EAP
- Multi-tenant : si le maillage de l'EAP illustré à la figure 9 correspond à un déploiement unique, plusieurs EAP par cloud sont possibles. Une autre application pourrait communiquer avec un autre EAP ou un maillage d'EAP.
- Conçue pour évoluer : chaque maillage est un maillage peer-to-peer (P2P) et peut évoluer horizontalement. Les EAP pairs peuvent savoir indépendamment quels EAP disposent de quel type de ressource et comment s’y connecter. L’AI/ML améliorera encore la façon dont chaque EAP planifie les ressources dans sa propre portée ou fait appel à d’autres EAP si nécessaire.
- Mise en réseau intégrée : pour que les applications puissent se connecter dans le cloud distribué, l'EAP doit prendre en charge la mise en réseau intégrée, indépendamment de l’infrastructure sous-jacente.
Mise en place
La figure 12 visualise le rôle des différentes couches lors du déploiement d’une application sur un cloud distribué.
Les points forts de cette représentation sont :
- Chaque EAP a un périmètre localisé, et toutes ses capacités ne sont pas indiquées sur la figure 10. L'EAP doit prendre en charge la fonction de découverte des ressources et de programmation. Les EAP programment les ressources en se connectant au contrôleur d’infrastructure approprié via des API adaptatives.
- La connectivité des applications n’a rien à voir avec la connectivité du réseau : comme dans le modèle sidecar à maillage de services, les ressources permettant de connecter les applications à travers le multi-cloud doivent faire partie de l’infrastructure applicative. On pourrait dire que le plan d’infrastructure fournit également la connectivité du réseau d’applications et devrait donc se trouver sous la couche réseau. Ce serait également vrai d’un point de vue technique, mais nous avons choisi de l’englober dans le plan de « connectivité des applications » car il s’agit principalement de fonctions réseau.
- Le plan d’infrastructure doit être considéré comme distinct du plan d’application.
- La connectivité du réseau est différente du transport, car nous parlons essentiellement de réseaux spécifiques routables qui sont distincts de la connectivité des applications.
- Le plan de transport peut être considéré comme des réseaux fédérateurs agrégés qui peuvent être fournis, à condition que le fournisseur de télécommunications permette aux processus et aux API de connecter la couche réseau supérieure.
Résumé
Ce livre blanc tente d’approfondir un peu plus le manifeste original Edge 2.0. Nous avons introduit quelques nouveaux thèmes, dans le but d’informer les différentes parties prenantes au sein des organisations internes et à l’extérieur du secteur.
L'Edge 2.0 repose sur la notion de cloud distribué où chaque entité peut participer en tant que source ou destination de services. Le thème principal est que la technologie Edge 2.0 portera sur l’expérience et non sur le bien ou l’emplacement.
La plateforme d’applications de périphérie/Edge (EAP) est présentée comme une pile de capacités permettant de réaliser l'Edge 2.0 sur un cloud distribué.
Les détails de mise en œuvre ont été délibérément omis afin de présenter une vue indépendante du fournisseur.
Ressources
2 https://www.f5.com/pdf/reports/f5-office-of-the-cto-report-continuous-api-sprawl.pdf
3 Wikipédia — Un système autonome (AS) est une collection de préfixes de routage du protocole Internet (IP) connectés sous le contrôle dʼun ou plusieurs opérateurs de réseau pour le compte dʼune entité administrative ou dʼun domaine unique qui présente une politique de routage commune et clairement définie à lʼInternet.