Intercloud Fabric, ou comment Cisco noyaute l’hybridation des Clouds

Du Cloud décloisonné mais cimenté sur une passerelle Cisco

Déjà, Intercloud Fabric ne fonctionne qu’avec les fournisseurs de Cloud qui ont bien voulu déployer chez eux le nécessaire, à savoir des routeurs Cisco capables d’interpréter ce qu’envoie InterCloud Fabric. Outre les Clouds publics américains Microsoft Azure, Amazon AWS et Google Compute Engine, Cisco a noué en France des partenariats avec Steria, Atos Canopy et la filiale française de British Telecom. A la rentrée, CloudWatt ou Numergy - on ignore lequel - devrait gonfler la liste des Clouds publics. Bien entendu, l’idée est de rallier à cette nouvelle « Alliance Intercloud », des fournisseurs locaux de Clouds privés. Il y en aurait pour l’heure une soixantaine dans le monde et ils totaliseraient 350 datacenters.

En pratique, Intercloud s’accapare un peu de puissance de calcul en local pour d’abord convertir les VM dans le format de destination avant de les expédier. « Non seulement nous pouvons passer de ESX (VMware) à Hyper-V (Microsoft), KVM (Red Hat), Xen (Citrix) ou encore VPC (Amazon), mais, en plus, nous pensons à changer à la volée les pilotes des Windows et des Linux virtuels pour qu’il n’y ait pas de dysfonctionnement », assure Bruno Dutriaux. 

Ensuite, du côté du fournisseur de Cloud, les VM sont mises en réseau sous la tutelle d’un switch virtuel Cisco CSR1000v qui reproduit là-bas la configuration réseau du datacenter d’origine. Cisco jure qu’il n’est pas nécessaire d’avoir des matériels réseau de marque Cisco en local pour que les règles de routage soient correctement reproduites. Selon Bruno Dutriaux, Intercloud Fabric saurait interroger et interpréter les configurations des constructeurs concurrents, sur la base des paquets universels LACP, 802.1Q et autres OSPF diffusés sur le réseau local. Il reconnaît cependant que le détail des règles de sécurité et de QoS est « mieux » reproduit si Intercloud Fabric peut aller récupérer un fichier de configuration sur un commutateur Cisco. A noter que, contrairement à ce qui est généralement indiqué, la présence du commutateur virtuel Cisco Nexus 1000v (téléchargeable gratuitement) ne suffit pas. Celui-ci doit impérativement disposer de l’option payante VSG (Virtual Security Gateway), laquelle coûte 40 000 dollars toute seule ou... 20 000 dollars si le réseau local repose sur des commutateurs physiques de Cisco.

« Enfin, entre ledatacenter local et le fournisseur externe, Intercloud Fabric crée un classique tunnel SSL, pour rendre l’extension du réseau local hermétique au trafic Internet, et chiffre même les VM chez le prestataire pour ne pas que celui-ci puisse les espionner », ajoute Bruno Dutriaux. Il tente ainsi de balayer les craintes en matière de sécurité, lesquelles restent le frein numéro 1 des entreprises françaises en matière de Cloud hybride.  

Proposer un maillage de Clouds pour les partenaires

Pour Cisco, l’idée sous-jacente d’Intercloud est surtout de consolider son réseau de partenaires avec toute une gamme de nouveaux services à vendre au-dessus. « Nos revendeurs de matériels pourront proposer du Cloud hybride en option avec un hébergeur de Cloud compatible Intercloud et les hébergeurs pourront proposer du Cloud hybride en revendant Intercloud ; c’est un dispositif qui prend tout son intérêt dans les plans de reprise ou de continuité d’activité dont les entreprises sont en ce moment friandes », prévoit Christophe Labro, directeur des services Cloud chez Cisco.

Il cite d’autres intérêts stratégiques du Cloud hybride : les fournisseurs de Cloud public peu chers pourront travailler avec ceux qui proposent du Cloud privé taillé sur mesure, les premiers pour permettre aux développeurs de tester à peu de frais les applications mises en production chez les seconds.

Surtout, au-delà du simple débord de VM génériques dans un Cloud IaaS externe, il s’agit de vendre des applications avec la promesse que leur charge de travail pourra se répartir là où la puissance de calcul est la moins chère ou la plus efficace. Outre les applications propres à Cisco (tout ce qui a trait au travail collaboratif, de la téléprésence aux services de communication unifiée), le fabricant annonce avoir déjà noué des accords avec une petite quarantaine d’éditeurs d’applications SaaS.

En vedette, Intercloud promet d’externaliser chez des fournisseurs de Cloud une partie de la charge de travail de SAP Hana ou d’Hadoop (Cloudera, HortonWorks, MapR font partie de l’alliance InterCloud).  « Le Big Data est une application majeure du Cloud hybride car il demande d’avoir des ressources extensibles pour traiter des flux qui arrivent de toute part », ajoute Christophe Labro. Afin d’attirer les éditeurs dans son alliance, Cisco propose un kit de développement - en clair les outils pour se connecter à l’API Intercloud - sur son site communautaire Devnet.

L’ombre des technologies propriétaires plane

Reste à savoir si cette solution pro-Cisco pourra s’imposer dans un domaine où l’on cherche avant tout des standards techniques pour se débarrasser de l’emprise des fournisseurs. Typiquement, et même si le constructeur refuse d’en parler dans le cadre du lancement d’Intercloud, le bon fonctionnement des applications au travers d’un maillage de Clouds est censé reposer sur l’utilisation d’un SDN (Software Defined Network). Or, chez Cisco, cette couche est propriétaire, elle s’appelle ACI (Application Centric Infrastructure), et elle est radicalement incompatible avec NSX que vend VMware, par exemple. Bien entendu, Cisco revendique s’appuyer sur des standards ouverts, en particulier ceux d’OpenStack. Du moins lorsque c’est possible, puisqu’OpenStack n’est pas considéré complètement fonctionnel. Mais, lorsqu’on lit les petites lignes des communiqués, on se rend compte que tous les partenaires InterCloud sont aussi des partenaires ACI.  

Annoncé il y a exactement un an, le projet Intercloud a déjà bénéficié d’un investissement de 2 milliards de dollars en R&D de la part de Cisco.