Depuis le boom de la virtualisation, base du Cloud computing, le mouvement s’accélère dans les réseaux. Après le Software Defined Networking arrivent toutes les autres déclinaisons : Software Defined Datacenter, Software Defined Servers, Software Defined Storage… effet de mode ou vraie évolution ? Quels sont les moteurs de ce mouvement ?
SDx : tour d’horizon des déclinaisons du « Software Defined »
Le Software Defined Networking est le premier acronyme du lot à avoir fait parler de lui. Il introduit un pilotage du réseau par une intelligence centralisée (le contrôleur), le traitement restant étant effectué par les équipements réseaux (qu’ils soient matériels ou logiciels).
Dans la lignée, le Software Defined Storage, ajoute une couche de virtualisation au-dessus du stockage. De la virtualisation existe déjà dans cet univers au sein des baies mais le concept est ici étendu pour couvrir le stockage dans son ensemble. Les VSA (Virtual Storage Appliances) en sont un exemple.
Le terme Software Defined Servers, quant à lui, fait aujourd’hui l’objet d’un débat… On devrait pouvoir ranger dans cette catégorie tous les hyperviseurs du marché. Le concept a cependant évolué et est sans doute un peu à rapprocher du concept de SDN maintenant : l’idée est de piloter des ressources matérielles depuis une intelligence centralisée pour instancier des serveurs et gérer leurs ressources.
Enfin, le Software Defined Datacenter agrège les différentes techniques de virtualisation pour fournir un service complet de type ITaaS
Toutes ces déclinaisons ont un point commun : retirer de l’intelligence du matériel pour la porter sur du logiciel, supporté en général par du matériel courant (commodity hardware) type serveur x86… l’évolution technologique fait surtout (re)surgir des rivalités entre acteurs. La bataille entre les vendeurs de matériel et éditeurs de logiciels est plus âpre que jamais, chacun voulant soit protéger ses parts de marché actuelles, soit s’imposer sur ce nouveau marché qui explose…
Nouveau débat ou opposition récurrente ?
La rivalité entre les codeurs et les fondeurs de semi-conducteurs ne date pas d’hier, et n’est pas près de s’éteindre, et en fait on observe un balancier rythmé par les évolutions technologiques, que ce soit dans les logiciels et les CPU ou bien dans les matériels spécialisés, et notamment dans les réseaux.
Des affrontements ont donc régulièrement lieu entre défenseurs du matériel, principalement pour des raisons de performance, et défenseurs du logiciel, pour la souplesse. Ce type de débat a existé également pour les processeurs où s’opposent CPU et ASIC (Application Specific Integrated Circuit), le circuit intégré polyvalent mais lent face au circuit intégré spécialisé et très rapide car « câblé » pour faire en une seule opération ce que le CPU fera en de multiples opérations.
Dans le domaine des infrastructures réseaux et sécurité on pourrait également faire référence aux affrontements historiques sur les routeurs (Cisco contre Extreme Networks ou Juniper) ou les pare-feu (Checkpoint contre Netscreen, racheté par Juniper depuis).
Toujours un même driver : vers plus d’intelligence et de souplesse…
La forte augmentation de la puissance des CPU x86 ces derniers temps les a amenés à embarquer un certain nombre de produits auparavant uniquement sous la forme de matériels vers une forme logicielle dans des hyperviseurs. Cette abstraction permet non seulement de ne plus être retreint par les possibilités du matériel, et donc d’apporter plus d’intelligence aisément, mais aussi un fort gain de souplesse : l’ajout de composants virtuels ne requérant aucune installation physique ni câblage.
Au-delà des serveurs c’est également le cas des pare-feu ou des équilibreurs de charge : F5, Radware et Citrix par exemple fournissent tous des versions en mode « virtual appliance ».
…mais pas au détriment des performances !
Ce qui est vrai dans les domaines ayant des traitements complexes ne l’est pas forcément dans des domaines nécessitant de très fortes performances brutes, comme les réseaux. Même les processeurs les plus récents ont du mal à suivre les débits du 10Gbs et encore plus du 40Gbps et du 100Gbps
Le logiciel a un gros avantage : la souplesse. Il est en effet bien plus simple de modifier quelques lignes de codes qu’ajouter des connexions cuivre et des transistors dans un ASIC. Néanmoins ce qu’un CPU fait en 20 ou 50 cycles d’horloge un composant spécialisé peut le faire en 1 ! C’est ici qu’interviennent les FPGA (Field Programmable Gate Array) : ces ASICs reprogrammables donnent une petite marge de manœuvre pour faire évoluer les fonctionnalités offertes par le matériel et tous les matériels modernes les intègrent afin d’arriver à réconcilier performances et souplesse.
Au-delà du cycle, une tendance se dégage donc : la solution doit pouvoir évoluer avec les besoins, qu’elle soit logicielle ou matérielle, et les équipements matériels non reprogrammables seront cantonnés à des utilisations spécifiques
Vers le « Software Defined Everything » oui, mais ne pas confondre « Software Defined » et « Software Only » !
Les solutions tout logiciel ne tiendront pas les performances nécessaires et à l’inverse les solutions tout matériel ne tiendront pas les promesses de souplesse demandées par les SI de demain.
Dans la réalité un compromis entre logiciel et matériel est évidemment obligatoire : du logiciel pour la souplesse et du matériel pour les performances… et c’est typiquement toute la logique derrière le Software Defined Networking, qui laisse au logiciel le soin de piloter du matériel à hautes performances.