Le cloud computing

Posté le samedi 5 septembre 2009 à 1 h 59, Read it in english with Google

C’est la mode depuis quelques annĂ©es et tout le monde ce met Ă  en parler maintenant qu’il lui on a trouver un nom : le cloud computing est partout. Traduction brut : l’informatique dans les nuages, un nuage de serveur, une meilleure façon de dire externalisation de service. Il permet de confier des fonctionnalitĂ©s ainsi que des donnĂ©es Ă  des entreprises tierces chargĂ©es de les gĂ©rer et de vous fournir (ou non) une interface appropriĂ©e pour vous dĂ©charger de la gestion de ces donnĂ©es ainsi que de la crĂ©ation et de la maintenance de ces applicatifs.

Toutes les entreprises proposant un cloud vous promettront monts et merveilles. Plus de gestion, plus de prise de tĂŞte, plus d’astreinte, ils s’occupe de ça. A priori, ils s’en occupent bien, puisque c’est leur mĂ©tier et qu’ils ont mis en place des processus adaptĂ©s pour vous fournir ces services. La loi de la factorisation fait que ça leur coute moins cher que si vous le faisiez vous mĂŞme (gĂ©nĂ©ralement). Il y a plusieurs sortes de cloud computing : SaaS, PaaS, IaaS et j’en oublie surement. Pour les exemple il y en a Ă  la pelle, Amazon EC2, Google App, delicious, megaupload 🙂 … globalement tout ce que vous avez en ligne qui semble vous appartenir.

Il y a plusieurs questions Ă  se poser avant de choisir de balancer toutes ses donnĂ©es sur un cloud, ici je n’indique que le point de vue de la DSI, du cĂ´tĂ© des utilisateurs, ils s’adapteront s’il y a Ă©volution).
– Quel niveau de confidentialitĂ© ont vos donnĂ©es ?
ĂŠtes vous prĂ©t Ă  risquer que quelqu’un puisse les lires ? Au-dela des contrats, les fuites existent, c’est un fait. Si le nuage n’est pas assez grand pour vous noyez dedans, je pense que c’est un risque.
– A quel point l’accès est critique ?
Les acteurs du cloud computing ont une très forte disponibilitĂ© pour un peu que vous sachiez Ă©carter les mauvais prestataires. Mais peut-ĂŞtre que la panne qui arrivera juste Ă  un moment crucial… aucun service n’est fiable Ă  100%.
– Qu’en est-il de l’export de ses donnĂ©es ?
Si vous ne pouvez pas exportez vos données dans un format brut ou via une API, vous oubliez !
– Le service propose-t-il toutes les fonctionnalitĂ©s dont vous avez besoin ?
C’est le gros problème gĂ©nĂ©ralement. On vous montre une belle interface, c’est tout beau c’est tout propre, on vous montre quelques fonctionnalitĂ©s avancĂ©s, c’est magnifique je prend ! et lĂ  1 mois plus tard vous vous rendez compte que cette fonctionnalitĂ© bug, ou qu’il vous en manque une cruciale… aĂŻe, vous tentez de voir avec le support, ils peuvent rien faire parce que ça impacterais des centaines de leur client, ou bien oui le bug sera rĂ©glĂ© dans 6 mois. Vous allez donc demandez Ă  votre dev prĂ©fĂ©rĂ© qu’il se dĂ©merde avec l’API (si il y a) pour voir « si y a pa moyen de »… Votre dev super mega geek qui vous a dit avant que vous signez que ça puait ce truck (ça sent le vĂ©cu lĂ ).

Il reste d’autres questions dĂ©pendantes du service auquel vous voulez souscrire comme : votre connexion internet vous le permet-elle ? quel sera le coĂ»t de dĂ©ploiement ? … Vous prenez tout ça, et vous vous posez une dernière question qu’on ne se pose pas forcĂ©ment : quel est la durĂ©e de vie de ce service ? Souvenez vous qu’en informatique tout bouge très vite.

Je ne suis pas contre le cloud computing, mais je n’ai pas la tĂŞte dans les nuages. Il y a des services qui sont extrĂŞmement rentable mĂŞme Ă  long termes (Amazon EC2 par exemple) mais dans beaucoup de cas le coĂ»t de recherche pour la compatibilitĂ© avec vos besoins et le coup de dĂ©ploiement (software et prise en main utilisateur), sans comptez le fait que si vous vous trompez c’est la cata, est largement plus haut que le coup de crĂ©ation d’une solution sur mesure, sur laquelle en plus vous aurez la main, qui sera pĂ©renne, et que vous pourrez adapter pour faciliter la prise en main des utilisateurs ou pour des Ă©volutions. Il faut donc ĂŞtre très prudent avec le cloud computing. Il peut vous apportez autant d’avantages que d’inconvĂ©nient. Et rappelez vous toujours qu’on est jamais aussi bien servi que par soit-mĂŞme.

3 réponses à “Le cloud computing”

  1. raymond

    juste une petite rectification pour amazon. S3 est la partie stockage. EC2 est la partie instance et peut utiliser une unité de stockage S3.

    Il est vrai qu’une application en mode SaaS n’est pas fiable Ă  100% comme toutes application : La, tu as raison ;-).

    Mais la question Ă  mon sens qui faut se poser serait plutĂ´t la suivante :

    Est ce que c’est mieux d’avoir mon application de ecommerce (par exemple) sur une infrastructure dĂ©diĂ© traditionnelle (j’ai une ferme de serveur frontaux + base de donnĂ©es; load balancer ….) ou un ensemble d’instance sur un cloud de type EC2 ?

    Dans le premier cas, la montĂ©e en charge nĂ©cessite de rajouter des machines (installation, parametrage etc …) et va entraĂ®ner un dĂ©lais d’intervention relativement Ă©levĂ© !
    Dans le second cas pour les mĂŞme raison de montĂ©e en charge, le rajout d’une instance Ă  son pool de frontaux est casiment instantanĂ© !!!! et en plus avec un peut de configuration, on peut linker le dĂ©marrage de l’instance avec un dĂ©pot svn !!!. Du coup la rĂ©activitĂ© est très courte !!!!
    Mon exemple est court 🙂 mais montre le potentiel de savoir maitriser un cloud !.

    Toutes les discutions qui disent ou qui prĂ©sente le cloud comme moins fiable, moins sĂ©curisĂ© etc … ce trompent et Ă  juste titre puisque les problèmes de sĂ©curitĂ© ont toujours existĂ©s aussi sur de l’hĂ©bergement dit traditionnel.
    Il est Ă©vident que la maitrise d’un cloud et la maitrise des concepts sous jacents n’est pas chose facile.

  2. XoraX

    Exact c’est modifiĂ© (S3 -> EC2). Je mettais aventurĂ© un peu trop longtemps dans les spec de S3 🙂

    Je suis d’accord avec pour la rapiditĂ© de gestion et d’extension d’un cloud. Cela dit ça me parait une approche très utopique. Ok il faut que il faut que je rajoute des serveurs si je veux monter en charge sur mon infrastructure perso. C’est long, c’est lourd. Mais je suis sur d’arrivĂ© Ă  en faire ce que je veux. Ce qui n’est pas le cas pour un cloud car il y a un niveau de plus, non modifiable celui-lĂ  et qui plus est propriĂ©taire. Qui dit dĂ©pendance de plus dit bug potentielle.

    Et c’est d’ailleurs le cas de EC2, qui publie des parfois des vulnĂ©rabilitĂ©s (niveau rĂ©seau dernièrement il me semble). Plus critique encore (c’est ce qui m’a fait revenir sur le sujet), le MIT vient de publier une Ă©tude sur la vulnĂ©rabilitĂ© des donnĂ©es elle mĂŞme (fr simplifiĂ©). Vu la mĂ©thode et l’impact sur le système, je me doute qu’il faudra un temps Ă  Amazon avant de corriger ça.

    Donc sur ce coup, il faut tout de mĂŞme l’avouer, on gagne en sĂ©curitĂ© globale mais pas en temps de rĂ©ponse face Ă  une attaque potentielle.

    Au final avis partagĂ© pour ma part. Si on part de zero dans le cas gĂ©nĂ©ral, pourquoi pas tenter sur un cloud. Si on a dĂ©jĂ  une certaine expĂ©rience ça me semble risquĂ© pour l’instant. Mais nul doute que l’avenir est lĂ  🙂

    PS : ça m’attriste un peu tout de mĂŞme de savoir que dans 20 ans on sera tous sur des sous-sous-sous-systèmes^n…

  3. Deenox

    Ovh se lance met dedans mais appelle ça le mini cloud, pas contre je cherche encore l’utilitĂ© que je peux en avoir.

Laissez un commentaire :