mardi, mai 26, 2009

Où est le cloud computing ?


Le 14 mai dernier certains services de Google, comme GMail, étaient
indisponibles pendant plusieurs heures (en fin d'après-midi et début
de soirée à l'heure de Paris). Twitter, quant à lui, fonctionnait à
plein régime et le curieux pouvait suivre en temps réel la progression
de la découverte de la coupure de services au fur et à mesure que les
USA se connectaient ainsi que déterminer les autres pays affectés
simplement en suivant « Google » sur Twitter. Urs Hoezle, Senior VP
Operations
à Google, s'empressait de publier un communiqué laconique
fidèle à son équanimité toute helvétique (d'origine) : à la suite
d'une erreur, laissée indéfinie, Google aurait détourné son trafic
entrant vers l'Asie, destination laissée également vaguement indéfinie
mais fleurant un exotisme suffisamment explicatif semblerait-il,
provoquant ainsi une sorte de bouchon majeur sur les autoroutes de
l'information. Ironique retour de la géographie du monde dans
l'univers virtuel que Google se propose de lui substituer !

 



Ce n'est pas la première coupure de services de Google. En
février dernier déjà, GMail avait connu quelques hoquets. En juin
2008, les utilisateurs d'Amazon avait connu une coupure générale d'une
durée de quelques heures. En 1999 et en 2002, eBay avait également
plongé ses utilisateurs dans les affres de l'incertitude sur la bonne
fin de leurs enchères. Ces événements, heureusement rares, viennent
nous rappeler que dans l'esprit du temps qui est à la virtualisation
généralisée l'ancrage réel du « *cloud computing* » reste de prime
importance.

 



Le débat actuel tourne autour de la définition du cloud computing et
du défi éventuel qu'il représenterait aux yeux des praticiens du
développement logiciel (commerciaux et Open Source, après
les prises de positions singulièrement radicales de leurs prophètes
incarnés comme rms.) Aujourd'hui déjà, nombreux sont les internautes
individuels qui ont recours à des services exécutés sur un composant
de l'architecture cloud computing (infrastructure, plateforme ou
application) : ce sont ceux-là mêmes qui furent les victimes des
coupures de services de ces dernières années — services de courrier
électronique, de gestion de photos et de vidéos, et bureautique en
ligne, etc. D'autres services cloud computing sont déjà accessibles
aux entreprises — citons Google, Amazon, Yahoo!, Salesforce,
DesktopTwo, Ultéo, Sun Secure Global Desktop, etc. Il y a également
des projets d'utilisation du cloud computing dans
l'enseignement et la formation.

 



Ce débat, pour légitime qu'il soit, occulte commodément me semble-t-il
la question plus importante suivante : où est le cloud computing ?

 



La question est est évidemment moins innocente qu'elle y paraît : elle
découle naturellement des grandes classes d'usages imaginées ou
pratiquées du cloud computing :

 




  • dans le mode Service Web, pour simplifier, le cloud héberge
    l'application du ou des utilisateurs qui y accèdent via une
    connexion à Internet.


  • dans un deuxième mode, comparable aux travaux par lots,
    l'utilisateur transfère un grand volume de données et l'application
    qui doit les traiter à un service cloud. La plateforme de cloud
    computing
    exécute ces traitements et renvoie les résultats à
    l'utilisateur. (Un exemple récent : la translitération par le New
    York Times de ses archives historiques grâce aux services combinés
    d'Amazon et de Hadoop.)


  • enfin, on voit également certaines entreprises utiliser
    temporairement des services cloud computing pour compléter leurs
    propres ressources informatiques ou bien faire face à un pic de
    trafic ou un afflux de données momentané.



Dans tous ces cas, cependant, les données et parfois les applications
mêmes de l'utilisateur résident, peut-être seulement temporairement,
dans un datacenter opéré par le fournisseur de services cloud
computing
.

 



Le premier indice que tout cela na va pas de soi, est bien dans
l'attitude contradictoire des utilisateurs individuels du cloud
computing
. Une étude du Pew Internet and American Life Project montre
en effet que malgré l'usage intensif et quotidien de tels services,
90% des internautes se défieraient de leur opérateur de cloud
computing
s'il vendait leurs données individuelles à d'autres
sociétés, 80% si elles étaient utilisées pour des campagnes de
marketing et 68% si elles étaient utilisées pour cibler des publicités
d'après leurs contenus. Or c'est exactement le business model de la
plupart de ces mêmes services, ceux que l'on pleure amèrement sur
Twitter dès qu'une coupure inopinée se produit !

 



La réponse lapidaire du technologiste, levant les yeux au ciel à la
question « où est le cloud computing », est évidemment que cela n'a
aucune importance, précisément parce que l'on s'affranchit enfin ainsi
des dernières attaches aux lourdeurs archaïques du monde réel. En
fait, c'est l'inverse : loin de représenter le zénith de la
virtualisation, le cloud computing est une (re)centralisation massive
de l'information et des ressources de calcul qui, malgré la dialectique
libératoire et New Age dont elle aime à se draper, permet un contrôle
et une surveillance — par les entreprises et les gouvernements —
d'une bien meilleure efficacité.

 



La puissance de calcul et les capacités inédites de stockage des
données du cloud computing sont le résultat des économies d'échelle
qui conduisent à la création de datacenters monumentaux. En 2008,
The Economist estimait à 7.000 le nombre de ces bunkers de l'ère
post-moderne répartis sur le territoire des Etats-Unis. Et là, la
géographie reprend ses droit, le naturel revient au galop ! Car
quelles considérations prévalent dans le choix de la localisation de
ces pyramides modernes :

 




  • suffisamment d'espace pour élever des hangars surdimensionnés — ce
    qui peut exclure certaines zones urbaines, malgré les idées
    innovantes de packaging des serveurs (Internet in a Box de Sun,
    Rackable Systems qui vient de reprendre le nom glorieux de sa
    récente acquisition, Silicon Graphics, etc.) ;


  • proximité de noeuds de connexion Internet à très haut débit ;


  • abondance de source d'énergie à bas coût pour alimenter le
    datacenter vorace et le refroidir — d'où des centres souvent au
    voisinage de centrales nucléaires ou de barrages ;


  • les lois, réglementations et le climat politique et sécuritaire de
    la région ou du pays d'implantation — point, rarement mentionné,
    mais dont on verra l'importance un peu plus loin.



Pendant la Bulle Internet, un datacenter typique consommait en moyenne
1 à 2 mégawatts. Heureuse époque ! Aujourd'hui c'est plutôt
10 fois plus et le datacenter de Microsoft près de Chicago dévore 200
mégawatts à lui seul. On estime que la consommation des 7 et quelques
milliers de datacenters aux Etats-Unis est comparable à celle d'une
ville comme Las Vegas ; à l'échelle planétaire, les datacenters auraient
consommés en 2005 environ 1% de l'électricité mondiale. On comprend
que la réglementation du prix de l'électricité et les conditions
d'accès, qui varient d'une région à l'autre du globe, puisse jouer un
rôle important.

 



Pain bénit pour les zélateurs du développement durable et les
prosélytes du Green IT, 8% à 9% de cette énergie est perdue dans le
seul transfert vers les serveurs eux-mêmes. Il y a donc largement de
quoi proposer des améliorations dans la gestion et le transport de
l'énergie et les innovations dans ce secteur seront les bienvenues.

 



La localisation vous dis-je ! Car l'autre facteur majeur du
développement du cloud computing, l'environnement réglementaire et
légal, est aussi — et pour longtemps — lié au lieu(x)
d'implantation.

 



Le législateur et les régulateurs peuvent en effet promouvoir ou, au
contraire, obérer voire interdire le développement du cloud computing
dans les secteurs sous leurs juridictions. Beaucoup de questions se
posent immédiatement, mais du point de vue des utilisateurs les
attentes d'un service cloud computing seraient :

 




  • l'accès : au gré des utilisateurs sans empêchement d'un tiers ;


  • la fiabilité : d'autant plus importante que l'opérateur du cloud
    computing
    peut, comme on l'a vu, être amené à prendre la
    responsabilité d'exécuter des traitements applicatifs et de gérer des
    données critiques des usagers ;


  • la sécurité : point n'est besoin de s'appesantir sur ce sujet,
    présent à tous les esprits par les temps qui courent ;


  • le respect de la confidentialité des données et de leur caractère
    privé : là-aussi, il y a aujourd'hui expression visible d'une
    tension entre complet laissez-faire et contrôle totalitaire avec
    des attitudes variées suivant les politiques (Patriot Act prévalent
    aux USA, « Nouvelle surveillance » en Chine et certains pays
    satellites, durcissement tout-répressif mal informé en Suède et en
    France, etc.)


  • une définition précise des risques et responsabilités des diverses
    parties contractant au service de cloud computing ;


  • le respect et la défense des droits de propriété intellectuelle et
    industrielle des utilisateurs ;


  • la propriété des données : dont les utilisateurs — en particulier
    professionnels — attendent qu'elle reste sous leur contrôle ;


  • la fongibilité des ressources : les utilisateurs, confiants dans le
    message technologique incarné par le cloud computing, s'attendent
    en conséquence à ce que leurs données puissent passer d'un
    datacenter à l'autre en fonction des besoins et des événements sans
    obstacle ni empêchement ;


  • la traçabilité et le droit d'audit : les utilisateurs,
    particulièrement les professionnels, attendent de l'opérateur
    cloud computing qu'il leur fournisse les éléments nécessaire à leur
    propre mise en conformité au droit et aux réglementations auxquels
    ils sont soumis en tant qu'usager du service ;


  • plus généralement, les considérations habituelles de droit du
    travail et de droit des entreprises, de coûts juridiques et légaux
    d'opération, d'attractivité du territoire et d'interventionnisme du
    gouvernement joueront également un rôle essentiel.



La liste est longue des lois et réglementations qui, dans chaque pays
ou région, peuvent influer sur chacun des points précédents. Aux
Etats-Unis même, l'entrelacs de l'USA Patriot Act, de HIPAA (Health
Insurance Portability and Accountability Act
), de la loi
Sarbanes-Oxley, du Stored Communications Act, des dispositions
fédérales rend déjà l'usage du cloud computing pavé de bombes à
retardement dans certains secteurs — celui de la Santé en
particulier.

 



Le maquis réglementaire américain provoque un effet de bord sensible
dans les autres pays. D'une part, les positions réglementaires et
légales des USA ont souvent valeur exemplaire — ou de repoussoir ! —
pour les autres législateurs. (En France on pousse le raffinement
jusqu'à inventer la « riposte graduée » — que le monde ne tardera
certainement pas à nous envier — et à se passer de la justice là où
RIAA et MPIAA vont encore devant les tribunaux défendre leurs
monopoles ébranlés.) Mais ces réglementations américaines peuvent,
d'autre part, être perçues comme un obstacle aux opérations d'une
entreprise étrangère : SWIFT, l'organisation bancaire internationale,
cherche à faire bâtir un datacenter sous les bienveillants auspices de
la neutralité helvétique plutôt qu'aux USA pour cette raison
précise. Il n'est que temps que le G20 se penche aussi sur les
paradis fiscaux virtuels...

 



À l'inverse peut-on faire plier un Amazon, un Yahoo!, un eBay ou un
Google lorsqu'ils hébergent des données ou offrent des services qui
tombent sous le coup d'une législation nationale différente de celle
qui s'applique dans les pays où leurs datacenters sont physiquement
implantés ? Comment juger l'attitude de ces mêmes opérateurs
lorsqu'ils se font l'instrument servile de la police en révélant les
adresses de blogueurs dissidents aux autorités de certains pays
asiatiques mais en refusant, aux Etats-Unis, de céder aux injonctions
du gouvernement au titre de la protection des droits civils ? Quelles
lois sont-elles applicables lorsque Google bâtit des datacenters dans
différents pays ? Faut-il mettre en oeuvre des incitations financières
ou des subsides pour attirer l'implantation de datacenters générateurs
de revenus et d'emplois et renforcer patriotiquement
l'attractivité de la France ? Ou alors, au contraire, faut-il taxer
les utilisateurs de services Web implantés hors du territoire, voire
les mettre en demeure (« graduellement »), sous peine de sanction —
déconnexion d'office d'Internet sans suppression de paiement de
l'abonnement ? —, de ne transmettre leurs données et applications
que sur un nuage de calcul français, ou tout au moins situé dans
l'Union européenne ?

 



Google n'a donc pas forcément versé dans la science-fiction en
déposant l'année dernière un brevet pour des datacenters flottants en
haute mer, hors des eaux territoriales — et donc des législations
nationales correspondantes — utilisant astucieusement les mouvements
de l'océan pour alimenter et refroidir ses serveurs.

 



lundi, mai 18, 2009

LLVM : les habits neufs du compilateur


Quelques bribes d'information avaient filtré durant les précédentes
éditions du WWDC (WorldWide Developers Conference) d'Apple ces
dernières années. Un nouvel acronyme, LLVM, y faisait de fréquentes
apparitions dans les présentations techniques et la communauté
bruissait des prédictions d'un avenir important dans les évolutions de
Mac OS X. LLVM, pour Low Level Virtual Machine, est à l'origine un
projet Open Source, lancé en 2000 à l'Université de l'Illinois Urbana
Champaign, par Chris Lattner. LLVM s'annonce comme une
« infrastructure pour la compilation » qui innove radicalement sur un
sujet que l'on pouvait penser complètement maîtrisé depuis des temps
immémoriaux, l'art de compiler des programmes. (À ce stade, lecture
obligatoire : Abelson, Sussman,
Structure and Interpretation of Computer Programs, et surtout le
primordial : Aho, Ullman, Principle Of Compiler Design à l'origine de
tout !)



Une fois la version 1.0 de LLVM livrée en 2003, Chris Lattner attira
l'attention d'Apple par son assiduité sur les forums de développement
Mac et l'acuité de ses questions et de ses réponses sur
Objective-C. Apple s'essaya à contribuer au projet LLVM en 2005, puis
recruta finalement Lattner pour poursuivre le projet intra muros.



En 2007, Apple livrait CLang, une implémentation de LLVM qui donnait
aux développeurs affamés un compilateur ultra-rapide et peu
consommateur de mémoire pour la famille des langages « C », un outil
de diagnostic enrichi et une architecture de bibliothèques portables,
le tout parfaitement intégré dans l'environnement de développement
XCode et sous licence Open Source BSD.



Mais l'impavide Lattner, indifférent à la menace des foudres joviennes
du démiurge de la compilation, le farouche ermite du Stata Building,
Richard M. Stallman, en venait même à ébranler la statue du Commandeur
sur son piédestal en proposant rien moins qu'un ravalement de façade
méticuleux de son trophée, Connochaetes glorieux,
le compilateur gcc. En effet, l'outil llvm-gcc substitue, horresco
referens
, l'optimisateur et le générateur de code de LLVM à celui du
vénérable outil des innombrables générations de programmeurs blanchis
sous le Makefile. Et non content de mettre à bas le mythe
alcelaphinère, llvm-gcc enrichit gcc — car prudemment compatible,
quand même — de toutes les avancées algorithmiques inventées depuis
en terme d'optimisation du code produit. Tant et si bien que l'on a du
mal à taire ce secret que tous les benchmarks oraculaires révèlent :
le code produit par llvm-gcc tournerait de 33% à 50% plus vite que
celui compilé par son ancêtre gcc...



Apple utilise également LLVM pour son stack OpenGL dans Leopard à des
fins d'optimisation sur les architectures PowerPC et x86. LLVM est
aussi employé dans les développements pour l'iPhone, mettant ainsi à
profit son architecture modulaire qui, depuis sa version 2.0, couvre
aussi d'autres processeurs comme l'ARM.



Quel est donc ce miraculeux outil sur lequel Apple même étaye ces
ambitieux développements ?



LLVM est une machine virtuelle qui, contrairement à celles auxquelles
Java puis .NET nous ont progressivement habitué, est un modèle d'une
machine de très bas niveau, un CPU, à vrai dire. Il y a longtemps que
ce niveau de détail est survolé, voire ignoré, dans le cursus actuel
du développeur « moderne ». (Ce malgré les injonctions de Jacques
Printz à renouveler l'expérience mystique en visitant avec humilité
les « cathédrales historiques » du logiciel, ces monuments souvent
oubliés aujourd'hui que sont les premiers compilateurs et systèmes
d'exploitation de naguère : Jacque Printz, Architecture logicielle. Il
ne faudra d'ailleurs envisager cette
perspective qu'avec stupeur et tremblement.)



Juste retour des choses, donc : Pourquoi donc revenir à des considérations
si primitives à l'époque contemporaine ? Parce qu'elles sont
précisément la clé des progrès attendus dans les domaines aujourd'hui
en effervescence de la programmation multicore, la programmation GPU
et le cloud computing.



En effet, l'idée de créer du code exécutable qui soit optimisé pour
des architectures aussi différentes
qu'un *quadcore* (ou bientôt 80 coeurs) d'Intel, un processeur
graphique NVidia, ou une grille mondiale de datacenters ne peut
trouver un début de réalisation sans une compréhension intime et un
banc d'essai paramétrable du fonctionnement d'un compilateur. C'est
précisément ce qu'offre LLVM, de plus avec les habits neufs de la
compilation just-in-time et de l'indépendance des langages de
programmation !



Les outils LLVM engendrent d'abord une représentation intermédiaire du
code source — quel qu'en soit le langage de programmation. C'est sur
cette représentation intermédiaire que le backend LLVM, lui aussi
entièrement paramétrable et extensible, va optimiser la génération de
code natif en fonction de l'architecture matérielle cible. Une des
innovations majeures de LLVM réside dans la définition d'API
rigoureuses pour chacune de ces étapes de traitement, tant celles de
la traduction dans la représentation intermédiaire que celles
d'optimisations et de génération de code natif qui les
suivent. Ainsi, un développeur peut expérimenter simplement de
nouvelles idées pour l'optimisation ou la génération de code : il lui
suffit d'insérer, via ces API, le traitement supplémentaire dans
l'outil LLVM lui-même. En parfait contraste avec la boîte noire que
gcc représente souvent pour les développeurs — parfois même la bête
noire
! — LLVM est une boîte transparente dont le mécanisme est non
seulement visible mais encore accessible et modifiable le cas
échéant. (J'entends d'ici certains évoquer OIL-CCG, Optimized
Intermediate Language
et Common Code Generator, précurseurs
avant-gardistes en 1976-77 pour PL/1 et Cobol...)



Qu'Apple cherche à acquérir une maîtrise la plus complète possible de
la génération et de l'optimisation de code natif n'est pas forcément
surprenant à la lumière, par exemple, de son acquisition l'an passé de
PA Semiconductor qui lui fournira des SoC spécialisés pour les
mobiles. Ainsi Apple contrôlerait toute la chaîne, du silicium
jusqu'au firmware et au code applicatif : un avantage concurrentiel
important sur les marchés fragmentés de l'embarqué.



Enfin, depuis sa création, la la liste des projets LLVM s'est notablement
allongée : API pour Python, Lua et Objective CaML, liens avec OpenJDK,
emploi pour la virtualisation (llvm-qemu), noyaux de traitement
d'images par Adobe (Hydra/Pixelbender), etc. LLVM pourrait également
jouer un rôle prépondérant dans le
développement et la généralisation de Linux aux appareils mobiles ou
embarqués. (Par exemple en compilant et optimisant au vol des
librairies Linux distribuées sous forme de représentation
intermédiaire en fonction du/des CPU/GPU disponibles.) Quant au cloud
computing
, LLVM offre la perspective d'un déploiement de code sur des
plates-formes hétérogènes en compilant just-in-time sur chaque machine
des datacenters le fragment optimisé de traitement dont elle est
chargée par un algorithme d'allocation comme Hadoop.



ShareThis