Réflexions personnelles sur les "clouds internes"

Comme vous avez pu le remarquer à la baisse de fréquence de publication sur ce blog, les actualités sont actuellement en vacances et les annonces du moment n'ont plus beaucoup d'originalité (on retrouve toujours les mêmes idées proposéss par de nouveaux fournisseurs)...

Ce calme ambiant me permet de rebondir sur une note de recherche de James Staten, analyste chez Forrester Research, intitulée "You're not ready for internal cloud" (réservée aux clients Forrester). Faute d'un accès client, je n'ai pu lire l'intégralité de cette note mais son résumé reflète mes propres réflexions sur le "cloud interne", que je vais donc synthétiser ici.

Le concept de "cloud interne" a  émergé comme une réponse aux craintes que le "cloud computing" (externe, donc) soulevait dans les DSI des grandes entreprises. En effet, malgré ses avantages de flexibilité et de coût, généralement reconnus, le cloud reste considéré avec méfiance (parfois à tort, mais ce sera l'objet d'un autre article) en raison de la perte de contrôle qu'il induit sur une partie du coeur de métier traditionnel de la DSI, qui se traduit par des interrogations sur la sécurité, la localisation géographique des données, la qualité de service... Le "cloud interne", qui consiste à appliquer les "recettes" du cloud dans les centres informatiques de l'entreprise, apparaît donc comme la solution idéale pour en tirer les bénéfices en éliminant les risques associés.

Avec des centres de production abritant des centaines, voire des milliers, de serveurs hébergeant une myriade d'applications, l'idée semble raisonnable et est même perçue comme une cible naturelle après les efforts entamés par bon nombre d'entreprises pour virtualiser leurs infrastructures. Malheureusement, cette cible sera beaucoup plus difficile à atteindre qu'il n'y paraît et il est presque certain que les "clouds" publics auront largement envahi le paysage informatique avant que de vrais "clouds internes" soient en place.

Pour le comprendre, commençons par rappeler quelques caractéristiques essentielles du "cloud computing" :

• L'élasticité qui permet d'adapter, à la hausse comme à la baisse, la délivrance de ressources aux besoins réels des applications ;
• La fourniture des ressources informatiques sous forme de service, facturé à l'usage ;
• Le partage des ressources entre de multiples clients, condition essentielle pour un modèle économique viable.

Or, pour que le "cloud interne" offre ces qualités (et délivre ainsi ses promesses de flexibilité et de rationnalisation des coûts), il est évident qu'un ensemble de conditions préalables doivent être remplies, parmi lesquelles :

• Un outillage adapté, permettant l'allocation "à la demande" et l'administration des ressources informatiques, doit être mis en place et parfaitement opérationnel ;
• Les équipes de production doivent non seulement maîtriser cet outillage mais aussi adapter leurs processus à un nouveau mode de fonctionnement où les serveurs physiques, les serveurs virtuels et les applications sont totalement décorrélés les uns des autres ;
• Le parc informatique doit converger vers un tout petit nombre de configurations totalement homogènes et banalisées (car l'équation financière du cloud est basée sur un modèle d'économie d'échelle, nécessitant un volume critique) ;
• Cela implique que les projets doivent également être contraints par ces choix de configurations (adieu le serveur exotique pour mettre en place un nouveau progiciel extraordinaire !).

On le voit bien, ces pré-requis vont nécessiter des efforts importants, d'une part pour adapter les comportements de la DSI et de ses clients et d'autre part en termes financiers car la plupart de ces transformations ont un coût non négligeable. De l'autre côté de la balance économique, les bénéfices seront certainement réels, avec des économies d'infrastructure presque évidentes, mais ils ne seront visibles que lorsque le "cloud interne" aura atteint une masse critique. Ce qui risque d'induire une situation d'attentisme classique dans les grandes entreprises : comment justifier un investissement important dans un projet transverse d'infrastructure dont la rentabilité dépendra de son adoption sur le long terme par des clients incertains ?

Bien entendu, ces difficultés seront traitées avec le temps et le "cloud interne" arrivera bien un jour sous une forme ou une autre (on peut d'ailleurs arguer que c'est déjà le cas dans certaines entreprises sur quelques niches, par exemple pour le stockage mutualisé). Mais si demain matin une demande de déploiement d'application sur Amazon EC2 arrive sur votre bureau, ne promettez pas de pouvoir l'installer sur votre "cloud interne" après-demain !