Les nombreux avantages offerts par les solutions de réseaux virtualisés SDN (Software-Defined Networking) et NFV (Network Function Virtualization) et leurs capacités à délivrer de la souplesse, de la flexibilité et de la vitesse au réseau ne sont plus à démontrer. Mais pour arriver à ces performances, il est essentiel de comprendre les différentes fonctionnalités des interfaces de programmation d’applications (Application Programming Interfaces), véritables portes d’accès permettant de contrôler l’exposition et l’utilisation des données numériques produites par un service.

Mais que se passe-t-il si les APIs se voient limitées à un certain nombre de services, ou possèdent une durée de fonctionnement limitée dans le temps, ou le cas échéant ne seraient pas compatibles avec certaines applications ? C’est précisément la situation dans laquelle se trouvent les fournisseurs de services actuellement.

L’écosystème des réseaux connaît de profonds bouleversements faisant écho aux évolutions technologiques et aux changements en matière de consommation. Les utilisateurs souhaitent pouvoir bénéficier d’une connectivité à tout moment et en tout lieu. Les réseaux doivent donc être calibrés afin de répondre aux exigences d’instantanéité.

Les développeurs l’ont bien compris et les applications disponibles sur le marché ont été conçues dans ce sens. Elles sont bien plus dynamiques, consommatrices de bande passante et capables de connecter plusieurs utilisateurs entre eux. Parallèlement, la technologie a elle aussi connu de profonds changements. Les solutions SDN et NFV sont à l’origine de nouvelles fonctionnalités et induisent de nouveaux business model. La White Box et l’Open Compute apparaissent comme des alternatives viables aux fournisseurs historiques de plateformes.

Avec la constante évolution des réseaux, comment déterminer les APIs qui permettent de contrôler les points d’accès au système ? Les APIs doivent-elles aussi être repensées et adaptées pour répondre à ces changements ?

Cela ne fait aucun doute, les APIs jouent un rôle décisif. S’il est impossible de créer des solutions parfaites de gestion des APIs afin de répondre à toutes les exigences des plateformes SDN et NFV, il est possible de s’approcher de la perfection en suivant les 3 conseils clés suivants.

1) Une API doit être simple

Une API doit être la plus simple possible. Le choix d’une API doit être mûrement réfléchi car elle va occuper un rôle essentiel dans l’échange d’information entre les services. Il existe des milliards d’utilisateurs de services réseaux – mobile, cloud et IoT. Pour ces utilisateurs – si ce n’est la majorité d’entre eux – la simplicité est un élément déterminant pour la compréhension et donc une meilleure utilisation des réseaux.

2) Une API doit être flexible

Si les APIs les plus simples permettent de répondre à la plus grande majorité des requêtes, la simplicité ne suffit pas toujours. Certains utilisateurs demanderont plus de contrôle sur leurs services. Par exemple, certains utilisateurs vont privilégier le contrôle plutôt qu’une plus grande élasticité, tandis que d’autres vont préférer le contrôle à la qualité des services. Les exigences étant différentes pour chaque individu, un fournisseur de service doit être capable de différencier ces besoins. En d’autres termes, un fournisseur de service doit être en mesure d’apporter des modifications et délivrer les services, les fonctionnalités et les APIs pour répondre aux besoins variés des consommateurs. En outre, l’adaptation instantanée aux besoins des clients devient primordiale pour un fournisseur de services, surtout dans cet environnement ultra-concurrentiel.

3) Plusieurs APIs sont nécessaires

Certains utilisateurs formuleront des requêtes plus sophistiquées, nécessitant des APIs plus complexes. Ces demandes proviendront des fournisseurs de services, des fournisseurs de contenu web (Internet Content Providers) et des grands groupes, dont l’exploitation de réseaux est au cœur de leur business. Ces utilisateurs recherchent des fonctionnalités avancées ainsi qu’une plus grande souplesse afin de configurer leur réseau selon leurs besoins. Ainsi, les APIs mises en place par ces utilisateurs sont plus robustes et plus riches en contenu. Les APIs « avancées » sont complètement différentes des « simples » APIs. C’est pourquoi, un fournisseur de services doit être en mesure de créer et d’incorporer de nouvelles APIs, le plus rapidement et efficacement possible, afin de répondre aux attentes des clients.

Si les nouveaux services apportent une nouvelle dynamique, un fournisseur de services optera pour une plateforme de réseau modulable afin de proposer des fonctionnalités supplémentaires aux APIs en fonction des besoins.

Par exemple, un fournisseur peut développer sa base de services APIs pour les plateformes Carrier Ethernet (CE) en intégrant un contrôle hiérarchique de la qualité de service (QoS). Si une API enrichie et modulable est nécessaire, la plateforme réseau devra supporter des APIs plus complexes, basées sur une définition des ressources du CE. Un fournisseur de services peut proposer une API modulable, qui expose toutes les caractéristiques du service CE. Ainsi, la simplicité, le changement et le développement peuvent coexister simultanément au sein du réseau.

La standardisation n’est pas prête d’arriver. Avec un peu de patience, les travaux de normalisation en cours finiront par s’appliquer à certains APIs.

Une chose est sûre :  la seule constante provient du changement. Les nouvelles applications feront émerger de nouvelles attentes en matière de services, de fonctionnalités et d’APIs. De nouvelles plateformes telle que Blue Planet émergeront pour permettre aux fournisseurs de services d’obtenir la souplesse nécessaire pour à la fois soutenir les normes en vigueur et accompagner le changement.

____________
Virginie Hollebecque est Vice-présidente, Directrice Régionale zone UK, Europe de l’Ouest et Moyen-Orient de Ciena