mercredi, juin 4 2008, 07:30
Quelles solutions pour la scalabilité des API?
Par Bastien - Web - Lien permanent
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 
Contact
2 commentaires
Je partage cet avis. La répartition de charge des serveurs est une technique qui a fait ses preuves, je pense par exemple au load balancing.
Néanmois, je trouve cette technique trop souvent limité par le contexte contractuel qui lie l'éditeur et son hébergeur, les limites ne sont plus physiques, mais simplement commerciales. Dans le web actuel, je trouve donc absurde de voir une application web ne plus répondre simplement parce que le contrat dit qu'on a le droit à tant de charge et pas plus.
Cela n'est donc pas meilleure façon de donner de la scalabilité. Je me répête souvent en disant que Google avait compris cela dès le départ. Imaginer une architecture répartie et décentralisée géographiquement à largement contribuer à son succès.
Les plate-formes de services et le cloud computing sont donc les techniques incontournables de demain pour fournir une scalabilité de qualité aux applications.
Ma théorie est simple, et j'ai pu la tester à de nombreuses reprise dans le cadre professionnel : le temps passé à la définition d'une bonne architecture évolutive (en phase préalable d'un projet web), est inversement proportionnel au temps qu'il faudra passer pour faire évoluer cette architecture lorsque ce projet atteindra un seuil critique.