Exotech.biz

Web, Technology & life by Bastien Labelle

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

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!

Un service peut-il survivre seul?

Comme on peut le constater depuis ces derniers mois voir années, les services (j'entends par service une API) florissent à travers la toile. Les services web sont les coeurs de nos applications web actuelles. En effet, ils sont partout et sont très utiles. Grâce à eux, il est possible par exemple d'utiliser Twitter sur le site web, via IM ou encore via un client tiers tel que twhirl. En balayant un peu plus large, un blog dispose en quelque sorte d'un service grâce à son flux RSS qui permet au blog d'être consulté dans un agrégateur par exemple. Mais un service tout seul est-il viable?

API Diagram

Il existe des services qui sont payants. Ces services, comme Amazon S3 ou encore CloudFS, sont des services pay as you consume, ce qui veut dire que l'on paye selon le traffic que nous échangeons avec ce service. Les deux exemples cités permettent par exemple de bénéficier d'espace disque. Un autre exemple peut être l'API de Google Maps qui est payante pour les entreprises, au bénéfice entre autres d'un Google Maps vierge de toute publicité. Ces services sont donc rentables, à condition évidemment de trouver un tarif adéquat.

Mais les principaux services sont ceux qui sont gratuits. C'est le cas de Twitter, cité plus haut, mais aussi de la plupart des applications sociales comme Pownce, Jaiku, etc. Les applications web mainstream ne sont pas en manque, on le voit avec Facebook ou encore Flickr. Un service permet ici une multiplication des clients, mais aussi de créer des mashups entre services qui peuvent devenir très intéressants, comme par exemple Flickr Vision, qui permet de visualiser des photos géolocalisées sur une carte issue de l'API Google Maps.

Revenons à ma problématique, à savoir la viabilité de ces services. Vous aurez noté que chaque service gratuit que j'ai pu citer est toujours associé à un nom d'une application web plus ou moins connue. Celà implique que le service est toujours associé au nom d'une application web.

Néanmoins, j'ai pu observer récemment l'arrivée de nouveaux services web qui n'ont pas de site web qui les exploitent. Il semblerait que ce soit la voie que prend Yahoo, avec FireEagle pour la géolocalisation, ou encore Internet Location Platform, l'API de recherche de lieux et d'adresses. Mais Yahoo n'est pas seul, Reuters semble aussi emprunter la même voie avec son API sémantique OpenCalais.

Ces services présentent des avantages certains en termes d'exploitation, permettent de décentraliser des données tout en gardant une stabilité assurée car un fournisseur de services tel que Yahoo bénéficie évidemment d'une architecture testée et approuvée. Mais quid de la monétisation? Bien sûr, peut-être que pour un gros comme Yahoo, les services proposés sont rentabilisés via d'autres fonctionnalités du portail (Même si ces derniers temps chez Yahoo, c'est pas la grande joie), mais pour un service qui naitrait seul, il n'y a à mon avis aucun espoir de monétisation.

Les services sont bel et bien l'avenir de nos applications, à n'en pas douter, mais ne sont à mon avis pas une priorité, dans le sens où ils ne sont pas forcément monétisables. Ils sont essentiels en  termes d'architecture technique, mais le gros des efforts doit être fait au niveau de la première application qui exploitera ce service, car c'est elle qui sera monétisable. Facebook ne serait rien sans son API, et pourtant, son API seule n'aurait jamais connu un tel essor sans le site web qu'est Facebook. Un service seul est donc voué à l'échec, c'est d'ailleurs ce que je prédis pour les quelques uns que j'ai pu citer. A moins que quelqu'un trouve une idée révolutionnaire de monétisation d'un service gratuit, mais j'en doute...