Table des matières
Introduction
La définition de la périphérie a toujours été étroitement liée à l’évolution de l’architecture du centre de données. La dernière décennie a été témoin d’une transformation rapide de l’architecture de l’infrastructure d’entreprise, passant des centres de données sur site aux architectures cloud distribuées d’aujourd’hui. Nous reconnaissons Edge 2.0 comme un changement technologique qui permettra aux applications de tirer parti d’une architecture cloud distribuée.
Chaque personne, organisation ou entité a une interprétation différente de la limite. Certains pourraient considérer que le bord est une tour cellulaire, d’autres pourraient dire que leur appareil mobile est le bord. Pour les fournisseurs de services cloud (CSP), la périphérie est une empreinte d'infrastructure gérée qui s'intègre de manière transparente à leur back-end. Pour les applications militaires, le bord est le théâtre de la bataille, que ce soit sur terre, en mer ou dans les airs. Chaque fois que nous lisons à propos de la périphérie, l’interprétation est généralement résumée comme les capacités de calcul, de mise en réseau et de stockage de l’infrastructure et/ou de son emplacement.
Mais nous voyons également Edge 2.0 comme l’expérience qu’il offre à toutes les parties prenantes de l’écosystème, et pas seulement à l’infrastructure ou à son emplacement.
Ce document décrit quelles devraient être les fonctionnalités d'Edge 2.0, indépendamment de son infrastructure physique ou virtuelle, ou de l'endroit où elle se trouve ou est instanciée. L’objectif n’est pas d’expliquer comment créer une meilleure application distribuée, mais d’éclairer les capacités qui doivent figurer dans Edge 2.0 pour prendre en charge la création des applications distribuées les plus optimales qui répondent à une exigence particulière.
Qu'est-ce que Edge 2.0 ?
Du point de vue d’une entité qui réside sur ce cloud distribué, la périphérie se trouve là où l’entité se trouve actuellement. Nous proposons donc une définition d’Edge 2.0 centrée sur l’expérience, non liée uniquement à l’emplacement de l’infrastructure, au type d’infrastructure ou à l’entité de contrôle.
L’objectif d’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 (telles que les SLA et les SLO) de l'application en s'adaptant aux besoins changeants 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 à grande échelle, en prenant en charge de manière transparente les objectifs de sécurité, de gouvernance et de niveau de service.
A titre d’exemple, prenons une application bancaire. L’objectif d’Edge 2.0 n’est pas d’améliorer la logique métier de la transaction. Il s’agit de le rendre plus sûr, plus rapide, privé, utilisable dans toutes les zones géographiques (selon les besoins) et évolutif à la hausse ou à la baisse selon les besoins pour soutenir les objectifs commerciaux.
Concepts et assertions
Voici les concepts et affirmations clés de cet article :
- Edge centré sur l'expérience : Établit une base pour Edge 2.0 autour de l’expérience qu’il offre, plutôt que d’un actif ou de ses emplacements.
- Considérations relatives à la conception : Spécifie les considérations de conception clés pour une implémentation réussie de l'architecture Edge 2.0.
- Infrastructures hétérogènes : Souligne que la conception d’un cloud distribué implique de prendre en compte le contrôle décentralisé de l’infrastructure.
- La télémétrie comme fondement : Met l’accent sur la télémétrie en tant qu’élément fondamental qui doit être pris en charge à tous les niveaux de l’infrastructure. Sans télémétrie, une stratégie axée sur les données devient diluée.
- Défis inter-clusters : Souligne un défi fondamental avec Edge 2.0, celui d'être inter-cluster plutôt qu'intra-cluster.
- Interfaces adaptatives : Présente les interfaces adaptatives, offrant une comparaison distincte avec les interfaces déclaratives et impératives.
- Plateforme d'application Edge 2.0 (EAP) : Présente l'EAP comme un cadre permettant à 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 cet article :
- Distribution des données d'application : Il existe de nombreux sous-sujets ici tels que les réseaux de diffusion de contenu (CDN), la distribution de stockage, la distribution de données, la mise en cache, etc. Il existe également des technologies émergentes telles que le type de données répliqué sans conflit (CRDT). Un framework Edge 2.0 doit inclure la prise en charge de la distribution des données d’application dans son champ d’application.
- Répartition des fonctions : L’avancement du calcul de pointe peut être considéré comme une logique et des fonctions cloud de base, se rapprochant de l’endroit où l’événement est généré ou où résident les données. En raison de la quantité importante de calcul disponible en périphérie, nous devons désormais résoudre des problèmes similaires à ceux généralement résolus dans les architectures cloud héritées si nous souhaitons tirer parti de ce calcul. Par exemple, la mise en réseau superposée, les charges de travail middleware et d'autres types de charges de travail qui sont étroitement liées et plus complexes que les cas d'utilisation naïfs que nous avons vus dans les premiers Edge, par exemple les storlets, qui sont des flux simples sans état à exécuter à côté des données.
- Il y a probablement d’autres domaines qui n’ont pas été abordés. L’objectif du framework est d’être extensible afin que les responsabilités puissent être ajoutées selon les besoins.
Évolution des bords
La figure 1 illustre le mieux la co-évolution des architectures Edge et Datacenter. Edge 1.0 et 1.5 étaient basés 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 d'infrastructure Internet principalement axé sur l'optimisation de l'utilisation de la bande passante avec la mise en cache de contenu distribuée, également appelée 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.
Alors que les coûts du processeur et de la mémoire ont chuté, des fermes de calcul sont apparues parallèlement aux nœuds CDN. Les applications étaient consommées en tant que services via des architectures orientées services (SOA). D'où la référence à Edge 1.5 comme réseau de distribution de services.
Une caractéristique commune d’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 à l’origine du service était toujours différent de celui du consommateur.
Cependant, dans Edge 2.0, n’importe quelle entité peut agir en tant que site d’origine ou en tant que consommateur. Le flux de circulation a changé. Les humains, les téléphones et les appareils produisent activement des données lorsqu’ils téléchargent du contenu ou génèrent 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 headless. De son propre point de vue, chaque entité de l’infrastructure pense qu’elle est à la périphérie.
Le cloud distribué est la dernière étape de l’évolution du datacenter. L’informatique est devenue véritablement omniprésente, depuis les appareils mobiles jusqu’aux objets du quotidien connectés au réseau. Parallèlement à cela, des architectures logicielles ont évolué pour permettre des applications distribuées et évolutives.
Conséquences marginales : Complexité accrue
L’abondance et l’hyper-distribution des ressources de calcul et de stockage partout ont créé une opportunité de transformation numérique rapide de l’entreprise. Mais cette évolution rapide a ses conséquences.
La plupart des entreprises sont généralement constituées 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 de la part des systèmes déployés. Les changements rapides des besoins de l’application, tels que les changements dans les exigences en matière de processeur 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.
Les conséquences de ces problématiques sont une complexité opérationnelle qui neutralise tout gain potentiel pour une entreprise en pleine transformation numérique.
Certains des problèmes et des artefacts interdépendants qui résultent de la complexité sont mis en évidence ci-après.
Les clouds hybrides génèrent une surface accrue qui peut être compromise en raison de divers vecteurs d’attaque. Différents cas d’utilisation créent de multiples défis de sécurité et, à mesure que l’infrastructure évolue, nous sommes constamment à la poursuite de la rondelle. Le problème que nous anticipons est donc le suivant : seules les recommandations technologiques changeront-elles souvent, ou les modèles de conception pour mettre en œuvre la sécurité changeront-ils également ?
Voici quelques-uns des problèmes liés aux approches existantes :
- Le périmètre défini par logiciel (SDP) n'est pas facilement évolutif, car les solutions populaires sont basées sur des agents, ce qui ne se prête pas à des déploiements opérationnels simples.
- La mise en œuvre de l'accès au réseau Zero Trust (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 PKI globale et la gestion des identités, etc.
- Secure Access Service Edge (SASE) combine le réseau en tant que service et la sécurité en tant que service, un mélange d'acronymes de plusieurs technologies non triviales à mettre en œuvre. De plus, l’accent du SASE tend à être centré sur le réseau étendu défini par logiciel (SD-WAN), s’adressant à un petit segment des cas d’utilisation de périphérie de réseau d’entreprise.
- La disparité entre les infrastructures des différents fournisseurs de cloud public 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 renforcement disparate des fournisseurs et à des configurations multicloud lourdes.
L’un des principaux défis liés à l’hyperdistribution des ressources de calcul à faible consommation et à faible coût disponibles en périphérie est la capacité à orchestrer et à planifier l’infrastructure de manière uniforme. Les équipes d’exploitation ont du mal à faire évoluer et à prendre en charge les applications qui exploitent le cloud distribué, car ces applications incluent généralement des technologies hétérogènes avec des exigences d’administration différentes.
Bien que les plateformes d’automatisation comme Terraform fournissent un moyen sophistiqué de personnaliser l’automatisation, les équipes d’exploitation doivent toujours maintenir des scripts pour plusieurs permutations : par exemple, cinq types différents de calcul, 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’est pas évolutif.
Cela conduit à une interaction continue du client de l’infrastructure avec les équipes d’exploitation via des systèmes basés sur des tickets, ce qui constitue un obstacle à l’automatisation des flux de travail existants. Le service d'assistance est submergé de tickets et doit privilégier la sécurité et la stabilité plutôt que l'agilité.
Les architectures de 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 en tout lieu, ce qui entraîne une prolifération des API. La découverte, la connectivité et la gestion de ces API de manière autonome deviennent un grand défi.
Un changement de paradigme est nécessaire pour lutter contre la prolifération des API. Nos modèles internes démontrent que même des hypothèses modérées sur des paramètres, comme le nombre de développeurs d’API mondiaux, 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 sur l’étalement des API fournit une vue complète de ce sujet émergent.
La complexité accrue exige que les entreprises permettent une visibilité granulaire et significative de bout en bout du système. Dans les environnements cloud distribués, les applications transcendent plusieurs piles d’infrastructures hétérogènes gérées par des entités distinctes.
De plus, aucun des opérateurs n’est aujourd’hui incité à exposer la télémétrie native de son infrastructure aux clients d’entreprise. Les entreprises fonctionnent essentiellement à l’aveugle lorsqu’elles déploient des applications dans un cloud distribué et doivent recourir à plusieurs outils d’observabilité. Pour combler ces lacunes de visibilité, les outils proviennent généralement de différentes sociétés fournisseurs travaillant à différents points de l’infrastructure ou des piles d’applications.
Les mesures d’infrastructure non standard ajoutent aux problèmes d’une entreprise. En règle générale, les mesures ne sont pas unifiées en raison de silos opérationnels et d’autres facteurs tels qu’une infrastructure non uniforme dans différents environnements d’infrastructure. Par exemple, les mesures entre les fournisseurs de cloud public sont différentes et les technologies de centre de données sur site ne suivent pas non plus de mesures standard.
Résultat commercial : Expérience diminuée
Les charges de travail génératrices de revenus et les systèmes critiques utilisent généralement la plupart des ressources opérationnelles et du budget disponibles dans une entreprise. Pendant ce temps, les projets plus petits, bien que moins complexes, tendent à constituer le volume des applications de l’entreprise. La figure 3 illustre cela comme une distribution à longue traîne du nombre de projets qu’une entreprise est susceptible d’avoir par rapport à sa complexité opérationnelle.
Même si les applications plus petites peuvent être moins complexes sur le plan opérationnel, les processus et les flux de travail d'opérationnalisation restent dans de nombreux cas manuels, et il peut falloir des semaines pour que les tickets de service parviennent à transiter avec succès 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 que les équipes de sécurité mondiales élaborent les approbations des politiques de sécurité. Le ticket de service peut ensuite être transmis à l'équipe réseau pour planifier les configurations de sous-réseau et d'itinéraire qui doivent être effectuées. Enfin, la validation des règles du pare-feu peut être requise par une autre équipe opérationnelle responsable de la gestion du pare-feu.
Imaginons maintenant que la complexité ci-dessus doit ê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 volume considérable de petits projets ou d'applications qui doivent être intégrés et pris en charge rend irréaliste pour les équipes d'exploitation la prise en charge de chaque projet, créant ainsi un problème de priorisation et une opportunité de libre-service.
Ce problème de priorisation est particulièrement visible lorsque les investissements des équipes d’infrastructure sont concentrés sur le support des 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 préparation avant la production. Cela entraîne une diminution des capacités et des investissements en faveur de la vitesse des fonctionnalités, de la personnalisation et de l’innovation qui prend en charge les nouveaux produits, ce qui aboutit à la stagnation de l’entreprise et de ses offres.
Espace de solutions Edge
L’évolution de l’écosystème Edge élargit considérablement l’espace de solution en offrant la possibilité de relever ces défis avec une plateforme d’application.
La figure 4 montre l’espace de solution Edge 2.0. Nous affirmons ici que tout ce qui relève d’une architecture cloud distribuée constitue la totalité de l’espace de solution.
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 : applications, humains et appareils qui agissent en tant que consommateurs, ou applications back-end Web et headless qui composent les services.
- Les équipes SRE et les propriétaires d'applications de ces applications, tout en préservant les garde-fous de sécurité et réglementaires attendus de l'infrastructure.
Edge 2.0 sera opérationnellement 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 sur la conception d'Edge 2.0
Sécurisé par défaut
Un cloud distribué amplifie ce problème de sécurité à grande échelle à mesure que le nombre de points de terminaison augmente de manière exponentielle. Avec une échelle aussi massive, la complexité de la mise en œuvre d’une solution augmente également. La posture de sécurité doit être telle 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’exécute sur elle.
La base de ces idées est capturée dans les concepts de l’état d’esprit Zero Trust, et l’exemple BeyondCorp1 démontre ces concepts pour le cas d’utilisation de l’accès aux applications. À l’avenir, Edge 2.0 étend ce modèle, basé sur les cinq principes fondamentaux suivants :
- L'identité est fondamentale : Dans Edge 2.0, l’identité est profonde, chaque instance d’entité ayant sa propre identité unique au niveau mondial, mais également sa place dans la hiérarchie de l’organisation ainsi que son niveau de privilège. L’identité devrait être une considération clé non seulement pour le trafic nord-sud, mais aussi en interne pour l’accès est-ouest.
- Privilège minimum : Les actions autorisées par un acteur doivent être limitées à celles dont l’acteur a besoin pour remplir son rôle dans le système. Un exemple consiste à limiter le sous-ensemble de charges de travail autorisées à communiquer avec le serveur de base de données en fonction de la spécification de conception.
- Authentification continue : Toute attestation faite par un acteur du système doit être assortie d’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 via des secrets partagés ou une chaîne de confiance, mais doit également prendre en compte des modèles implicites de comportement et des métadonnées contextuelles.
- Surveillance et évaluation constantes : Les actions de tous les acteurs du système doivent être surveillées, renforçant le rôle clé des technologies de collecte et de stockage de données dans une architecture Edge 2.0. De plus, ces activités doivent être évaluées en permanence afin de détecter et d’atténuer les tentatives d’exécution d’actions interdites ou dangereuses. L’évaluation doit être réalisée en temps quasi réel, à grande échelle, impliquant une utilisation abondante des techniques d’automatisation et d’apprentissage automatique.
- Supposer une violation : Compte tenu des ressources dont disposent les adversaires sophistiqués d’aujourd’hui, on doit 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 la charge de travail et les identités des utilisateurs, imposant un accès basé sur les privilèges représentés par a et b, sont souvent insuffisantes pour empêcher toutes les attaques. Par conséquent, un système Edge 2.0 pleinement mature doit également être capable d’effectuer des évaluations des risques et des récompenses en temps réel sur la base d’une surveillance et d’une évaluation continues.
Offre une observabilité native
Edge 2.0 doit intégrer la télémétrie en tant que citoyen de première classe au plus profond de la pile d'infrastructure, fournir un moyen simple et évolutif de collecter la télémétrie inter-couches au sein de l'infrastructure et la faire apparaître sur une plate-forme commune. Cela aide les équipes d’observabilité à faire apparaître l’interrogation de « l’état de l’infrastructure » selon les besoins. Cela permet aux équipes d’application de se concentrer sur la logique métier sans instrumenter explicitement leurs piles d’applications.
L’état actuel de la technologie d’observabilité est en grande partie propre au fournisseur et exclusif. Cela a conduit de nombreux agents spécifiques aux fournisseurs à collecter des signaux similaires qui se bousculent pour obtenir une mémoire et un processeur coûteux.
L’étape logique suivante est l’utilisation d’un collecteur de télémétrie indépendant du fournisseur qui permet de diffuser les données d’infrastructure et de trafic vers une plate-forme de données centralisée.
De nombreuses équipes de produits ont du mal à justifier l’investissement dans l’instrumentation, car l’effort doit être associé à une opportunité de revenus. L’infrastructure doit être instrumentée comme toute autre fonction ou processus commercial, car l’équipe doit comprendre son comportement pour l’optimiser en fonction des objectifs de l’entreprise. Le débat devrait donc davantage porter sur ce qui devrait être prioritairement instrumenté, plutôt que sur sa nécessité.
Pour obtenir des mesures granulaires et plus précises du comportement de l'application, nous prévoyons que l'instrumentation « se décalera vers la gauche » en l'invoquant au moment du code — Figure 5.
Prend en charge les interfaces adaptatives
Conformément au cloud distribué, en décortiquant quelques couches, chaque cloud dans sa portée (locale ou globale) dispose de son propre gestionnaire, administrateur, orchestrateur, etc. Chacun se comporte de manière indépendante, prend ses propres décisions, mais fournit des interfaces que d'autres entités peuvent utiliser selon les besoins.
Ainsi, la notion de cloud distribué est, par essence, une administration et un contrôle décentralisés. On ne peut pas échapper à ce fait, et il est important pour nous de le reconnaître afin de mieux comprendre les nuances des interfaces adaptatives, 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 fabriqués à la main qui sont essentiellement des constructions statiques qui ne s’adaptent pas assez rapidement aux conditions en évolution rapide.
C’est vers les résultats que nous devons tendre, et les systèmes doivent être suffisamment intelligents pour ajuster les politiques à travers l’infrastructure (de bout en bout) afin d’atteindre ces résultats. Nous appelons cela des interfaces adaptatives.
Pour être clair, les interfaces impératives, déclaratives et adaptatives ne s'excluent pas mutuellement :
Impératif: Il devient 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, bande passante requise, itinéraires 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 à ce que l’on connaisse à 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é des entrées est inférieure, même si elle nécessite 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 souhaité, plutôt que sur l’état. L’objectif de l’interface adaptative est de capturer l’objectif de la partie prenante qui souhaite déployer l’application plutôt que de se concentrer sur une connaissance préalable du système sous-jacent. Adaptive est différent car il n’a aucune idée des capacités de l’infrastructure sous-jacente. Il n’y a aucune contrainte sur la manière de « réaliser 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 demande 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 inter-cluster
Un cloud distribué, par définition, s'adapte à 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 à l’aide d’un maillage de services, mais un maillage de services ne résout ce problème qu’au sein du cluster (intra-cluster).
Les applications Edge 2.0, quant à elles, exploitent les API sur une infrastructure cloud hyperdistribuée, essentiellement un environnement multi-cluster. Les nouvelles applications sont écrites avec des API qui dépassent les frontières organisationnelles et géographiques. Certaines API peuvent être des API privées ou partenaires derrière plusieurs couches de pare-feu sans itinéraire explicite entre elles, même si elles sont détectables. Ce problème de cluster hétérogène (inter-cluster) ne dispose pas d'une 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. D'un point de vue programmatique, c'est le pseudo-code. |
L'interface adaptative exprime l'état souhaité comme une exigence sans faire aucune hypothèse sur les capacités des ressources sous-jacentes. Une interface adaptative appartient à l’infrastructure et permet à l’infrastructure de répondre de manière dynamique aux besoins changeants de l’application. |
Scénario 1 : Le colis doit être envoyé de SFO à New York |
Jane dit à Mark : (a) Imprimez l'étiquette d'expédition, (b) Allez au magasin UPS, (c) Choisissez la livraison en 72 heures, (d) Payez-la et expédiez-la Marque: Doit suivre un ensemble d'étapes très spécifiques |
Jane demande à Mark : (a) Veuillez envoyer ce colis à cette adresse, (b) Le colis doit arriver dans les 72 heures. Marque: Vous pouvez choisir n'importe quelle entreprise de messagerie (UPS, FedEx, DHL, etc.). |
Jane exprime à Mark : (a) Ce colis doit arriver à New York d'ici samedi. Marque: Il peut faire ce qu'il veut. Il pourrait même potentiellement prendre le colis 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ée avec cette politique. Ici, la tâche est spécifique à la marque, au modèle, à la version, etc. de l'équilibreur de charge. |
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 orchestration |
Aucune hypothèse sur l’infrastructure sous-jacente. Assurez-vous que l'application évolue selon les besoins, avec une latence maximale de 10 ms. |
Possession |
Copropriété : application et infrastructures |
Copropriété : application et infrastructures |
Seules les infrastructures |
Qualité des données saisies |
Extrêmement élevé. Nécessite une connaissance approfondie de la portée sous-jacente. Par exemple, vous devez savoir quel équilibreur de charge F5, quelle version du logiciel, etc. Une CLI ou un NMS serait un exemple d’interfaces impératives. |
Haut: Nécessite une connaissance des capacités de l’infrastructure. Par exemple, dans l’exemple ci-dessus, il existe une connaissance préalable de l’infrastructure prenant en charge un équilibreur de charge. |
Faible: Ne nécessite aucune connaissance des capacités de l'infrastructure. La qualité des entrées se rapproche de celle du langage naturel. |
Niveau de compétence (Persona) |
Compétences spécifiques à la fonction. Par exemple, administrateur réseau, administrateur informatique, administrateur de stockage. Chaque aspect de l'infrastructure exige que l'utilisateur soit un expert dans ce domaine. |
Compétences en déploiement d'applications. L'utilisateur connaît le type de fonction nécessaire pour déployer l'application. Comme dans le cas ci-dessus, le gestionnaire d’applications sait qu’un équilibreur de charge est nécessaire, ainsi que des 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 simplement signaler à l'infrastructure quelles sont les exigences non fonctionnelles de l'application. Dans ce cas, il s’agit de la rapidité avec laquelle l’application doit répondre à une demande client. D’autres facteurs tels que l’emplacement géographique, le coût, etc., peuvent être ajoutés selon les besoins. |
Portée |
Les interfaces impératives ont |
La portée déclarative est plus large. Généralement associé à un moteur d’orchestration qui communique avec plusieurs interfaces impératives pour obtenir le résultat requis. |
Portée très large car le résultat de |
Exemple |
- nom : mettre à jour les serveurs Web hôtes : serveurs Web utilisateur distant : root tâches : - nom : s'assurer qu'Apache est à la dernière version yum : nom : httpd état : le plus récent - nom : écrire le fichier de configuration d'Apache modèle : src : /srv/httpd.j2 dest : /etc/httpd.conf |
apache-server : version : « dernière » |
application-latence : - lt : 10 ms coût de l'infrastructure : - lt : 200 $ - facturation : mensuelle |
Nous avons abordé en détail les API dans le rapport API Sprawl 20212 et y abordons de nombreuses questions qui pourraient surgir. 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 est divisée en dizaines, voire centaines, d’API.
Quoi qu'il en soit, chaque cluster d'application est développé et géré de manière avisée. Par exemple, dans les cas d’architecture de microservices, une équipe peut utiliser n’importe quelle version de maillage de services : Istio, Linkerd, Aspen Mesh ou autres. Chaque approche dispose de ses propres moyens pour gérer et contrôler les API au sein de son cluster, en d’autres termes, intra-cluster.
Il existe de nombreuses solutions ici, et l’objectif d’Edge 2.0 n’est pas de réinventer ou de forcer les organisations ou les équipes de développement à adopter une énième nouvelle technologie.
Inter-Cluster : À mesure que le nombre de services fournis via les API augmente, de nouvelles applications sont créées à l’aide de 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. D’un point de vue architectural, 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 être situés sur n'importe quel bien immobilier pouvant héberger l'application ou faire partie du cluster d'applications.
Pour réitérer, la portée d’un cluster d’applications ne se limite pas uniquement au sein d’une organisation. Les clusters peuvent être répartis sur deux réseaux, applications, silos organisationnels ou même entre deux entreprises.
La portée couvre toute la gamme de toutes les permutations et combinaisons, augmentant ainsi de manière 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 y avoir différentes versions de service mesh, ou une application Web 2.0 basée sur une architecture orientée services, ou un déploiement logiciel monolithique, selon l'équipe qui le développe et le déploie. Les API sont ainsi dispersées dans toute l’entreprise, qu’il s’agisse d’API privées ou d’utilisation d’API publiques. Ce problème n'est pas encore résolu. La communication API entre plusieurs sites est essentielle et constitue un problème difficile à résoudre dans les entreprises de toute taille.
Il existe plusieurs solutions pour gérer les API au sein d'un cluster (par exemple, un contrôleur d'entrée, une passerelle API, etc.), tandis que la communication API inter-cluster n'est pas résolue de manière pratique, évolutive et sécurisée. Nous concentrons donc la portée du contrôle et de la gestion unifiés des API pour résoudre uniquement les problèmes inter-clusters.
Offre une autonomie
Une valeur sous-estimée du cloud est l’autonomie qu’il offre au « consommateur de cloud ». Les entreprises et les entrepreneurs peuvent créer leurs propres infrastructures à la demande tout en bénéficiant d’un semblant de contrôle total.
Le principe de conception fondamental qu’une plate-forme Edge 2.0 doit suivre est de fournir une expérience autonome au client cloud tout en mettant en œuvre les bonnes garde-fous. Étant donné que les entités peuvent apparaître dans n’importe quelle infrastructure (fiable ou non), les garde-fous doivent être mis en œuvre de manière à ne pas surcharger l’unité opérationnelle ou l’équipe DevOps chargée de créer l’application.
Le défi émergent avec 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 peut être important. Comment les équipes découvrent-elles ces services au sein de l’entreprise ? Ou alors, comment peuvent-ils savoir si les services sont toujours valables et à qui ils appartiennent ? Peuvent-ils être sûrs qu’il s’agit d’un service validé avec une confiance établie ? Le problème est aggravé lorsque les équipes souhaitent consommer des services créés par des clusters résidant en dehors des limites de l’entreprise, par exemple des fournisseurs SaaS ou des applications qui s’exécutent sur des appareils périphériques, complètement hors du contrôle administratif des équipes d’infrastructure de l’entreprise.
Plateforme d'applications 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 définissons l’objectif de la solution : découvrir de manière autonome (sans intervention humaine), faire évoluer et sécuriser les applications distribuées sur une infrastructure décentralisée.
Essentiellement, 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 des applications
Portée du PAE
L'infrastructure est la totalité de l'espace de solution où les éléments d'infrastructure peuvent apparaître et disparaître en permanence. La propriété de l’infrastructure et de ses ressources, d’une part, et l’administration et le contrôle de ces ressources, d’autre part, sont deux constructions distinctes. Le propriétaire d'une infrastructure peut attribuer une infrastructure spécifique ou une instance de celle-ci à une autre organisation 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 applications individuels. Cette notion n’est pas nouvelle ; par exemple, les fournisseurs de services cloud offrent un contrôle administratif hiérarchique qui peut être utilisé par les équipes informatiques d’une entreprise pour proposer davantage d’infrastructures en tant que service (IaaS) aux unités commerciales internes, aux équipes, etc. La principale préoccupation concernant Edge 2.0 est de savoir comment y parvenir de manière extensive dans un cloud hyper-distribué, qui est l’état actuel et futur de l’infrastructure Edge.
C’est ici que la portée du PAE entre en jeu. La figure 8 ci-dessous montre la portée de l’EAP dans le contexte de différents types d’interfaces. Chaque EAP s'orchestre avec sa portée locale en utilisant des interfaces déclaratives et impératives. Dans ce cas :
- Les API déclaratives/impératives seraient les API AWS, les API Azure, etc.
- Les interfaces adaptatives seraient de nouvelles fonctionnalités qui devraient être définies 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 via un cloud distribué. L’objectif est que l’EAP individuel devienne équivalent au concept de système autonome3 dans les réseaux IP, mais pour la couche application.
En mettant tout cela ensemble (Figure 9 ci-dessous), nous pouvons maintenant construire une vue d’ensemble de la manière dont plusieurs EAP peuvent être déployés dans une infrastructure cloud décentralisée interagissant les uns avec les autres de manière autonome.
Les interfaces adaptatives facilitent également l’intégration des CI/CD et d’autres applications du cycle de vie des applications au 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.
Le cadre du PAE
Le cadre EAP, comme illustré dans la figure 10, organise les responsabilités en termes de capacités de chaque instance EAP. Le rôle de l'EAP est de s'interfacer avec les contrôleurs d'infrastructure sous-jacents, qu'il s'agisse d'infrastructure en tant que service (IaaS), de plate-forme en tant que service (PaaS), de logiciel en tant que service (SaaS), et d'orchestrer et de planifier les ressources appropriées selon les besoins.
Contrôle et gestion unifiés des API
L’avenir sera une économie pilotée par les API, où les API seront plus qu’une simple approche d’architecture logicielle simplifiée grâce au maillage de services. Une API deviendra le principal moyen par lequel toute entité participant à un cloud distribué fournit son service.
Comme établi, le nombre mondial d’API publiques et privées qui seront disponibles atteindra des centaines de millions, voire des milliards, au cours de la décennie. Les API vont remodeler notre économie et nécessitent donc un examen plus approfondi de ce que le PAE doit mettre en œuvre pour soutenir cette économie.
La prolifération des API exige que chaque API soit détectable à l'intérieur et à l'extérieur de l'EAP. Avec le cloud distribué, les API peuvent être situées n’importe où sur plusieurs clusters.
L’hypothèse sous-jacente est que le problème de découverte d’API est véritablement un problème inter-cluster. La portée d’un EAP peut s’étendre à de nombreux clusters d’applications qui utilisent différentes approches logicielles (des microservices aux monolithiques), chacune implémentant 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, pas seulement au sein du 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 la cohérence, la précision et le contrôle de version. L'EAP met en œuvre un moyen d'informer les entités utilisant ses API sur l'état actuel des API spécifiques utilisées. Cela pourrait 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 dans laquelle une application suppose que l’infrastructure dans laquelle elle est actuellement déployée est déjà compromise.
Le pilier clé pour mettre en œuvre cette posture de sécurité est axé sur l’identité. Chaque point de terminaison d’API doit avoir une identité unique à l’échelle mondiale. Les politiques et contrôles de sécurité sont conservés séparément dans un référentiel central.
Les API doivent être marquées comme publiques ou privées, 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 applications commencent par une politique de refus total. Ce n’est pas parce qu’une API est visible qu’une autre application peut l’appeler. Cela doit être explicitement configuré dans la politique de sécurité de l'application.
L'EAP doit garantir que toutes les API relevant de son champ d'application sont fiables et que, dans le même temps, toutes les API externes utilisées par les services relevant de son champ d'application sont également fiables.
« On ne peut pas prouver la confiance, c’est ce qui fait la « confiance » » – Extrait de Traitors @ Netflix
La confiance est essentiellement une « réputation au fil du 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 au fil du temps peut constituer un défi pour certaines entreprises qui n’ont pas le luxe du temps nécessaire pour établir une réputation mutuelle entre leurs systèmes et ceux de tiers. L’infrastructure et les API peuvent toutes deux faire des ravages si leur réputation n’est pas surveillée de près.
En supposant qu'un service dans le cadre du protocole EAP accède à une API externe, la plateforme doit implémenter un mécanisme permettant au service appelant de s'assurer 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 fiable. Soit la réponse pourrait être inexacte en raison de problèmes de qualité, soit des inexactitudes pourraient avoir été explicitement insérées pour rendre l’entreprise moins compétitive. Avoir cette capacité d'attribuer un facteur de confiance à chaque API, interne ou externe, est unique à la construction EAP.
Une stratégie pour mettre en œuvre la confiance consiste à la moyenne sur une « période » la plus récente plutôt que sur l’historique complet du service. C'est comme comparer les « meilleurs avis » et les « plus récents » pour un produit sur Amazon. Le produit peut très 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 ne se limite pas à la question de savoir si une API est ou non une source connue de données fausses ou trompeuses. La réputation d’un EAP dépendra également de la manière dont il gère et met à jour les API dans son périmètre. De plus, 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.
Gestionnaire d'infrastructure Edge
Le cloud distribué étant la base de l’infrastructure Edge 2.0, il devient impératif que les ressources dans le cadre 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 pour les capacités du gestionnaire de l’infrastructure de périphérie.
Dans le cadre d’un PAE, les ressources peuvent être planifiées selon les besoins. De nouvelles ressources peuvent arriver ou partir de manière dynamique en raison de la mobilité. Un EAP peut également envoyer ou recevoir des demandes d'autres EAP pour découvrir et planifier les ressources nécessaires 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 ainsi assurer la sécurité de l'application déployée sur son périmètre.
Quel que soit le niveau administratif, le cadre EAP doit prendre en compte de multiples facettes de la sécurité, telles 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 risques peuvent être atténués en utilisant les meilleures pratiques existantes en matière de sécurité, comme la prévention des attaques DDoS, le pare-feu, etc. La recommandation est qu'elle soit obligatoire pour tout trafic.
L'homme du milieu : Tout le trafic doit être chiffré et on ne peut pas supposer que la couche d’application fera la bonne chose. Cela garantit la confidentialité de base des données contre tout dispositif d’espionnage du trafic et protège l’intégrité des données contre toute manipulation pendant la transmission.
Menaces internes : La portée de la couche d’infrastructure doit être limitée et principalement destinée à se protéger. La recommandation est d’empêcher une ressource au sein de l’infrastructure de lancer une attaque interne sur le gestionnaire de l’infrastructure.
Si Edge 2.0 se concentre sur l’expérience qu’il offre et non sur l’actif ou son emplacement, il s’ensuit naturellement que la télémétrie doit également être centrée sur l’expérience.
La question est : à quelle expérience faisons-nous référence ? L'expérience est celle de toute entité qui réside ou utilise une infrastructure pour produire ou consommer un service : applications, appareils, humains, applications back-end, 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 se contenter de mesurer l’expérience ; il faut aussi trouver un moyen d’y remédier.
Toute entité qui consomme ou fournit un service peut déterminer si elle obtient l’expérience demandée. Cependant, dans les environnements cloud distribués, il peut être presque impossible d’expliquer ce qui s’est passé dans la couche d’infrastructure qui a conduit à la mauvaise expérience.
Les mesures de haut niveau telles que l’utilisation du processeur, la mémoire, 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 en profondeur dans la pile d'applications 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 essentielle pour l’EAP. Les stratégies d’apprentissage automatique (ML) et d’intelligence artificielle (IA) peuvent ensuite être exploitées pour prendre la meilleure décision concernant la réservation de nouvelles ressources ou l’optimisation de l’utilisation des ressources existantes.
Connectivité des applications définies par logiciel
Bien que la connectivité et l’accessibilité soient considérées comme des problèmes résolus, de nombreuses équipes réseau ont encore du mal à rationaliser leur structure réseau avec les besoins dynamiques de la couche applicative. Une plateforme doit également répondre à ces défis.
Le problème avec les 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 permettant d’aborder un réseau cloud distribué peuvent 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 parviennent donc pas à garantir un comportement cohérent.
Le seul moyen par lequel nous pouvons obtenir un réseau évolutif, sécurisé et stable à l’échelle mondiale pour l’application est de séparer le plan de connectivité de l’application du réseau sous-jacent, comme indiqué ci-après.
Dans l’évolution vers une architecture cloud distribuée, 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 Edge 2.0, nous devons apporter ce semblant de stabilité même avec la connexion des 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é de l'application peut ou non suivre la même connectivité SDN que celle observée avec la superposition du centre de données (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 superposition et sous-couche. Les équipes réseau voient 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.
La séparation du plan d’application du réseau sous-jacent et du transport élimine la nécessité pour les équipes réseau de répondre activement à chaque demande d’application. Son champ d'application se limite à fournir des chemins robustes, stables et bien définis, en mettant l'accent sur l'optimisation de l'utilisation de la bande passante globale aux latences les plus faibles.
Modèle d'interface adaptatif
Le principe clé d’un EAP est qu’il est indépendant, autonome et qu’il gère un sous-ensemble de l’espace de solution global. Mais les PAE ont besoin d’un moyen de communiquer et d’offrir leurs ressources ou de demander des ressources à d’autres PAE. Cette approche présente plusieurs avantages.
Une interface basée sur les résultats élimine la nécessité pour le PAE de connaître les détails de l’autre infrastructure. Supposons qu'il existe deux PAE : A et B. Chaque EAP dispose d'une portée locale de son infrastructure pour planifier 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, EAP-A ne peut pas satisfaire les besoins de l’application et nécessite des ressources dans l’infrastructure qui relèvent du champ d’application d’EAP-B, il peut alors simplement exprimer son objectif souhaité à EAP-B. Il incombe alors à EAP-B d’invoquer des interfaces déclaratives ou impératives pour réserver, allouer et configurer à partir de son pool de ressources libres. L'EAP-B est également chargé de garantir que les SLO pour ce service au sein de son infrastructure sont respectés.
Bien qu’une syntaxe commune soit utile pour démarrer 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.
Différents modèles opérationnels deviennent également simples lorsque seul l'état souhaité doit être spécifié. Les modèles de résilience, par exemple, peuvent simplement être basés sur un SLO attendu. Il incombe au PAE fournissant le service de s’assurer que les ressources relevant de son champ d’action sont allouées de manière à atteindre les objectifs de niveau de service. L'EAP appelant n'a pas besoin de s'en soucier, mais devrait probablement surveiller les mesures de service pour savoir si elles sont respectées ou non.
Fonctionnalités EAP
- Multi-locataire : Bien que le maillage des EAP illustré dans la figure 9 soit destiné à un déploiement unique, plusieurs EAP par cloud sont possibles. Une autre application pourrait communiquer avec un EAP différent ou un maillage d’EAP.
- Conçu pour évoluer : Chaque maillage est un maillage peer-to-peer (P2P) et peut évoluer horizontalement. Les EAP homologues peuvent suivre de manière indépendante quels EAP ont quel type de ressource et comment se connecter à la ressource. L’IA/ML améliorera encore davantage la manière dont chaque EAP planifie les ressources dans son propre champ d’application ou communique avec d’autres EAP selon les besoins.
- Réseau intégré : Pour que les applications se connectent via 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 du tout
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 une portée localisée et toutes ses capacités ne sont pas indiquées dans la figure 10. L'EAP doit prendre en charge la fonction de découverte et de planification des ressources. Les EAP planifient les ressources en s'interfaçant avec le contrôleur d'infrastructure approprié via des API adaptatives.
- La connectivité des applications n’est pas la même que la connectivité réseau : comme dans le modèle sidecar de service-mesh, les ressources permettant de connecter des applications sur plusieurs clouds doivent faire partie de l’infrastructure des applications. On pourrait soutenir que le plan d’infrastructure fournit également la connectivité du réseau d’application et devrait donc se situer en dessous de la couche réseau. Cela serait également techniquement correct, mais nous avons choisi de l’intégrer 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é réseau est différente du transport, car nous parlons essentiellement de réseaux routables spécifiques qui sont distincts de la connectivité des applications.
- Le plan de transport peut être considéré comme un ensemble de réseaux dorsaux agrégés qui peuvent être provisionnés, à condition que le fournisseur de télécommunications permette aux processus et aux API de connecter la couche réseau au-dessus.
Résumé
Ce livre blanc tente d'approfondir quelques couches supplémentaires du manifeste Edge 2.0 original. Nous avons introduit de nouveaux thèmes, dans le but d’informer les différentes parties prenantes au sein des organisations internes et externes à l’industrie.
Edge 2.0 repose sur la notion de cloud distribué où chaque entité peut participer à la fois en tant que source et destination des services. Le thème principal est qu’Edge 2.0 sera axé sur l’expérience et non sur l’actif ou l’emplacement.
La plateforme d’application Edge (EAP) est présentée comme une pile de fonctionnalités permettant de réaliser Edge 2.0 sur un cloud distribué.
Les détails de mise en œuvre ont été délibérément ignorés pour 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 un ensemble de préfixes de routage IP (Internet Protocol) connectés sous le contrôle d'un ou plusieurs opérateurs de réseau au nom d'une seule entité administrative ou d'un seul domaine qui présente une politique de routage commune et clairement définie sur Internet.