Exotech.biz

Web, Technology & life by Bastien Labelle

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

Keyword - Platform as a Service

Fil des billets Fil des commentaires

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.