Comme le cloud, le SDN souffre d'une fatigue de définition

Au début de l’histoire du cloud, il n’y a pas si longtemps, il était courant de voir des rapports de croissance et d’adoption vantant la pénétration inégalée du marché du « cloud » sans distinction entre ses principaux modèles (à savoir IaaS, PaaS et SaaS au cas où vous l’auriez oublié). Cela donnait l’impression que les trois modèles connaissaient une croissance incroyable et que le cloud allait, comme certains l’avaient prédit, éradiquer le centre de données tel que nous le connaissions.

Quelques années plus tard, nous avons vu de meilleures répartitions du marché qui indiquent que l’essor fulgurant du cloud s’est principalement produit du côté SaaS, car les parties prenantes du secteur d’activité ont vu les avantages de passer d’un modèle informatique qui implémente des logiciels packagés pour nous à un modèle SaaS qui nous donne ce que nous voulons aujourd’hui. À ce jour, la plus grande croissance du « cloud » a sans conteste été le déplacement des opérations commerciales des locaux vers des applications « dans le cloud ».

Considérez que « d’ici 2018, 59 % des charges de travail totales du cloud seront des charges de travail de type Software-as-a-Service (SaaS), contre 41 % en 2013. Cisco prévoit que d'ici 2018, 28 % des charges de travail cloud totales seront des charges de travail d'infrastructure en tant que service (IaaS), contre 44 % en 2013. 13 % des charges de travail cloud totales seront des charges de travail de plate-forme en tant que service (PaaS) en 2018, contre 15 % en 2013.  Le graphique suivant fournit une analyse comparative des prévisions IaaS, PaaS et SaaS de 2013 à 2018. » ( http://softwarestrategiesblog.com/tag/idc-saas-forecasts/ )

Ainsi, lorsque vous demandez généralement à une organisation si elle adopte le « cloud », vous obtiendrez probablement un oui. Cela ne vous dit rien sur le type de cloud qu’ils adoptent et, par conséquent, rend presque impossible de prédire ou de commenter le type de défis auxquels ils pourraient être confrontés en fonction de l’adoption. Après tout, chaque modèle de cloud apporte ses propres défis, et si certains sont communs (la gestion des identités peut être un problème pour les trois modèles), d’autres ne le sont pas (la sécurité des applications Web est principalement un défi pour les applications déployées en IaaS, et non en SaaS).

Donc, fondamentalement, le terme « cloud » n’a pas vraiment de sens sans un qualificatif.

C’est également vrai aujourd’hui pour le SDN, où une variété de modèles sont en jeu, chacun avec ses propres exigences architecturales et, par conséquent, ses propres défis.

Considérez cette diatribe de mon collègue, Nathan Pearce, sur l’inclusion des protocoles de superposition (VXLAN et NVGRE) dans la définition du SDN : Quel protocole SDN vous convient le mieux ? Nathan suggère à juste titre que si nous devons inclure les protocoles de superposition dans la définition du SDN, nous devons également nommer d'autres protocoles d'encapsulation comme étant du SDN.

Le problème est, bien sûr, que, comme le cloud, le SDN souffre de sa large inclusion de multiples modèles. Il existe la définition traditionnelle (ou classique, si vous préférez), basée sur OpenFlow et incluant uniquement le réseau sans état (couches 2 à 4). Il existe le modèle architectural qui se concentre sur l’opérationnalisation du réseau ; en abordant l’aspect programmabilité du SDN du point de vue de l’automatisation du provisionnement et de la gestion. On parle souvent de « gestion et orchestration de réseau » (MANO)

Ensuite, il y a le modèle qui est une sorte de mélange, qui s'appuie sur la programmabilité afin de construire un réseau automatisé sur l'ensemble de la pile ; il inclut les sept couches OSI mais se concentre sur la capacité du réseau à ajuster son routage et l'application des politiques en fonction du trafic en temps réel.  On parle plus justement de « réseaux automatisés ».

Chacun de ces trois modèles apporte avec lui ses propres défis (et avantages également). Et rien n’empêche une organisation de combiner ces modèles pour atteindre ses objectifs (de la même manière que 82 % des organisations envisagent une stratégie multi-cloud (RightScale, State of the Cloud 2015)). Mais le fait demeure que si vous demandez à quelqu’un s’il adopte ou met en œuvre SDN et qu’il répond « oui », vous n’avez vraiment aucune idée de ce qu’il fait réellement. Est-ce OpenFlow ? OpenStack ? OpenDaylight ? Ouvert-nous-avons-écrit-des-scripts-pour-automatiser-le-réseau ?

Les statistiques actuelles sur l’adoption du SDN ne sont pas très inspirantes et sont certainement loin de là où se trouvait le cloud au même stade de maturité du marché.

Mais étant donné la disparité des définitions, il est tout à fait plausible (et probable) que ce qui se passe en réalité ne soit pas un manque d’adoption ou d’intérêt, mais plutôt un manque de définition commune.

Je vais étayer cela avec certaines données qui indiquent que les organisations ne disent peut-être pas qu’elles utilisent SDN (ou DevOps, d’ailleurs, qui souffre également d’une fatigue des définitions), mais elles le font probablement.

Dans les résultats compilés pour notre rapport le plus récent sur l’état de la distribution des applications (2016, qui sera disponible en 2016), le nombre de réponses « faisant appel au SDN » était assez faible compte tenu du nombre d’années pendant lesquelles le SDN est « la chose à faire ». Mais en examinant de plus près les réponses concernant l’utilisation de l’automatisation et des scripts, on découvre une histoire complètement différente : 67 % des répondants utilisent au moins un outil ou un framework d’automatisation ; plus de la moitié en utilisent 2 ou plus.

Et par « outil » ou « framework », j’inclus Python, Juju, Chef, Puppet, OpenStack, VMware et Cisco.

L’utilisation de tels cadres et outils indique un intérêt plus important pour les deux dernières définitions du SDN – celles axées sur l’automatisation et l’orchestration, plutôt que la définition classique basée sur OpenFlow.

Mais nous (ceux d’entre nous qui ont réalisé l’enquête) n’avons pas posé de questions sur chacun des modèles SDN ; nous avons posé des questions sur le « SDN » en général. Ce qui laisse la définition ouverte à l’interprétation, tout comme le terme générique de « cloud » a laissé le résultat des premières enquêtes d’adoption ouvert à l’interprétation.

Nous devons être plus judicieux dans la manière dont nous utilisons le terme SDN et ce que cela signifie. Est-ce que cela inclut des protocoles de superposition ? Cela n'inclut-il pas les protocoles de superposition ? Parle-t-on d’automatisation de réseau ou d’automatisation de réseaux ? Ou bien nous concentrons-nous sur des modèles de réseau classiques basés sur OpenFlow ?

La réponse à cette question permettra à chacun de mieux comprendre comment le SDN est (ou n’est pas) adopté aujourd’hui et empêchera (espérons-le) la tête de mes pauvres collègues d’exploser lorsque quelqu’un suggérera que les protocoles de superposition devraient être inclus dans le « SDN ».