Exotech.biz

Je m'interrogeais il y a quelques temps sur la viabilité des services web gratuits. Avec le lancement de FireEagle cette nuit, et le lancement de BOSS, l'API de recherche de Yahoo il y a de cela quelques semaines, ma réflexion a eu le temps de mûrir un peu.

J'étais persuadé lors du dernier billet que de grandes sociétés telles que Yahoo pouvaient se permettre de lancer un service web en grande pompe sans se soucier de la contrepartie financière, le tout étant compensé par d'autres services fournis par l'entreprise, comme un moteur de recherche ou un webmail. Mais Yahoo est une société, et a pour but de faire de l'argent, et être rentable, et quid des start-ups qui ont beaucoup moins de moyens?

Comment donc monétiser un service web gratuit?

La première solution, à court terme, serait de monétiser indirectement l'API via la publicité. Il ne s'agit pas de faire de la publicité sur une autre partie du site, mais de donner un moyen pour l'application exploitant l'API de se monétiser. C'est d'ailleurs ce que semble faire Yahoo, qui devrait permettre d'intégrer un système de publicité afin que tout le monde soit gagnant (sauf peut-être les annonceurs, mais c'est une autre histoire).

La deuxième solution quant à elle viserait plutôt le long terme, et n'est rien d'autre que le rachat. En effet, fournir une API permet de gagner des parts de marchés en fournissant les données aux "concurrents". Prenons le cas de BOSS. Yahoo va gagner des parts de marché en fournissant une API de recherche exploitée par des mashups. Si l'un d'eux commence à devenir un concurrent sérieux ou vraiment innovant, alors il y a de fortes chances de voir une acquisition de la part de Yahoo.

La troisième possibilité vient quant à elle trouver une solution au problème récurrent des API, je veux bien entendu parler de la scalabilité. Le modèle est très connu, il s'agit du modèle Freemium. On en parle chez GigaOM récemment en évoquant une éventuelle solution pour Twitter, mais il me semble que Google table déjà sur ce modèle avec ses différentes API. Il s'agit de limiter les accès à une ressource, et de faire payer au delà de cette limite les gros consommateurs.

Voilà donc trois manières de monétiser une API. Il est encore trop tôt pour pouvoir dire que telle façon a plus souvent marché qu'une autre, mais la mode étant le pay as you consume, j'imagine volontiers que la troisième solution, basée sur le modèle freemium et la tarification en fonction de la consommation devrait s'imposer, les autres solutions n'étant peut-être pas adaptées à toutes les entreprises.

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.

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!

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.

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

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?

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...

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.

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.