Fournisseurs de services à la pointe de la technologie : Cadres d’automatisation courants et fin des compromis en matière de vitesse et de sécurité

Dans un passé pas si lointain, le secteur des fournisseurs de services était caractérisé par une ligne de démarcation bien définie.

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 l’accent sur la virtualisation des fonctions réseau et sécurité. Les incursions dans le monde de l’automatisation étaient pour le moins hésitantes.

De l’autre côté, les développeurs ont adopté avec enthousiasme les plateformes cloud, les méthodologies DevOps et l’automatisation via les pipelines CI/CD. Le déploiement et la livraison rapides des applications étaient, et sont toujours, la règle du jeu.

La périphérie est l'endroit où les deux se rejoignent et où les applications peuvent cohabiter harmonieusement avec les fonctions réseau.

Grâce à sa nature distribuée et alimentée par le déploiement mondial progressif de la 5G , l'informatique de pointe commence enfin à permettre aux fournisseurs de services de proposer de nouvelles solutions et de nouveaux services qui augmentent simultanément les flux de revenus et réduisent les coûts de transport du réseau.

Plutôt que de transmettre les données au cloud ou à un entrepôt de données central pour analyse, le traitement peut avoir lieu à la « périphérie » d’un réseau, réduisant ainsi la latence du réseau, augmentant la bande passante et offrant des temps de réponse considérablement plus rapides.

Prenons l’exemple des voitures autonomes.

L'hébergement d'applications, avec toutes leurs données associées, dans un emplacement centralisé comme un cloud public peut générer une latence de bout en bout de l'ordre de plusieurs dizaines de millisecondes. C'est beaucoup trop lent. Vous obtiendrez le même résultat si l’application reste centrale et la fonction réseau est déplacée vers la périphérie. Cependant, lorsque vous déplacez l'application et la fonction réseau vers la périphérie, il est possible de réduire la latence à quelques millisecondes. Maintenant, nous sommes en affaires.

Les réseaux de diffusion de contenu virtualisés (CDN) sont un autre exemple convaincant.

Jusqu’à présent, un CDN tiers avait tendance à être hébergé sur un point de peering ou dans un centre de données centralisé. Cela est en train de changer, certains fournisseurs de services astucieux construisant leurs propres CDN basés sur l'informatique de pointe pour couvrir le contenu vidéo local et les services IPTV, tout en économisant sur les coûts de transit et de retour.

Il existe différents modèles commerciaux disponibles pour donner vie à ce type de cas d’utilisation.

Le scénario le plus simple est celui d’un fournisseur de services autorisant l’accès physique à un site de calcul de périphérie. Les tiers apportent leur propre matériel et gèrent tout. Le fournisseur de services est responsable de l’espace, de l’électricité et de la connectivité, également connu sous le nom de modèle de colocation.

Une approche beaucoup plus intéressante consiste pour le fournisseur de services à proposer des options d’infrastructure en tant que service (IaaS) ou de plateforme en tant que service (PaaS) à des tiers via une plateforme de calcul Edge partagée. Les prestataires de services peuvent les construire eux-mêmes ou avec l’aide de partenaires spécialisés.

La puissance de l'automatisation

L’automatisation est l’ingrédient secret pour que tout fonctionne.

Dans le contexte du cloud computing, l’automatisation est essentielle pour que les développeurs puissent publier de nouvelles versions de code à un rythme soutenu et avec agilité.

Dans le monde du réseau NFV, l’automatisation est essentielle pour réduire les coûts opérationnels d’un fournisseur de services. Auparavant, la mise en place de réseaux et de services était une tâche manuelle qui prenait du temps. Aujourd’hui, même si les objectifs peuvent différer, les outils et les techniques sont les mêmes (ou partageables) pour les équipes réseau et les équipes de développeurs. Les applications et les fonctions réseau coexistent dans un environnement de calcul de pointe.

Alors, comment les développeurs peuvent-ils automatiser le déploiement d’applications et de 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 dans des outils de gestion de configuration et de provisionnement populaires tels qu'Ansible ou Terraform, qui sont ensuite complétés par des outils de pipeline CI/CD tels que Jenkins.

La première étape consiste à amorcer ou à introduire la machine virtuelle pour fournir des services d’application dans le cloud de votre choix.

L’étape suivante est l’intégration, qui implique l’introduction d’une configuration de base avec des paramètres de mise en réseau et d’authentification (par exemple, adresses IP, serveur DNS, etc.). Enfin, il y a le déploiement réel des services d’application, tels que les ADC ou les politiques de sécurité, à l’aide d’interfaces de programmation d’application déclaratives (API).

Le dernier point est crucial.

Les API impératives, dont disposent la plupart des fournisseurs, vous permettent d'indiquer au système ce qu'il doit faire à chaque étape. Les pare-feu en sont un bon exemple. Vous devrez créer des listes d’adresses et les aligner sur les règles du pare-feu. Ceux-ci sont ensuite regroupés dans une politique, qui est ensuite attribuée à une interface. Il existe des étapes et des exigences distinctes pour que les appels d'API REST se déroulent en séquence, sinon tout échoue. Contorsionner tout cela dans un outil d’automatisation est coûteux et prend du temps.

Les API déclaratives sont une bête différente. Vous pouvez dire au système ce que vous voulez, et il détermine la voie à suivre. Avec une seule déclaration (au format JSON ou YAML), vous pouvez, par exemple, définir tous les paramètres ADC et du service de sécurité et les transmettre au système avec un seul appel d'API REST. Dans ce cas, le résultat est soit un succès (le service a été déployé), soit un échec, mais le système global reste inchangé. Il n’y a aucune exigence d’intelligence dans le système d’automatisation. L'intelligence reste dans les 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 de réseau virtuel 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 étapes individuelles pour configurer un service ou une fonction réseau, il envoie simplement une seule déclaration JSON avec les paramètres dont le système a besoin pour configurer le service. Encore une fois, les informations sur « comment » configurer le service restent au sein du système que vous configurez.

Grâce à une harmonisation plus étroite entre les disciplines de mise en réseau et de développement, nous pouvons désormais créer un cloud de télécommunications distribué avec un cadre d'automatisation commun pour les applications et les fonctions réseau. Il est agile et sécurisé à chaque couche de la pile, du centre de données central jusqu'à la périphérie, en passant même par le cloud public.

À l’échelle de l’industrie, nous nous attendons à ce que les cadres d’automatisation communs qui permettent le déploiement d’applications et de leurs services, ainsi que des fonctions réseau, deviennent la norme dans les années à venir, en particulier à mesure que le déploiement de la 5G se poursuit dans le monde entier. La pression s’accroît sur les prestataires de services pour qu’ils unifient les silos, deviennent agiles et commencent à vivre davantage en marge.

Vous pouvez également cliquer ici pour regarder le discours de Bart Salaets sur l'edge computing lors du récent congrès mondial SDN NFV.