Réflexions autour du Software Defined Network
‘Depuis quelques mois on assiste à une frénésie autour du SDN.
De nombreuses start-up sont apparues avec l’espoir d’un rachat à court et moyens termes par un des grands du marché.
Ce serait réducteur de limiter ce phénomène à un buzz médiatique puisque l’on commence à voir des mises en œuvre apparemment réussies et que chaque constructeur, Cisco y compris, bâtissent des stratégies autour de SDN.
Mais aujourd’hui le SDN est-il la panacée universelle ?
Au-delà du débat technologique je pense qu’il serait bon de revenir sur les besoins et cas d’usages associés
Tout le monde s’accorde sur le besoin de simplification et de programmabilité mais ce besoin peut s’exprimer différemment selon les sociétés, leurs métiers et leur organisation.
Pour analyser ces besoins et cas d’usage j’ai pris conseil aupres de Christophe 
Compain architecte DataCenter.
On peut déterminer 5 grands cas d’usage pour la programmabilité avec des réponses différentes:
La recherche et l’université : partager un réseau dans un campus
C’est de là que vient Openflow : le milieu de la recherche sur un campus universitaire. Comment arriver à ‘découper’ un réseau pour permettre à chacun de concevoir et ‘tester’ ces nouveaux protocoles sans avoir nécessairement de moyen de développement ‘hardware’ ?
Les énormes datacenters massivement scalables : gestion de flux de réseau et APIs programmables
On est là face aux énormes datacenters des societes internet telles que Google, Facebook etc…Le gigantisme de ces environnements nécessite du développement ‘customisé’ de l’ensemble de la chaîne de valeur : car le métier est l’IT avant tout. De facto, la manipulation des objets réseaux au travers une API programmable devient un pré requis pour une bonne agilité et une efficacité opérationnelle concurentielle.
Les Opérateurs de Cloud : évolutivité et multitenancy
Un opérateur de type ‘public cloud’ doit capter le maximum de clients pour
maximiser ses revenus sur des services simples (cf. Amazon EC2 ou S3). Chaque
client doit avoir la garantie d’une part d’obtenir son environnement rapidement
et d’autre part qu’il ne sera jamais gêner par ses voisins. Les overlay réseaux
‘programmables’ résolvent une partie de la problématique car ils assurent ce
niveau de segmentatin (cf. VXLAN). La seconde partie de l’équation est elle
résolue par des mécanismes d’orchestration et d’automatisation. ( lire le post sur VXLAN)
Les services providers : Agilité dans la fourniture de service
Ici le besoin est de facturer un service en fonction de l’effort d’engineering. C’est ce qu’on appelle le traffic engineering. On recherche à fournir des services agiles le plus simplement possible. On est là devant un besoin de « delivery » avant tout. On doit pouvoir analyser et contrôler selon des règles pour optimiser et monétiser la fourniture de services.
A noter qu’un groupe d’opérateurs telecom on récemment créer le Network Functions Virtualization (NFV) group qui entend aller avec SDN au-delà du simple protocole openFlow (« Recognition that SDN needs to be more than openflow and that openflow cannot solve many of the software networking problems operators will face with NFV”). Lire le white paper
Les entreprises : avant tout l’automatisation, le cloud privé et l’ouverture vers l’hybride
La programmabilité s’exprime surtout ici avec l’orchestration des
ressources : comment coordonner intelligemment le processus de mise à
disposition d’infrastructure en entreprise .
En conclusion
La pluralité des besoins est une réalité et la tendance est surtout aux capacités d’orchestration et de provisionning dans la majorité des cas. Certains aspects plus orientés ‘programmation’ sont essentiellement liés à une dépendance vis-à-vis du métier nécessitant une customisation poussée. Au final, SDN n’est pas la solution à l’ensemble des cas d’usage mais plutôt une des technologies (ou façon de programmer le réseau) qui pourrait permettre dans un avenir à moyen terme de répondre à certains de ces besoins.
Tags:
