Dans une annonce relayée par Channelnews, Cisco prétend être en mesure de déplacer des workloads. Une affirmation mise en doute par Jean-Marc Defaut, directeur Cloud de HP France, dont nous publions une adaptation du blog.

 

Je suis récemment tombé sur un article de Channelnews faisant la part belle à l’annonce de Cisco relative à son offre InterCloud. Selon le journaliste, il est question de pouvoir déplacer les charges de travail (workloads) – données et applications – entre différents Clouds publics interopérables.

Une promesse encore largement exagérée à mon avis. Arrêtons-nous quelques instants sur la nature de cet engagement afin d’essayer de comprendre de quoi il retourne vraiment. En premier lieu il s’agit de définir le terme workload. Je trouve la définition ci-dessous plutôt pertinente :

En informatique, la charge de travail est la quantité de traitement que l’ordinateur doit produire à un moment donné. La charge de travail est composé d’une certaine quantité de code applicatif s’exécutant sur l’ordinateur et généralement un certain nombre d’utilisateurs connectés et interagissant avec les applications de l’ordinateur. Pour faire simple, on parle d’un code applicatif en interaction avec des utilisateurs.

Maintenant, que veut dire déplacer une charge de travail ?  Il s’agit de prendre […] une application et ses dépendances ainsi que la charge de travail associée s’exécutant à un endroit A, pour la faire voyager à travers un réseau vers un endroit B. N’oublions pas le jeu de données qu’il faut déplacer avec le code qui le contextualise.

Est-ce faisable ? […] L’accès à des API Cloud classiques est-elle suffisante ? Suis-je en mesure de déplacer une charge de travail si j’ai capacité à créer, à la volée, l’infrastructure nécessaire pour la supporter ? La grammaire OpenStack ou les API d’accès à Azure ou Amazon sont-elles suffisantes ?

La réponse à toutes ces questions est (malheureusement) non. Tous ceux qui ont fait de la mise en production savent pertinemment que la magie du copier/coller n’existe pas dans le monde de l’application. On ne peut pas créer une machine virtuelle comme un répertoire (dans le Cloud distant), copier l’application comme un .exe et la déposer à l’intérieur pour la relancer.

On nage en plein fantasme. Bien sûr, c’est très intéressant de pouvoir créer des environnements à la volée mais c’est loin d’être suffisant pour déplacer une application d’entreprise.

Pour mieux comprendre je vous renvoie aux travaux de l’OASIS sur le modèle TOSCA (OASIS Topology and Orchestration Specification for Cloud Applications ou spécification de topologie et d’orchestration OASIS pour les applications Cloud), qui se présente comme le premier standard à normaliser les services informatiques reposant sur des infrastructures sous forme de services.

Selon ce modèle, le déplacement d’une application suppose de décrire la topologie et la séquence d’instanciation de chacun de ses composants (bases de données, frontaux Web, systèmes d’exploitation, etc.). Le déplacement d’une charge de travail implique donc, dans les faits, de déplacer l’application en elle-même (le code) avec toutes ses contingences : jeux de données, adresses réseau, outils de gestion des serveurs (supervision, sauvegarde)…

En pratique, OpenStack permet de créer […] une machine virtuelle et du stockage dans un contexte réseau. Azure permet sous conditions et de façon limitée, de créer une instance de base de données. AWS permet à grosse maille, la même chose qu’OpenStack. Mais les API du marché permettent difficilement d’aller au-delà des serveurs d’application ou des bases de données.

Avec le déplacement des jeux de données (qui peuvent être colossaux) se pose le problème de la taille et du coût des tuyaux. On peut toujours transférer des données d’un endroit à un autre au cas par cas. Mais il n’existe pas d’application qui gère le processus de bout en bout.

Ne vous y trompez pas, j’adore l’idée du déplacement des charges de travail. Je suis même convaincu que nous y arriverons à moyen terme. Mais aujourd’hui, nous n’y sommes pas encore. Nous devons nous contenter d’utiliser des applications conçues pour fonctionner dans un seul serveur ou codées pour fonctionner de manière géographiquement distribuées.

L’annonce de Cisco ne relève donc pas du transfert de Workloads mais de l’ouverture, à l’instar de ce que HP ou VMware font déjà, d’une fonctionnalité de débordement permettant de dupliquer des machines virtuelles dans le Cloud public depuis son Cloud privé.

Cette tribune est une adaptation d’un post paru sur le blog Cloud Experience le 20 février.