Dans un passé encore récent, le monde des fournisseurs de services était marqué par une frontière très nette.
D’un côté, les équipes réseau et sécurité ont été le fer de lance de l’évolution vers une architecture NFV, en mettant fortement l’accent sur la virtualisation des fonctions réseau et de sécurité. Les incursions dans le monde de l’automatisation restaient pour le moins timides.
De l’autre côté, les développeurs ont adopté avec enthousiasme les plateformes cloud, DevOps ainsi que l’automatisation via des pipelines CI/CD. Le déploiement et la livraison rapides des applications étaient, et restent, la priorité absolue.
La périphérie est le point de convergence de ces deux univers, où les applications peuvent coexister harmonieusement avec les fonctions réseau.
Grâce à sa nature distribuée et porté par le déploiement progressif de la 5G à l’échelle mondiale, l’edge computing commence enfin à permettre aux fournisseurs de services de proposer de nouvelles solutions et de nouveaux services qui augmentent leurs sources de revenus tout en réduisant les coûts de transport du réseau.
Au lieu de transmettre les données vers le cloud ou un entrepôt de données central à des fins d’analyse, leur traitement peut être effectué à la « périphérie » du réseau, ce qui réduit la latence du réseau, augmente la bande passante et permet des temps de réponse nettement plus rapides.
Prenons l’exemple des voitures autonomes.
L’hébergement des applications, ainsi que de toutes les données qui leur sont associées, dans un emplacement centralisé tel qu’un cloud public peut entraîner une latence de bout en bout de plusieurs dizaines de millisecondes. C’est beaucoup trop lent. Le résultat sera le même si l’application reste centralisée et que la fonction réseau est déplacée en périphérie. En revanche, lorsque vous déplacez l’application et la fonction réseau en périphérie, il est possible de réduire la latence à quelques millisecondes. Là, les choses deviennent intéressantes.
Les réseaux de diffusion de contenu (CDN) virtualisés en sont un autre exemple éloquent.
Jusqu’à présent, les CDN tiers étaient généralement hébergés au niveau d’un point d’échange ou dans un centre de données centralisé. La situation évolue : certains fournisseurs de services avisés créent désormais leurs propres CDN basés sur l’informatique en périphérie afin de prendre en charge les contenus vidéo locaux et les services IPTV, tout en réduisant les coûts de transit et de collecte.
Différents modèles économiques permettent de concrétiser ce type de cas d’usage.
Le scénario le plus simple est celui d’un fournisseur de services autorisant l’accès physique à un site d’edge computing. Des tiers apportent leur propre matériel et gèrent l’ensemble des opérations. Le fournisseur de services est responsable de l’espace, de l’alimentation électrique et de la connectivité : c’est ce que l’on appelle un modèle de colocation.
Une approche bien plus intéressante consiste, pour le fournisseur de services, à proposer à des tiers des offres d’infrastructure en tant que service (IaaS) ou de plateforme en tant que service (PaaS) par l’intermédiaire d’une plateforme partagée d’edge computing. Les fournisseurs de services peuvent développer eux-mêmes ces plateformes ou faire appel à des partenaires spécialisés.
La puissance de l’automatisation
L’automatisation est l’ingrédient secret qui permet à l’ensemble de fonctionner.
Dans le contexte du cloud computing, l’automatisation est essentielle pour permettre aux développeurs de publier rapidement et avec agilité de nouvelles versions du code.
Dans le monde des réseaux NFV, l’automatisation est essentielle pour réduire les coûts d’exploitation des fournisseurs de services. Auparavant, le provisionnement des réseaux et des services reposait sur des tâches manuelles et chronophages. Aujourd’hui, même si les objectifs peuvent différer, les outils et les techniques sont identiques — ou peuvent être partagés — pour les équipes réseau comme pour les équipes de développement. Les applications et les fonctions réseau coexistent dans un environnement informatique en périphérie.
Alors, comment les développeurs peuvent-ils automatiser le déploiement des applications et des services applicatifs associés dans le cloud ?
Dans le cadre de cet article, nous nous concentrons sur l’automatisation des services applicatifs. Il convient de noter que les étapes décrites ci-dessous peuvent être facilement intégrées à des outils courants de gestion de la configuration et du provisionnement, tels qu’Ansible ou Terraform, puis complétées par des outils de pipeline CI/CD tels que Jenkins.
La première étape consiste à amorcer ou à intégrer la machine virtuelle afin de déployer les services applicatifs dans le cloud choisi.
Vient ensuite l’intégration, qui consiste à mettre en place une configuration de base comprenant les paramètres réseau et d’authentification (par exemple, les adresses IP, le serveur DNS, etc.). Enfin vient le déploiement proprement dit des services applicatifs, tels que les stratégies ADC ou de sécurité, à l’aide d’interfaces de programmation d’applications (API) déclaratives.
Ce dernier point est crucial.
Les API impératives, proposées par la plupart des fournisseurs, impliquent d’indiquer au système ce qu’il doit faire à chaque étape. Les pare-feu en sont un bon exemple. Il faut créer des listes d’adresses et les associer à des règles de pare-feu. Celles-ci sont ensuite regroupées dans une politique, elle-même affectée à une interface. Les appels à l’API REST doivent respecter des étapes et des exigences précises, dans un ordre déterminé, faute de quoi tout échoue. Adapter l’ensemble à un outil d’automatisation est coûteux et chronophage.
Les API déclaratives sont d’une tout autre nature. Vous pouvez indiquer au système ce que vous souhaitez, et il détermine lui-même la marche à suivre. Une seule déclaration (au format JSON ou YAML) permet, par exemple, de définir tous les paramètres de l’ADC et des services de sécurité, puis de les transmettre au système au moyen d’un unique appel d’API REST. Dans ce cas, soit l’opération réussit (le service a été déployé), soit elle échoue, mais le système dans son ensemble reste inchangé. Le système d’automatisation n’a pas besoin d’intégrer de logique intelligente. Celle-ci reste au sein des systèmes que vous configurez, ce qui réduit considérablement les coûts d’automatisation.
Les mêmes étapes peuvent être suivies pour provisionner une fonction réseau virtuelle dans un environnement NFV. Une API déclarative simplifie considérablement l’intégration avec les outils d’orchestration NFV de bout en bout. L’orchestrateur n’a pas besoin de connaître les différentes étapes de configuration d’un service ou d’une fonction réseau : il lui suffit d’envoyer une seule déclaration JSON contenant les paramètres dont le système a besoin pour mettre en place le service. Là encore, l’intelligence permettant de déterminer « comment » configurer le service reste au sein du système que vous configurez.
Grâce à un rapprochement entre les disciplines des réseaux et du développement, nous pouvons désormais bâtir un cloud télécom distribué doté d’un cadre d’automatisation commun aux applications et aux fonctions réseau. Il est agile et sécurisé à chaque couche de la pile, du centre de données central jusqu’à l’extrême périphérie, et s’étend même au cloud public.
À l’échelle du secteur, nous nous attendons à ce que les cadres d’automatisation communs permettant le déploiement des applications et de leurs services, ainsi que des fonctions réseau, deviennent la norme dans les années à venir, notamment à mesure que le déploiement de la 5G se poursuit dans le monde entier. Les fournisseurs de services sont de plus en plus poussés à décloisonner leurs activités, à gagner en agilité et à se tourner davantage vers l’edge computing.
Vous pouvez également cliquer ici pour regarder une conférence de Bart Salaets sur l’edge computing, présentée lors du récent SDN NFV World Congress.
À propos de l’auteur
Articles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.