Quand Robert Metcalfe a inventé Ethernet, il a dit que « le réseau est la communication inter processus. » Je n’ai jamais rencontré Robert Metcalfe mais je pense sans pouvoir l’affirmer qu’il ne croyait pas alors devoir attendre 40 ans pour que son idée arrive sur le devant de la scène. Même si, en 1986, John Gage déclarait que « le réseau est l’ordinateur » dans l’objectif de faire avancer le débat, c’est comme si c’était tombé dans l’oreille d’un sourd. Alea jacta est, et chacun construisit des réseaux sans se préoccuper du reste. Internet et les réseaux sont ainsi nés, de manière « mécanique » pour citer un de mes amis. Vous connectez votre serveur, vous obtenez une adresse IP et vous êtes relié au monde ; tout cela grossit, on construit de nouveaux data centres plus gros mais sans réelle évolution.

TCP/IP et son cousin MPLS sont arrivés et ont défini toute une classe de réseau simple mais sécurisé pour quasiment l’ensemble des entreprises du monde ou pour les personnes voulant un plus haut degré de contrôle sur leurs « communications inter processus ».

Il en est ainsi aujourd’hui. Même si des pionniers comme John Day et sa Recursive InterNetwork Architecture (RINA) ont repris le thème à leur charge en complétant la phrase de Robert Metcalfe par « … et uniquement une Communication Inter Processus » ou IPC.

SDN et NFV ont rouvert le débat mais trop vaguement, oubliant qu’on n’achète pas du réseau de manière isolée. C’est l’arrivée du Cloud computing qui a révélé que l’informatique pouvait réellement – pas uniquement en partie mais totalement – être optimisée grâce au réseau.

Qu’en est-il de cette notion : « inter processus » ? Tout fonctionne si les processus sont dans le même bâtiment, c’est-à-dire le même data centre, mais qu’en est-il s’ils sont éloignés géographiquement pour des raisons de souplesse ou parce qu’il est moins cher de créer de l’élasticité sur un réseau que physiquement (Internet le prouve). Pour vraiment faire du Cloud computing une solution universelle, nous devons reprendre les thèmes des pionniers : réintégrer la « communication inter processus ».

A première vue, ce n’est pas si compliqué. Mettre l’informatique dans le réseau. Littéralement, ça revient à mettre l’intelligence informatique et les ressources de stockage au cœur du réseau MPLS, calibré selon la taille nécessaire. Distribuer les ressources de stockage et l’informatique selon les besoins de chacun (avec le réseau), en éliminant la notion de « quelque part dans le nuage » qui gênait dans la version 1.0 du Cloud, en boostant la performance, l’efficacité, l’élasticité et en préservant la souveraineté des données, en ce qui nous concerne.

L’idée n’est pas nouvelle pour bon nombre de personnes mais pour que la solution soit universelle, il faut conserver tous les avantages de la version 1.0 du Cloud computing. Il n’y a rien de génial à faire compliqué, ça dénote justement un manque d’ingéniosité. Pour avancer, nous devons virtualiser le réseau et créer une API pour que l’informatique puisse utiliser et requêter le réseau sur des IP publiques et privées. L’astuce est de se servir de MPLS et VRF pour définir le domaine des ressources ou des « virtual data centres ». Chaque VLAN peut être associé à un ou plus de vos VRFs, ce qui crée automatiquement l’étalon d’or des architectures TIC d’entreprise sans les coûts, les problèmes ni les délais. Vous obtenez une informatique en réseau sur une importante ossature MPLS qui permet à votre propre infrastructure d’avoir une couverture mondiale, via l’internet des fournisseurs d’accès, dans chaque ville. Là, vous avez tous les bénéfices : la dimension, la flexibilité et la sécurité, avec le meilleur de la version 1.0 du Cloud computing.

Vous pouvez ainsi créer des temps de réponse tels qu’on les connaît avec les aller-retour en informatique ou une latence aller-retour en milliseconde, à un seul chiffre. Etant donné que nous ne pouvons pas faire la différence sur l’équipement, tous approvisionnés chez un petit nombre de fournisseurs, la différence entre opérateurs se fera sur la combinaison du processeur silicium avec la « Communication inter processus ».

La rapidité c’est bien, mais que fait-on quand on est l’Agence spatiale européenne et qu’on ne peut pas tolérer une milliseconde de retard ? Nous avons tous besoin que ça aille vite. Le principal bénéfice d’une communication inter processus rapide et prédictible pour chacun est un débit plus élevé et donc plus de requêtes auxquelles vous pouvez répondre. Evidemment : plus c’est rapide, plus on peut faire de requêtes, et moins il faut de serveurs.

Sans doute peut-on obtenir les mêmes résultats avec un Cloud 1.0 mais ce sera plus lent et on n’atteindra jamais la densité d’une version ancrée dans le réseau. Et surtout, le coût sera supérieur. Comme toujours, les nouvelles versions sont plus rapides, moins chères et plus performantes.

Maintenant, tout le monde s’accorde pour dire que c’est bien mais l’idée persiste que ce serait compliqué. Pas du tout ! En 5 minutes vous pouvez être l’heureux propriétaire d’un backbone internet mondial et d’un data centre distribué doté d’une immense puissance de calcul et de stockage et que vous contrôlez. Ah, j’oubliais : en plus, vous ne payez pas le réseau… le transfert de données est gratuit.

Assez parlé. Le temps pris pour lire cet article aurait pu être mis à profit pour essayer.

Par Jean-Pierre Tournemaine, Directeur Général d’Interoute pour la France