Exotech.biz

Web, Technology & life by Bastien Labelle

Aller au contenu | Aller au menu | Aller à la recherche

Keyword - Cloud Computing

Fil des billets Fil des commentaires

Le cloud computing illustré

Si vous êtes intéressés par le Cloud Computing et tous ses acronymes, comme SaaS, IaaS, PaaS, et j'en passe, voici un petit schéma qui récapitule toute la cloud stack dune manière assez simple.

Cloud continuum, Cloud computing, Cloud stack

Lire la suite...

BaconFile, partagez vos fichiers stockés sur Amazon S3

Nous, les développeurs, les vrais, sommes passionnés par ce que nous faisons, et il n'est pas rare que nous ayons ce que l'on appelle des pico-projects ou side projects, des mini projets qui sont un peu comme des fenêtres ouvertes vers l'extérieur, où l'on expérimente et où l'on apprend.

BaconFile

BaconFile est le nouveau pico-project qu'a lancé Leah il y a quelques semaines. C'est une mini webapp qui permet d'uploader et de partager des fichiers. Au niveau technologies, les fichiers sont stockés exclusivement chez Amazon S3 (il vous faudra donc par conséquent posséder un compte Amazon S3), le backend est basé sur Django couplé à CouchDB. Petit bonus, il est possible de poster les fichiers partagés sur Twitter.

A noter que l'interface est vraiment excellente, très soignée, et signée Wilson Miner, qui fait partie de mon top 5 des meilleurs UI designers sans la moindre hésitation!

Le Cloud est-il fiable?

C'est un fait, du moins pour moi, j'ai tendance à décentraliser pas mal de stockage. SugarSync, Google Docs, Flickr, Delicious et bien d'autres services possèdent des données m'appartenant, et très souvent, j'ai tendance à ne laisser ces données que dans le cloud. J'ai une confiance presque absolue dans le Cloud, c'est la raison pour laquelle mes photos Flickr sont stockées uniquement sur le service, et nulle part ailleurs.

Clouds

Pourtant, une note d'Om Malik vient de m'interpeler. Ma.gnolia, un service de bookmark social vient de perdre ses données, et le CEO ne sait même pas si elles seront récupérables en totalité. Par chance, je n'utilise pas ce service, mais je dois avouer que c'est un peu effrayant de voir qu'en une nuit, un site web pas des moins connus peut perdre la totalité de ses données.

As I evaluate recovery options, I can't provide a certain timeline or prognosis as to to when or to what degree Ma.gnolia or your bookmarks will return; only that this process will take days, not hours.

Ce genre d'évènement peut arriver à tout moment, et surtout à n'importe qui. N'importe qui, oui, car cela concerne pas les sites webs mais aussi les disques durs de nos propres ordinateurs, internes ou externes.

Alors, après cet exemple, peut-on dire que le Cloud est fiable? La réponse est non. Car aucun système n'est fiable à 100%. Mais au fond, est-ce que le taux de défaillance d'un disque dur est plus élevé que le taux de défaillance d'un système décentralisé et répliqué? Pas si sûr. Pour moi, stocker des données dans le Cloud, sur divers services web, est beaucoup plus sûr que de les stocker sur un disque dur interne ou externe. Ce qui est arrivé à Magnolia peut arriver à d'autres. Mais c'est bien trop rare pour oser dire qu'il est plus sûr de stocker ses données chez soi.

Crédit photo: Hans Speijer

Quand les Web Services Amazon provoquent le chaos du Web 2.0

Au premier abord, les Web Services d'Amazon qui couvrent des services liés au cloud computing, notamment Platform as a Service (EC2) ou encore Infrastructure as a Service (S3), sont très avantageux pour de nombreuses start-ups. En effets, ces derniers permettent de bénéficier d'infrastructures haute disponibilité à moindre coût, étant donné que la facturation se fait en fonction de la consommation.

Amazon Web Services

Le succès d'Amazon dans ce domaine n'est plus à faire, de nombreuses Startups utilisent notamment S3, je pense par exemple au service d'avatar décentralisé Gravatar, ou encore à Twitter qui l'utilise aussi pour ses avatars, mais aussi Pownce qui y gère tous ses fichiers, mais aussi certains blogs, comme Center Networks. Dans la nuit de dimanche à lundi, les Web Services d'Amazon ont connu un gros downtime, qui a provoqué l'indisponibilité des sites cités plus haut, mais aussi de nombreux autres.

Les raisons sont désormais révélées, il s'agissait en fait d'un problème de load-balancing. L'essentiel étant que tous les systèmes sont redevenus stables. Cependant, c'est la deuxième fois de l'année que les AWS connaissent un sérieux downtime.

On peut alors légitimement se demander si externaliser les services est judicieux ou non. A cette question, je répondrais sans hésitation oui. Pour plusieurs raisons. D'abord en termes de coût, bien évidemment, et c'est d'ailleurs le principal intérêt. Mais l'aspect compétences n'est pas non plus négligeable: derrière les AWS, il y a des experts en scalabilité. Prenons par exemple un service comme Twitter, qui a déjà beaucoup de mal à assurer en termes de scalabilité: Il connait beaucoup plus de downtimes qu'en a connu Amazon S3. En imaginant que les avatars ne soient pas externalisés, on peut facilement déduire que ce seraient de nouveaux problèmes à la charge d'une petite équipe.

Pour toutes ces raisons il me semble que les services qui tournent autour du cloud computing comme Amazon S3 sont malgré les downtime de très bonnes solutions. Qui dit que gérer ses propres serveurs va permettre d'éviter ces downtimes? L'administration système est après tout un métier à part entière!

Quelles solutions pour la scalabilité des API?

L'API d'une application web permet aux développeurs de créer leurs propres programmes pour utiliser ou créer de nouveaux usages à l'application déjà existante. Nombreux sont les sites web qui en disposent, je pense notamment au pionnier Flickr, dont les mashups sont innombrables, à Delicious, qui permet de sauvegarder ses favoris via le site web mais aussi sur Firefox. Plus récemment, les services de micro-blogging comme Twitter ont grâce à leur API trouvé de nouveaux usages: Des mashups de recherche comme l'excellent Summize. Et il y a aussi Pownce, qui possède un client AIR très agréable.

Comme Rémian le remarque très bien sur son blog, fournir une API aux développeurs peut s'avérer parfois très dangereux, notamment dès lors qu'une application est mal codée, ou qu'elle abuse intentionnellement. Ces usages révèlent une faiblesse majeure et pourtant essentielle: le problème de la scalabilité, qui implique qu'une application ou un service doit pouvoir supporter une charge de traffic et de connexions très importantes.

Hacker 1992

Il y a d'abord une phase essentielle d'optimisation logicielle, qui implique le code, la base de données, mais aussi parfois le système d'exploitation: il est essentiel de gagner du temps à tout les niveaux, car le temps gagné implique que l'on peut faire bien des choses pendant ce temps libre, à commencer par répondre à plus de requêtes, et donc gagner en scalabilité.

Mais la vraie problématique se situe au niveau des serveurs. Faut-il plus de serveurs dès lors qu'on commence à être saturé? La plupart des administrateurs systèmes auront tendance à répondre que bien souvent ce n'est pas la faute aux serveurs, mais aux développeurs qui codent mal leurs applications. Et pourtant, une application a beau être bien codée, les serveurs arrivent souvent à saturation.

Et j'aurais tendance à penser que la vraie solution passe par les offres de platform as a service du genre Google App Engine. C'est une solution qui semble avantageuse car elle est basée sur le pay as you consume, mais aussi techniquement, car ces offres sont basées sur des technologies de cloud computing qui favorisent un déploiement facile, du fait de l'utilisation des technologies de virtualisation.

Les récents problèmes rencontrés par les différents services, par ailleurs essentiellement ceux de micro-blogging, me poussent à penser que les offres de platform as a service devraient exploser dans les prochains mois à venir, un peu à l'image des offres d'infrastructure as a service de type Amazon S3, qui sont devenues incontournables ces derniers mois.

Note pour moi-même: penser à faire bientôt un dossier Cloud, IaaS, PaaS, SaaS pour ne pas perdre mes visiteurs ;)

CloudFS peut-il concurrencer Amazon S3?

Le stockage on-demand repose actuellement sur trois notions essentielles:

  • Un stockage illimité, car décentralisé
  • Les services web: une API RESTful est à disposition des développeurs afin de faire abstraction de la couche physique du stockage
  • Le pay for what you use: Le service est facturé selon la consommation, c'est d'ailleurs le business model de tout ce qui tourne autour du cloud computing

Mosso, la start-up de RackSpace, spécialisée dans le domaine de l'infrastructure as a service a lancé hier son nouveau service de stockage on-demand qui se posera en concurrence directe avec Amazon S3. Ce nouveau service s'appelle CloudFS, et est en beta privée.

Mosso

Au niveau de la tarification, elle est pour l'instant simple comme bonjour, et est annoncée au prix de 0,15$ par Go. Aucune autre précision n'étant donnée, je suppose qu'il s'agit là d'un coût global qui comprend à la fois le stockage, les accès, mais aussi le transfert des données. Fini donc le casse-tête d'Amazon S3, où les tarifs sont dégressifs et où il faut prendre en compte tous ces paramètres: CloudFS arrive donc à trouver une sorte de juste milieu dans la tarification de ses services.

Cependant, cette notion de prix dépend énormément du type d'usage de l'application que l'on souhaite créer. Pour le partage de fichiers sur Pownce, par exemple, il sera plus avantageux d'utiliser S3 dans la mesure ou chaque utilisateur partage chaque fichier avec son réseau d'amis, ce qui implique qui implique que le prix du stockage prime sur les accès effectués aux fichiers stockés. D'ailleurs, Pownce utilise S3 pour cette fonctionnalité. En revanche, pour un service comme Gravatar, où le stockage nécessaire est celui d'une image qui sera affiché sur de nombreuses pages, il sera préférable d'utiliser CloudFS, qui prend en compte le stockage et les accès dans sa tarification.

Outre la notion de prix, il n'en demeure pas moins que CloudFS est une copie d'Amazon S3. C'est du moins ce qu'en concluerait Kevin Kelly d'après son billet "Better than free" (une traduction est disponible sur Biologeek). Entrent alors en compte d'autres paramètres, tels que la confiance: Qui fera confiance à Mosso, tout en sachant qu'Amazon est sensiblement tout aussi compétitif? Car ne l'oublions pas, Amazon a l'énorme avantage d'être une société plus que connue, à l'architecture ayant une scalabilité éprouvée, ce qui lui donne déjà une sacré longueur d'avance.

De plus, Rackspace joue la carte de la transparence en affichant clairement les problèmes rencontrés pour le lancement de CloudFS sur le blog officiel, sans forcément que les solutions soient déjà mises en oeuvre. Je ne suis pas sûr que cela joue énormément en leur faveur.