IBM qui n'a évidemment pas l'intention de laisser à d'autres, même prétendus pionniers, le monopole de l'idée du « cloud computing », vient d'annoncer haut et fort, juste avant les Jeux Olympiques, son intention d'investir $360m dans un datacenter neuf et rutilant en Caroline du Nord destiné à compléter le réseau qu'il met énergiquement en place.
Google Maps m'indique bien volontiers qu'en suivant
(La polémique avait à l'époque tourné autour des avantages fiscaux promis à Google par le comté de Caldwell pour favoriser son installation à proximité de la centrale hydro-électrique de Rhodiss — on le sait, ces bunkers informatiques ont un besoin dévorant d'eau et d'énergie. Il y a là une idée à creuser pour les centres anémiés de la recherche française dont on persiste à nous dire que le monde entier nous les envie malgré les dégringolades annuelles dans le classement de Shanghaï. Qu'attend-on pour proposer à Google notre excellent site de Bollène, tombé quelque peu en désaffection depuis certains « dysfonctionnements » de la centrale du Tricastin en juillet dernier ?)
Microsoft qui avait annoncé début 2007, juste avant Google, lui aussi un nouveau datacenter de compétition à San Antonio au Texas, (un investissement de $550m, médaille d'argent au podium des dépenses BTP des géants de l'Internet), vient de publier sa propre vision du « cloud computing » qui sera officiellement dévoilée en octobre prochain, à l'occasion de sa Professional Developers Conference (amateurs s'abstenir !). Tel un moderne Carl Linnaeus — mais non, pas Linux ! Carl von Linné, voyons ! naturaliste suédois fondateur de la systématique — David Chappell, l'auteur du papier, propose une taxonomie qui a le mérite de clarifier les initiatives techniques pour le moins proliférantes de l'éditeur de Redmond :
- Red Dog annoncé par Ray Ozzie en avril dernier et généralement perçu comme une réponse immédiate à AppEngine de Google lancé à la même époque ; et plus généralement comme un contrepoids au grand-père fondateur reconnu de tous les services de « cloud computing », EC2 (Elastic Compute Cloud) d'Amazon.
- BizTalk Services, le terme générique désignant les technologies liées au processus métier (business processes) et leur interconnexion — SOAP dopé au workflow amphétaminé maison (Windows Workflow Foundation).
- Zurich un mystérieux projet de plateforme de cloud computing pour les ISV, voilé derrière les sous-entendus d'un Ray Ozzie et d'un Bill Gates qui n'en finit pas d'être sur le départ.
- SQL Server Data Services (SSDS) du stockage distant « à la demande », composant indispensable d'une architecture distribuée. (Là-aussi l'antériorité d'Amazon avec S3 (Simple Storage Services) et SimpleDB vient assez vite à l'esprit.)
- Microsoft Dynamics CRM Live clairement opposé à Salesforce.com avec Force.com et Apex.
La classification périodique proposée par notre Mendéleïev du jour — au moins le chimiste russe ne provoquera pas de confusion politiquement incorrecte à propos de Microsoft entre un naturaliste suédois et un programmeur finlandais ! — distingue trois catégories de services cloud :
- Software as a service (SAAS), recyclage obligatoire de l'acronyme en vogue dont le succès est indubitablement, malgré qu'il en coûte de certainement à Chappell de l'admettre, à mettre au compte de l'insolent Salesforce.com ;
- Les services joints (Attached Services) qui, distants, viennent compléter une application métier tournant localement, l'exemple de Exchange Hosted Services étant mis en avant ;
- Les plateformes cloud, probablement les plus innovantes qui, rendues possibles par le développement récent des techniques de virtualisation et de services Web, sont aujourd'hui en concurrence pour s'attirer les faveurs des développeurs.
Ceux dont l'âge approche ou dépasse 110000 ans trouveront sans doute que cette classification rappelle de loin, mais mis à l'échelle du Web, Corba et la subdivision proposée à l'origine par l'Object Management Group de l'univers en objets métiers (Domain Specifications), objets techniques (Corbaservices) et middleware (Object Request Broker). D'ailleurs, il y a exactement dix ans, David Chappell, l'auteur même de ce position paper de Microsoft se dévoilait fort critique de l'OMG et de Corba.
Il y aurait certainement beaucoup à commenter autour de ces premières idées de mise en ordre de l'architecture distribuée des applications d’informatique d'entreprise — sans parler des enjeux économiques et d'organisation. À ce stade, il est peut-être simplement intéressant de souligner à quel point la résilience de certaines techniques, dont la pratique plutôt que la théorie a présidé au choix par le passé, reste visible dans ces concepts que l'on nous (re)présente comme nouveaux, innovants, voire bouleversants et prioritaires.
En l’occurrence, on pourrait lire dans le cloud computing le retour triomphal du RPC.
Alors que le vétéran fruste des débuts balbutiants d'une informatique naissante semblait à tous infréquentable, au dernier stade du Parkinson, et relégué à une disparition silencieuse et bienvenue dans l'oubli poussiéreux des salles de musées logiciel, il fait un retour à la scène inattendu en meilleure forme que jamais ! (Le RPC est, après tout, bien plus jeune que Madonna.)
Prenons Google à nouveau : Protocol Buffers, nous dit-on, forment une méthode de codage des donnés structurées très efficace et cependant facile à enrichir ; « Google utilise Protocol Buffers pour pratiquement tous ses formats internes de fichiers et de protocoles RPC ». (Et GWT RPC alors ?) Du côté du navigateur client maintenant, JSON est « un format léger d'échange de données » adapté à Javascript et complément fréquent de l'architecture Ajax. Mais ce n'est pas tout : Facebook, le réseau social que l'on ne présente plus, a fait donation à
Pourquoi un tel retour en grâce du RPC ? D'abord, ne pas négliger les mouvements de mode (toujours d'actualité en informatique comme ailleurs) : les réseaux sociaux sont cools donc le RPC, qu'ils mettent en œuvre, est cool ! Sinon qu'est ce qui pousserait Microsoft à acheter 1,6 % de Facebook pour $240m ? Ou Cisco à acheter Tribe.net après Five Across ? Sans parler de Google et YouTube et autres transactions qui défraient la chronique (et effraient le chroniqueur).
Ensuite il y a l'effet de fatigue SOAP. Mis au point il y a dix ans en s'appuyant sur les technologies les plus cools du moment, XML et HTTP, SOAP a été présenté par les obsédés de l'interopérabilité, craignant à juste titre il est vrai la domination impérialiste d'un certain éditeur, comme le protocole définitif d'échange de données à l'heure du Web. Esprit de « coopétition » oblige, les groupes de travail réunissant les ennemis d'hier ont proliféré, les manifestations de bonnes intentions standardisatrices se sont multipliées ainsi que les spécifications, sous-spécifications et leurs variantes au W3C, à l'IETF et à l'OASIS (15 recommandations au W3C et 10 groupes de travail, 12 comités techniques à l'OASIS et une quarantaine de spécifications), sans parler des subtiles variations entre les implémentations commerciales de telle ou telle spécification.
Protocole réputé lourd, SOAP est donc souvent invoqué comme exutoire par les promoteurs de ces nouveaux RPC qui se réclament, par contraste, de l'architecture REST. (Si l'on en croit la blogosphère, le débat « SOAP ou REST » est largement tranché.) En fait, beaucoup de ces RPC réinventés sont livrés en Open Source et pour le programmeur pragmatique, du moment que c'est gratuit et que l'implémentation fait raisonnablement le travail qu'on attend d'elle, pourquoi creuser plus loin ? Il serait pourtant salutaire de relire à la lueur des annonces actuelles la note prémonitoire (1994 !) de Jim Waldo, Distinguished Engineer du projet Darkstar chez Sun Microsystems, une plateforme de cloud computing pour les mondes virtuels, les jeux en ligne et les résaux sociaux « massifs ». Dans ce monde post-SOAP, le RPC n'est plus un protocole c'est plutôt l'absence de protocole...
Voilà qui promet bien des maux de tête pour nos naturalistes systématiciens et nos urbanistes des systèmes d'information !
