Google AppEngine
Lundi 14 avril 2008 à 17 h 34
Le 8 Avril dernier, Google a lancé son nouveau service, Google AppEngine. Ce service a pour but de vous proposer une solution d'hébergement pour vos applications web. L'avantage d'AppEngine se situe au niveau de la scalabilité (capacité d'un système à évoluer en puissance) de votre architecture web. Pour que vous compreniez mieux, voici un petit exemple. Imaginez que vous développiez une petite application web dans votre coin. Vous êtes une dizaine de personne à vous en servir et vous avez donc un serveur qui est calibré pour ce nombre d'utilisateurs. Du jour au lendemain, un site populaire fait une news sur votre système, ou votre site est "diggué" et donc par conséquent le trafic augmente brutalement. Votre serveur va se retrouver dans les choux et les utilisateurs ne manqueront pas de lâcher un "bouh c'est nul ça marche pas de toute façon". Avec AppEngine, votre architecture web s'adapte à vos besoins (à votre trafic donc), votre serveur devrait donc tenir la charge sans soucis.
Voilà pour la théorie, en pratique, le service vient d'être lancé et il est encore très limité, la partie payante du service n'a pas encore été dévoilé. Pour le moment chaque développeur bénéficie de 500Mo de stockage pour son application et de 5 millions de pages vues par mois. Le dépassement de ces limites entraînera une charge financière pour le développeur mais pour le moment cela bloque juste l'accès à l'application. Je ne m'attarderais donc pas sur ce point. Je vais plutôt vous parler du coté technique.
Un des premiers points négatif tombe directement. Un seul langage supporté (pour le moment). Le Python. Les développeurs PHP, RoR et autres sont donc dans l'impossibilité de déposer leurs applications existantes. Il en est de même pour le système de base de données. Pas de MySQL ou autres, un seul système, BigTable, système interne créé par Google pour leur besoin. On est donc dans l'obligation de se mettre au Python si l'on souhaite créer son application web, forcement l'accessibilité aux services en est réduite. On a donc un premier frein qui va rebuter pas mal de développeur malgré le fait que le Python soit un langage assez simple à comprendre et à utiliser.
A l'ouverture de ce service, je n'ai pas pu récupérer une des 10000 premières invitations. Je me suis donc contenter de récupérer le SDK AppEngine qui permet de travailler en local. Comme d'habitude, Google fait bien les choses puisqu'une doc complète et des tutoriaux viennent illustrer le SDK et ses quelques APIs. On se retrouve très vite avec un "Hello World" qui tourne sur son serveur local. Le principe est très simple. On dispose de deux exécutables pour uploader sur l'AppEngine ainsi que pour tester en local en lançant un serveur web très rapidement.
Après avoir testé un peu plus en profondeur de mon côté, voilà ce que l'on peut reprocher à l'AppEngine :
* Les timezones : Toutes les dates et heures sont basées sur l'heure UTC. Par conséquent il faut insérer des traitements supplémentaires pour recaler les dates et heures au timezone français par exemple. C’est un traitement qui alourdit le temps d’exécution.
* Backup de BDD : Il n'est pas possible à ma connaissance de récupérer un back-up de sa base de données en ligne. On ne peut donc pas non plus faire des traitements de masses sur sa base, si par exemple on souhaite modifier la structure ou faire un import de masse sans passer par l'application web.
* Exécution de tache à heure fixe (CRON par exemple) : La encore on ne peut pas programmer des traitements à heure fixe. Bon ce n'est pas un souci pour la majorité des gens et ça n'est pas dispo' sur la majorité des serveurs web de base non plus.
* Une BDD un peu lente : Quand on commence à pousser un peu niveau requêtes/analyses sur la base (récupérer plus de 2000 lignes par exemple). On se rend compte que BigTable galère un peu et c'est bien dommage.
* Gestion des données en base complexe : Les IDs de lignes ne sont pas accessibles, on est obligé de récupérer l'id après un insert pour ensuite mettre à jour sa colonne perso ID avec le même. Ce qui fait qu'on se retrouve avec deux colonnes représentant la même information, une accessible seulement par BigTable et une autre identique fait par nos soins. D'un fait général, s'aventurer vers une base de données avancée me parait dès lors très complexe.
Mais il ne faut pas oublier que l'AppEngine est tout jeune et comme tout produit Google il est voué à évoluer très rapidement. Les développeurs parlent déjà de supporter plus de langages (ce qui n’est pas forcement une bonne nouvelle, je préfère personnellement cent fois le Python au PHP). Il n'est pas destiné à n'importe qui, mais il offre quelques avantages non négligeables. Comme par exemple l'intégration du SSO Google via l'API. C'est à dire que l'utilisateur s'identifiera avec son compte Google pour se loguer à votre application, en contrepartie vous accéderez à son email, login et autres infos du compte (pas tout bien entendu) alors que vous auriez du coder tout ça -compte et sa gestion- par vous même auparavant.
Il faut donc laisser du temps à l'AppEngine pour murir un peu. Mais nul doute que le produit est intéressant, en particulier si son intégration à Google Apps est possible.
Et vous, vous avez testé ? Ça vous inspire quoi ? Ça vous passe au dessus du cigare ?
Voilà pour la théorie, en pratique, le service vient d'être lancé et il est encore très limité, la partie payante du service n'a pas encore été dévoilé. Pour le moment chaque développeur bénéficie de 500Mo de stockage pour son application et de 5 millions de pages vues par mois. Le dépassement de ces limites entraînera une charge financière pour le développeur mais pour le moment cela bloque juste l'accès à l'application. Je ne m'attarderais donc pas sur ce point. Je vais plutôt vous parler du coté technique.
Un des premiers points négatif tombe directement. Un seul langage supporté (pour le moment). Le Python. Les développeurs PHP, RoR et autres sont donc dans l'impossibilité de déposer leurs applications existantes. Il en est de même pour le système de base de données. Pas de MySQL ou autres, un seul système, BigTable, système interne créé par Google pour leur besoin. On est donc dans l'obligation de se mettre au Python si l'on souhaite créer son application web, forcement l'accessibilité aux services en est réduite. On a donc un premier frein qui va rebuter pas mal de développeur malgré le fait que le Python soit un langage assez simple à comprendre et à utiliser.
A l'ouverture de ce service, je n'ai pas pu récupérer une des 10000 premières invitations. Je me suis donc contenter de récupérer le SDK AppEngine qui permet de travailler en local. Comme d'habitude, Google fait bien les choses puisqu'une doc complète et des tutoriaux viennent illustrer le SDK et ses quelques APIs. On se retrouve très vite avec un "Hello World" qui tourne sur son serveur local. Le principe est très simple. On dispose de deux exécutables pour uploader sur l'AppEngine ainsi que pour tester en local en lançant un serveur web très rapidement.
Après avoir testé un peu plus en profondeur de mon côté, voilà ce que l'on peut reprocher à l'AppEngine :
* Les timezones : Toutes les dates et heures sont basées sur l'heure UTC. Par conséquent il faut insérer des traitements supplémentaires pour recaler les dates et heures au timezone français par exemple. C’est un traitement qui alourdit le temps d’exécution.
* Backup de BDD : Il n'est pas possible à ma connaissance de récupérer un back-up de sa base de données en ligne. On ne peut donc pas non plus faire des traitements de masses sur sa base, si par exemple on souhaite modifier la structure ou faire un import de masse sans passer par l'application web.
* Exécution de tache à heure fixe (CRON par exemple) : La encore on ne peut pas programmer des traitements à heure fixe. Bon ce n'est pas un souci pour la majorité des gens et ça n'est pas dispo' sur la majorité des serveurs web de base non plus.
* Une BDD un peu lente : Quand on commence à pousser un peu niveau requêtes/analyses sur la base (récupérer plus de 2000 lignes par exemple). On se rend compte que BigTable galère un peu et c'est bien dommage.
* Gestion des données en base complexe : Les IDs de lignes ne sont pas accessibles, on est obligé de récupérer l'id après un insert pour ensuite mettre à jour sa colonne perso ID avec le même. Ce qui fait qu'on se retrouve avec deux colonnes représentant la même information, une accessible seulement par BigTable et une autre identique fait par nos soins. D'un fait général, s'aventurer vers une base de données avancée me parait dès lors très complexe.
Mais il ne faut pas oublier que l'AppEngine est tout jeune et comme tout produit Google il est voué à évoluer très rapidement. Les développeurs parlent déjà de supporter plus de langages (ce qui n’est pas forcement une bonne nouvelle, je préfère personnellement cent fois le Python au PHP). Il n'est pas destiné à n'importe qui, mais il offre quelques avantages non négligeables. Comme par exemple l'intégration du SSO Google via l'API. C'est à dire que l'utilisateur s'identifiera avec son compte Google pour se loguer à votre application, en contrepartie vous accéderez à son email, login et autres infos du compte (pas tout bien entendu) alors que vous auriez du coder tout ça -compte et sa gestion- par vous même auparavant.
Il faut donc laisser du temps à l'AppEngine pour murir un peu. Mais nul doute que le produit est intéressant, en particulier si son intégration à Google Apps est possible.
Et vous, vous avez testé ? Ça vous inspire quoi ? Ça vous passe au dessus du cigare ?
C'est pas un mal de faire du dev web en Python c'est juste que la plus part des serveurs proposant une hebergement ne proposent pas python.
On pourra regreter l'absence de SGBD comme Mysql ou Postgres, c'est fort dommage.
What frameworks does Google App Engine Support?
Google App Engine allows most python web frameworks to be uploaded with your application. These web frameworks should need little or no modification to work with our system. For your convenience, Django v0.96.1 is included with the Google App Engine SDK.
Pour ceux qui est du SGBD. On voit bien que pour le lancement ils se sont contenté de pousser les technos qu'ils utilisent en interne. Soit Python/BigTable. On peut imaginer par la suite qu'ils proposent d'autres langages et d'autres SGBD. Mais bon, rien n'est sur.
Et sinon en temps que développeur amateur, j'utilise beaucoup PHP, quels sont les avantages du Python ?
Je trouve ça vraiment bien ce que fais Google avec les multiples API qu'ils sortent, qui sont bien léchées et bien documentées.
Mais se pose le problème du stockage des données. Stocker toutes ses données sur Google ça me branche pas trop... Je parle d'un point de vue professionnel. Sinon pour un particulier c'est tout bon.
edit : les avantages de Python? Mon opinion : la simplicité, la rapidité de codage, permet de coder des applis webs, des applis graphiques, des scripts... , un beau code propre, des doctests etc...
C'est bien beau un SDK mais l'amont n'est pas libre je suppose. Au prix d'un hergement mutualisé, la richesse des API disponibles quels que soit le langage (PEAR, CPAN & co) personnellement je ne vois pas du tout l'interêt de se formater Google.
Edit: Python c'est très bien, je le critique pas du tout ce choix de langage. Mais bon leur API, leur SGBD, leur services.
Sinon rien à voir mais je n'ai pas réagit à ton précédant billet, que je n'ai pas vu. Je n'utilise plus que Mootools comme lib JS, je trouve ça vraiment élégant, complet et intelligent. La stable 1.2 est annoncée pour les jours qui viennent.
Pour les avantages, voilà deux trois raisons en anglais :
Highly adaptable - You need a language that is very flexible, so you can adapt your tools during development
Rapid development - For new and experienced developers - The market moves very very quick; you want to be able to keep up with it. If it takes two years for you to respond to something that is needed today, you're behind the curve.
Easy to maintain - most important point in Greg's view - You can come back a year later, look at that code, and understand what is going on.
@Crazralfrill: Le stockage des données chez Google, c'est toujours (et c'est normal) l'argument qui revient en premier quand on parle des services Google aux entreprises. Il faut savoir que Google ne plaisante pas avec ça, je ne vais pas m'étaler à part si ça vous intéresse vraiment.
@mst : oui je suis comme toi, MooTools est mon préféré.
@DjMerguez : Exactement! Vu que BigTable est utilisé en interne, le système est surement bien au point en terme de réplication. Dans les prochains jours, j'ai bien l'intention de mettre un peu à l'épreuve BigTable pour voir ce qu'il a dans le ventre!
Ben ouais tiens, perso ça m'intéresse :)
edit : très très chouette css au passage
Question très conne, mais en Python, on peut intégrer du JavaScript comme en PHP (vu que c'est exécuté côté client) ?
@Conradson : Merci pour le commentaire, pour te répondre je vais être un peu long mais essayer d'être clair!
D'abord une petite précision, le PHP comme le Python est un langage qui est interprété (exécuté si tu veux) côté serveur.
Lorsque l'on développe il est toujours bien de respecter quelques modèles. La majorité des gens qui codent en PHP ne code pas correctement (à mon sens). En effet la page PHP contiendra à la fois du code HTML/Javascript destiné à être exécuté coté client, mais aussi du code PHP qui sera lui exécuté coté serveur avant d'être envoyé au client. On se retrouve avec une page mélangeant les traitements et le rendu.
Pour coder plus proprement il est préférable de coder selon un modèle MVC (pour Modèle, Vue, Controleur). En gros, qu'est ce que ça signifie ? Tu as ta page PHP d'un coté qui contient tout les traitements des données que tu souhaites afficher. Et de l'autre coté, tu as ta page HTML qui contient le template du rendu que tu souhaites afficher. Tu sépares donc les traitements du rendu.
Pour prendre un exemple concret, quand je code en PHP, j'ai d'un coté mon fichier index.php et de l'autre index.html. Dans mon fichier index.html dès que je dois afficher du contenu généré par mon fichier PHP je met des "variables" du genre %NOM%. Et dans mon fichier PHP après avoir effectué tout mes traitements je charge le fichier index.html et je remplace mes variables comme %NOM% par la donnée que j'ai traité précédemment.
Comme tu peux le voir dans mon exemple, ce n'est pas du tout obligatoire, c'est une habitude et un réflexe. Mais tout est fait à la main.
Dans le cadre de l'AppEngine, il existe des librairies (Django pour l'AppEngine) qui gèrent tout ça mais le fonctionnement est identique.
Dans mon code Python je calcule mes données que je stock dans un tableau destiné pour mon template index.html. Dans index.html j'affiche les données calculées avec des balises du type {{ maVariable }}. Et bien sur pour en venir à ta question sur le javascript, tu l'auras compris, ton template HTML peut contenir tout le Javascript que tu souhaites.
Voilà j'ai préféré reprendre d'assez haut pour expliquer clairement mais je suis pas sur d'être très clair au final. Dis moi si tu ne saisis pas un truc et je te posterais un exemple plus concret à base de code!
Pour ce qui est du milieu de l'entreprise, il y a des contrats qui posent clairement les choses. Une entreprise n'irait pas s'engager avec Google si elle n'avait pas de sécurité.
J'en ferais un billet bientôt et on aura l'occasion d'en discuter!
J'attends ton prochain billet.
Ha si quand même, j'ai eu l'occasion de travailler avec Python, sa syntaxe est tout simplement horrible et ultra rigide. Tu mets une tabulation là où il faut pas: t'es mort. Supayr ce concept dis donc.
De deux, modère ton langage sinon je supprimerais tes message vu que je ne peux pas les modifier moi même.
De trois, si tu es habitué à mal coder, c'est sur que le respect d'une syntaxe imposé par Python oblige à faire un petit effort. Mais cet effort est nécessaire pour une meilleure reprise du code par la suite.
(c'est vrai que c'est plus compliqué de coder n'importe comment avec python qu'avec php par exemple)
Article intéressant, et, j'aime beaucoup ta css.
J'attends ton prochain article.