Test de Google App Engine
Google App Engine est un projet de Google qui consiste à faire fonctionner des applications sur l'infrastructure de Google. Il est ainsi possible de réaliser des applications Web qui ne craignent pas de grosses charges.
Avec le développement de Perf-o-meter (voir l'annonce sur Linux Certif) j'ai pu tester l'environnement de Google App Engine. Cet article retrace les bonnes et mauvaises surprises que réservent App Engine par rapport au développement Web classique.
Scalabilité VS Vitesse
Puisque les applications fonctionnent sur les serveurs de Google, on pourrait s'attendre à ce qu'elles soient particulièrement rapide. À la sortie de App Engine, on pouvait d'ailleur constater des temps de réponses excellent.
En réalité, App Engine est incroyablement lent en comparaison avec les solutions classique. Par exemple, une page simple de Linux Certif est rendue avec Django + Postgresql en 30 millisecondes, sur App Engine, la même page prend entre 131ms et 502ms. Les serveurs sont évidemment différent, mais cela s'explique aussi par les fondations sur lesquels est bati l'infrastructure de App Engine.
App Engine n'est donc pas rapide, mais il est scalable (il tient la mise à l'échelle). Les éléments de App Engine (infrastructure et base de données) sont conçu et assemblés de tel façon qu'ils peuvent être distribués sur un parc de serveur, et c'est exactement ce que propose Google. Ainsi, plus la charge augmente, plus il y a de serveurs sont impliqués et le temps de réponse n'augmente pas de façon trop importante.
Webapp framework
App engine est compatible avec WSGI, ce qui permet d'y faire tourner à peut prêt n'importe quoi (les frameworks trop lié à SQL posent problème car App Engine ne propose pas SQL). Django est fourni par défaut (version 0.96) mais il est possible d'utiliser un autre framework ou une autre version de Django (pour outrepasser la limite des 1000 fichiers, utilisez zipserve pour charger le framework à partir d'un zip).
Google fournit aussi un mini-framework web nommé "Webapp framework". Personnellement, j'ai trouvé ce "framewok" catastrophique. Les seules choses que gère ce framework sont les objets de requêtes et de réponses, et l'API de ces objets est peut pratique.
Je pense que "Webapp framework" a été introduit pour deux raisons. La première est qu'il fallait bien fournir un moyen d'utiliser App Engine "out of the box", pour que les développeurs puissent l'essayer. La seconde est que Google a sans doute cherché à introduire une API indépendante du language, et on imagine très bien que Webapp framework soit porté sur Java. Mais finalement Webapp framework est trop pauvre par rapport aux autres outils disponible en Python.
Datastore
Puisque App Engine est destiné à être scalable, Google s'est passé de SQL pour utiliser sa propre base de donnée: Big Table. Big Table à l'avantage d'être conçu pour être distribué sur un cluster et a les propriétés requises pour être scalable. Ce type de base de donnée est utilisé par de nombreux projets de Google. Dans App Engine, la base de donnée Big Table s'appelle le Datastore.
Le Datastore de App Engine est vraiment très simple de conception. Il suffit de créer un modèle des données en Python pour avoir une table dans le Datastore. Pour le colonne, on retrouve le types classique des bases de données.
Par rapport aux bases de données SQL, Datastore apporte aussi une souplesse intéressante. Ajouter des colonnes à une table se fait naturellement, les index sont générés automatiquement à partir des requêtes effectués en développement, l'héritage est géré naturellement, etc.
Hélas, en dehors de ces spécification idyllique, le Datastore est la source de nombreux problèmes. L'API est bien trop peu puissante, il faut écrire une grande quatité de code pour assurer la consistance des données, et on finit par se demander sans arrêt pourquoi on doit réinventer la roue. Par exemple, les types de données ne proposent pas d'assurer l'unicité sur une table, si ont veut créer un champ unique, il faut le coder à la main.
L'autre point qui rend le Datastore peut pratique est l'absence de vrai transaction. Les transactions sur le Datastore ne peuvent réaliser que des opérations très basiques, et les entités impliqués doivent avoir été groupés à leur création. Les propriétés assurés sont incroyablement faible par rapport à la sécurté qu'on a sur les transactions de PostgreSQL ou Oracle. On se rend compte à quel point les transactions sont importantes quand celles-ci nous sont enlevées.
Déploiement
Pour déployer une application, il suffit d'utiliser un petit script qui va uploader l'ensemble de l'application sur les serveurs de Google.
Il est possible de donner un numéro différent à chaque version du code, ce qui est particulièrement intéressant pour le déploiement. Par exemple, si vous venez de déployer la version X, la page d'administration de App Engine affichera la version courante et la version X. Pour passer à la version X, il suffit de la selectionner dans l'interface d'administration. Si un problème devait apparaître avec cette version, App Engine a gardé la version précédente et il suffit de revenir à celle-ci.
Ce mécanisme permet de revenir rapidement à une version fonctionnelle en cas de bugs (pour autant que le modèle de donnée n'ai pas changé d'une version à l'autre). De plus, ce type de déploiement évite tout problème de condition de course (un fichier pas encore mis à jour qui appellerait une fonction d'un fichier déjà mis à jour).
Conclusion
Globalement, Google App Engine est intéressant, mais aussi décevant.
Coté intéressant nous avons un service gratuit et naturellement scalable. Pouvoir offrir une application à des millions d'utilisateurs est normalement une tâche difficile et coûteuse. Avec App Engine, cela devient facile par la conception même du système, et c'est gratuit.
Néanmoins on peut reprocher à App Engine son manque de sérieux. Le service n'est pas aussi stable qu'on voudrait (bug intermitants, bug au déploiement, grande variance de la latence, etc). Cela est évidemment dû à la jeunesse du service, et Google ne cache pas que App Engine n'est pas encore prêt pour des applications importantes (le service est une "preview").
Du point de vue programmation, il est possible d'utiliser des framework web éprouvés ce qui donne immédiatement tout les outils nécessaire pour réaliser de grands projets. Néanmoins, les problèmes du Datastore sont une perpétuelles perte de temps et il y a vraiment des progrès nécessaire et de la documentation à écrire.
Un dernier point qui mérite l'attention, est de savoir si oui ou non nous sommes prêt à donner notre code et nos données à Google. Un projet créé sur App Engine n'offre aucune alternative pour plus tard. Les données du Datastore sont très difficilement récupérable et elles sont sujettes au droit des États-unis.

