A quoi faut-il réfléchir dans le cadre de l’adoption de technologies cloud au sein d’une entreprise ?  En effet, quelle que soit la définition du cloud qu’on puisse prendre, un point commun emerge : le partage des ressources (multi-tenancy). Ces technologies n’ont de sens que dans la démesure. Pour atteindre cette masse critique il faut mutualiser.

Aussi, que le cloud soit interne ou externe à l’organisation, il devra être partagé, et donc géré par un (ensemble) service(s) dédié(s) et transverse(s) à qui reviendra la tâche de gérer les ressources informatiques (stockage, nombre de serveur, monitoring …) Cette gestion, qui était auparavant potentiellement répartie dans les différents service IT de l’organisation sera donc déléguée à un prestataire, une fois encore, interne ou externe… on ne fait que réinventer le services centraux si chers au mainframers.

Il est évident, dès lors, que les grands équilibres vont évoluer au sein des différents services (IT et probablement autres) de l’organisation. Il apparaît certain que les entreprises qui feront le choix d’aller vers le cloud, devront apporter le plus grand soin dans l’élaboration des définitions de services, le choix des technologies et des procédures, la mise en place des équipes et l’intégration des nouveaux processus dans les anciens. Elles devront par ailleurs, et surtout, être très vigilantes dans l’accompagnement qu’elles offriront à leur collaborateurs vers ces nouvelles façons de penser, sous peine de voir les corporatisme, reflexe de refus du changement et autres luttes de pouvoir (hélas inhérentes à toutes les organisations, quasiment quelle qu’en soit leur taille) réduire en miette leurs efforts.

1. Conduire un Audit de pré-déploiement et de préparation

Déterminer les cas d’usage des technologies de cloud computing, les domaines d’utilisation et les conséquences que le remplacement des anciennes technologies et procédures va avoir dans l’organisation. Comment la mise en place d’un service de stockage à la sauce cloud peut elle impacter vos services ?

a/ Techniquement : Déterminer grâce aux demandes utilisateurs (par utilisateur, par département puis au niveau de l’organisation dans son ensemble) les besoins de ressources techniques induite par le changement. Cette étape de dimensionnement doit concerner les serveurs, le stockage, les infrastructure réseau, les nouvelles couches logiciels… On doit prendre en compte des problématique de priorité de service, de sécurité mais aussi d’interdépendance des SI. En effet, lorsqu’il s’agit de relier différents SI (de plusieurs services) on s’assurera que la politique de l’organisation permet ce type de lien, et dans quelles conditions (cloisonnement, asynchronisme des services…). Comment souhaite-ton relier ce cloud aux anciens service de l’entreprises ? quelles API ? Souhaite-t-on pouvoir accéder a différents cloud (interne et externe) et si oui comment s’assurer de la compatibilité (premier pas vers la réversibilité)

b/ Organisationnellement : Si certaines responsabilité doivent être transférées comment l’annoncer, et gérer les problématiques politiques cela induit. Les personne anciennement en charge des activités techniques doivent elles être transférées, doivent elle être réaffectées. Leur métier doit il évoluer pour se concentrer vers d’autres secteurs. Ces questions se posent naturellement pour le ressources techniques chargées de l’exploitation mais également concernant les ressources non techniques (relations clients, suivi , pricing …). Au contraire de nouveaux métiers n’apparaissent-il pas du fait de ce changement ?

c/ Humainement : Ce point découle directement du précédent. Les compétences utiles à de tels déploiements sont, pour certaines, assez spécifiques et éloignées de celles utilisées auparavant. Il faut donc accompagner les collaborateurs de l’organisation vers ces nouveaux usages, les former, leur expliquer en quoi ces changements sont utiles à l’organisation ainsi qu’à eux, ce qu’ils peuvent en retirer (en terme de confort au quotidien, en terme de carrière)… L’évangélisation ne doit pas s’arrêter aux responsables des principaux départements, les personnes qui seront chargées de l’exploitation de ces nouveaux services doivent absolument être convaincues du bien fondé de ces changement et y prendre une part active.

d/ Financièrement : Les échanges financiers au sein de l’organisation sont eux aussi appelé à évoluer. Qu’achètent dorénavant les différents départements ? Un service et non du matériel amortissable. Cela peut changer grandement les problématiques comptables. De plus, à qui est fait cet achat, un prestataire exterieur, un département interne spécialisé ?

2. Déplacer le focus des directions informatiques

a/ Techniquement : L’avantage du Cloud Computing repose sur le fait de placer le fardeau des applications, du stockage réseau et de la puissance serveurs vers un autre réseau, une autre organisation. Les priorité de ces dernières doivent donc évoluer pour ne plus se concentrer sur les problématiques matérielles mais bien sur des questions plus applicatives, architecturales. Elles sont également susceptibles de conserver une activiété de provisionning pour autant que des problématiques de place de marché (avec prix basé sur offre et demande) aient été mise en place. L’infrastructure est alors largement désolidarisée des services a plus fortes valeurs ajoutée

b/ Organisationnellement : Certes, tout un pan de leur activité actuelle leur échappe, mais ces problématiques étant réglées par ailleurs, elles auront toute la latitude de se concentrer sur leur vrai métier : apporter à leur utilisateurs les fonctions qu’ils demandent (développement d’applications spécifique, services transverses…)  tout en garantissant que les développements et autres directions prises resteront en ligne avec les grandes directions choisie par le management (en terme business essentiellement).

c/ Humainement : Les collaborateurs des différentes directions informatiques se réorientent vers des tâches plus métier, et ont un role de charnière plus prononcés entre les études et les service

d/ Financièrement : cf1.

3. Déterminer les priorités

a/ Techniquement : La priorisation des traitements et des dialogues devient critique. En effet l’architecture étant multi-tenants il n’est pas question qu’un seul utilisateurs monopolise une partie des ressources du centre technique qui ne serait pas à la mesure de ce qu’il achète. Il faut donc être en mesure de suivre la consommation des manière très précise, par client, sur l’ensemble des infrastructures (puissance, stockage et réseau) et de prévoir des alertes et autres modes dégradés lorsque ces limites de consommations sont atteintes.

b/ Organisationnellement : L’ouverture du service est elle un impératif à très courte échéance ? Dans ce cas, il est peu probable que les compétences nécessaires se trouvent toutes en interne, il faudra surement passer par de la prestation. Dans un premier temps donc, les structures transverses serviront uniquement, ou principalement, de recette, contrôle le temps que les passages de compétences puissent se faire.  On peut mime penser que certaines organisation préfèreront s’en remettre totalement à un prestataire externe, afin de se décharger complètement des problématiques liées. Cependant la structure de contrôle devra rester afin de gérer la relation avec ce prestataire (controle de niveau de service, de facturation …)

c/ Humainement : Dans quelle mesure souhaite-ton faire évoluer les collaborateurs ? Les compétences doivent elles entrer dans le patrimoine de l’entreprise. Quelle échelle de temps est elle prévue pour faire le passage de compétence ? Bref, dans le cadre de l’internalisation d’un cloud, il faut clairement s’interesser au plan de formation. Dans le cas d’une prestation externe, il semble également judicieux de s’interroger sur la disponibilité chez le prestataires des ressources compétentes.

d/ Financièrement : Quels sont les services devant être toujours accessibles aux clients ? Y a t-il des clients plus prioritaires ? Il faut clairement prévoir des niveaux de services différents aux sein des SLA. Bien entendu ces services devront être sur des bases de facturations différentes.

4. Considérer la redondance des ressources

a/ Techniquement : Les systèmes utilisés doivent tous etre completement redondé. Il faut également penser a redonder les moyens d’accès au cloud (accès internet ou infrastructures internes) afin de garantir la continuité de service.

b/ Organisationnellement : Les services critiques doivent être identifiés, et dès lors géré de façon continue afin que les SLA soient également garanti sur l’organisation et pas uniquement sur les composant techniques. Des audits doivent être mis en place afin de juger la fiabilité des différents composants nécessaires (techniques ou non) au respect du SLA

c/ Humainement : Les compétences doivent etre gérés afin de s’assurer qu’aucun homme clé n’apparaisse, qui détiendrai seul une partie de connaissance critique du système.

d/ Financièrement :

5. Responsabilités et contrôle des fournisseurs de services

a/ Techniquement : Il faut s’assurer que les technologies utilisées dans le cloud et les moyens d’accès sont bien en phase avec les garanties exigées par le SLA.

b/ Organisationnellement : Il faut mettre en place une entité de suivi du SLA, indépendante de celle qui gère le cloud,  qui surveillera le respect du SLA.

c/ Humainement : Les membres des équipes engagées doivent etre impliqués dans la réussite du service de cloud et sensibilisés aux enjeux métiers qui en découlent. Une phase de “formation” (technique et métier) doit précéder leur prise de fonction.

d/ Financièrement : Le respect des SLA prend une importance primordiale dans la facturation du service. Ces derniers doivent donc indiquer de manière très précise les engagements de service demandé par service, en terme de disponibilité, performances, perte potentielle d’information, support.

Avant de partir j’ai écouté Eric présenter le travail et l’engagement de Sun dans le domain du cloud computing (cf son blogs, en ce qui me concerne je reviendrai surement dessus plus tard) puis l’intervention de Sam Johnston dont je lis régulièrement le blog et qui a présenté rapidement le cloud au travers de ses grandes caractéristiques (opex et non capex, commodity,virtualisation, admin automatique) et qui a présenté rapidement la carte mentale faite par Peter Laird concernant les principaux vendeur de services clouds.

J’ai ensuite participé au workshop sur l’architecture du cloud qui s’est révélé très intéressant tant par l’animation qui a été faite par Constantin Gonzalez Schmitz (sun) et Sébastien Pahl que par les contributions des participants. Les points suivants ont été évoqués :

Cloud Comuting Architecture workshop
but réutilisabilité du code entre les clouds et réversibilité
attention il faut vraiment séparer les chiottes différentes LB / Apache /DB  … ça facilite le réversibilité
séparer également les service.

1/ Structured data SQL : les bases de données relationnelles ne sont pas toujours indispensable ni même adaptées au stockage de données structurées, il faut impérativement penser à utiliser Key/value stores ou les bases de données un peu plus évoluées telles que couchdb !! Par ailleurs, il a été évoqué dans ce cadre que MySQL (ainsi que bon nombre d’autre SGBDR classiques) pouvait devenir votre “pire ennemi”  (dixit)  dans le cadre de scabilité (attention a la réplication , aux incréments…)
2/ Introduire de l’asynchrone : tout n’est pas nécessairement synchrone, et l’utilisation de Message Queueing est sans aucun doute l’un des premiers pas à faire vers la scalabilité des applications

3/ Les applications doivent être pensée pour etre scalables sans que  le développeurs ne doive se poser d’autre problèmes que les problèmes métiers. Les couches de scalabilité doivent introduire assez d’abstraction pour que cela soit pris en charge de manière transaprente. Quoi qu’il en soit le développeur doit penser REST.

On y voit que les recherches sont corrélées avec la décroissance de celle concernant le grid computing et qu’elles suivent l’augmentation des requêtes concernant la virtualisation.

Bien entendu les intervenants historiques de l’informatique  (Oracle, HP…)  minimisent le côté novateur du Cloud (voire en discute carrément l’existence)  en prétendant ne pas voir de nouveauté dans ces concepts. “Un buzz marketing” sur d’anciennes technologies déjà en oeuvre pour les uns, de multiples définitions sans cohérence pour les autres. Rien d’étonnant me direz-vous, surtout lorsqu’on voit les constructeurs à la peine pour suivre cette nouvelle tendance. En effet, ces derniers tentent toujours de vendre des baies de stockage, des serveurs surpuissant ou des logiciels. dont les  coûts de licences sont calculés par core , a des prix élevés. Parallèlement  de nouveaux entrants se basent sur des paradigmes assez différents des éditeurs et constructeurs actuels, profitant des matériels bon marchés et des logiciels open sources gratuits.

La fin des modèles traditionnels : Pourquoi ?

Cette opposition tant technologique que culturelle semble marquer la fin des modèles traditionnels (ou tout au moins une évolution très notable) qui régissent l’informatique depuis l’avènement des plateforme open (*NIX, windows) alors que les plateformes mainframes régnaient sans partage sur l’informatique. Pour illustrer ce propos, prenons l’exemple du stockage de données, l’un des domaines de prédilection du cloud.

Rappelons l’image courante dans ce domaine : “Chaque année, sont produites autant de données que le cumul des données produites jusqu’à l’année précédente“.  Plus actuellement, en 2008 l’IDC affirme qu’en 2009 40 exabytes de données seront produites. On constate que ces données sont de plus en plus non structurées. Dématérialisation et explosions du multimédia poussent au stockage de vidéo, audio et autre PDF.  Par ailleurs, les exigences des départements commerciaux renforcent également les notions de tracking et de profiling des utilisateurs, afin d’améliorer les performances des différents produits commerciaux. Comment dans ces conditions recueillir, stocker et gérer ces données.

En amont de ce problème de gestion se pose celui des taux transactionnels dans les environnements sécurisés. En effet, dans un contexte mutlicanal, comment garantir le maintien de ces taux transactionnels dans des environnements devant prendre en compte des exigences de hautes disponibilités, de Plan de reprise d’activité… Les réplications standards sont de plus en plus compliquées à mettre en œuvre, exploiter et à garder synchrone (ou tout simplement a en garantir un déphasage minimum). Les problématiques de temps de latences sont par ailleurs elles aussi de plus en plus dures à contenir.

Une fois les données recueillies il faut le gérer. Les gérer oui, parce que les stocker n’est pas suffisant. Vos données doivent être exploitées, retraitées, archivées pour leur donner du sens. Le problème est que ces workflows doivent être de plus en plus rapides (tous les 60 jours sont produits 7 exabytes), alors même que les temps de traitement nécessaires à ces volumétries explosent.

Enfin, parallèlement aux temps de traitement, les coûts de gestion et de stockage de ces données deviennent peu à peu des freins ; certains projet n’étant tout simplement plus rentables du fait des contraintes exposées ci-dessus.

Toutes ces évolutions forcent les entreprises à trouver des solutions quitte à s’éloigner des chemins traditionnels

La fin des modèles traditionnels : Comment ?

Si les offres des constructeurs ne semblent que peu évoluer sur le marché (de grosses baies, avec beaucoup de cache…) de nouveaux entrants sur le marché du stockage font leur apparition, Amazon à leur tête. Amazon vous propose tout simplement de ne pas conserver vos données ou vos traitements dans votre propre SI mais de les lui confier (avec les clauses de confidentialités adaptées) et d’en disposer, dès lors,  via internet.  Le tout a des prix ultra compétitifs !

Cette offre ne fait que repousser la question : comment ces prix peuvent ils être atteints ? C’est qu’Amazon se base sur des technologies fort différentes, tout comme un Google, un Yahoo! ou un Facebook. Le paradigme de départ est totalement différent. On ne parle plus ici de concentrer les données dans des baie hyper protégées et de faire appel à des serveur très haut de gamme pour exécuter les traitements mais bien de répartir données et traitements sur un trés grand nombre de machines d’entrée de gamme (commodity hardware). Cela assure tant la haute disponibilité et que de très bon temps de réponse, le tout à des couts largement en baisse (serveurs très standards, disques SATA, et surtout, économies d’échelles, les commandes auprès des constructeurs étant titanesques), et une scalabilité remarquable. Parce qu’en fin de compte c’est de cela qu’il s’agit : répondre de manière aussi linéaire que possible a la charge, quel que soit le volume de données le tout pour un coût aussi réduit que possible.

En regardant dans le passé de ces géants internet, on se rend compte que tous ont commencé par des offres standard de type LAMP, mais que, la charge augmentant ils ont du développer leurs propres outils pour faire face (en se basant sur des projets, et donc des technologies et protocoles, open source et gratuits). Certains  n’ont publié que des white paper sur leur manière de gérer cette charge (c’est le cas de Google : Big Table et GFS) alors que d’autres ont carrément créé ou contribué très fortement à des initiatives open source et grauite (Facebook : Thrift , Yahoo! : Hadoop …)

Il se développe depuis quelques années des offres de virtualisation (Xen), de cache (memcached développé pour LiveJournal.com) , de File Systems distribués (Caringo, MogileFS, GlusterFS, HDFS) dont la vocation n’est plus de concentrer les données mais bien au contraire de les répartir et de les répliquer sur des matériels a bas prix (commodity hardware), afin d’en exploiter au mieux les ressources.

Une rupture technologique mais surtout culturelle est bien en train d’avoir lieu quoi que puissent en dire certains géants.

Attention, peinture fraîche

Etrangement les offres d’un Amazon semblent elles assez au point. Depuis Janvier 2008, d’ailleurs, la bande passante utilisée pour les web service d’Amazon (AWS, les offres de cloud) est supérieure à la bande passante utilisée par le reste des sites web Amazon. Cela indique le nombre de leur client augmente très rapidement et que les données stockées par eux explosent. On est donc passé de la commercialisation de capacité inutilisée a un véritable business, qui , pour avoir rencontré les personnes d’Amazon semble être organisé avec une rigueur martiale. Et la, au contraire, si les noms des clients sont assez durs à avoir (on le comprend aisément) Amazon affiche néanmoins des références solides (NASDAQ, Wall Street Journal, …), et le recul est certains, ces offres étant la base du business d’Amazon depuis un moment déjà.

Alors certes les constructeurs tendent a se rapprocher de ce modèle, mais leurs offres commerciales sont-elles encore adaptées. Je ne parle pas seulement des technologies qui sortent de leurs laboratoires (pas de soucis pour ces dernières qui sont issues en droite ligne des technologies open source qui font la gloire des géants internet) mais surtout des offres commerciales avancées par leur commerciaux ? Assez étrangement, malgré toutes les annonces faites par les constructeurs majeurs, sur l’importance du Cloud et de ses implications, ces commerciaux tardent toujours à proposer des solutions « modernes », ils se font même un peu prier. On les comprend ces offres paraissent bien récentes et « pas encore sèche ». Pas ou peu de recul, très peu de clients et un supports dont la qualité semble faible, tant l’évangélisation dans ces société même semble en retard.