David Larlet : artisan, contributeur et citoyen.


Archives du site biologeek.com. Publications récentes.

Google App Engine : avantages et inconvénients

vignette

Vous n'avez pas pu passer à côté de l'information aujourd'hui, Google a lancé son nuage en orbite. Réactions à chaud froid (j'ai pas encore d'invitation) sur le bon et le moins bon. Vous avez eu peur du GWeb ? Attendez-vous à pire.

Google App Engine ?

Rapide séance de rattrapage pour ceux qui bossent trop. Ce nouveau service vous permet de mettre en ligne des sites dynamiques développés avec Python sans vous préoccuper de l'hébergement. Ce qui pouvait auparavant prendre un bon moment se fait maintenant en une poignée de secondes. C'est presque plus simple qu'un déploiement de site en PHP qui demande l'utilisation d'un client FTP.

Contrairement à Amazon et ses services modulaires (S3, EC2, SQS, etc), Google a décidé de fournir une offre tout compris et gratuite pour les sites de tailles modestes (les tarifs si on dépasse la limite ne sont pas encore connus).

Google App Engine

C'est un grand jour pour...

Django

Même si les autres frameworks sont évoqués, le grand gagnant de la journée est certainement Django qui a plus que jamais le vent en poupe. <autosatisfaction>Je ne vous cache pas qu'il est assez encourageant de miser sur les mêmes outils que Google</autosatisfaction>. J'ai l'impression (mais je suis trop impliqué donc ça reste vraiment une impression) que le soufflet RoR est en train de retomber et s'il doit y avoir une date clé à cette inversion de tendance, c'est celle-ci.

La documentation si vous connaissez Django est très claire et détaillée, prise en main immédiate et vous pouvez même installer la dernière version de Django. Rien à redire à ce niveau. Il est à noter que le système de stockage de données est différents donc les applications existantes (notamment l'administration) ne fonctionneront pas sans de sérieuses modifications.

Python

Avec l'arrivée de Guido chez Google il y a quelques temps, on pouvait s'attendre à quelque chose. Mais là l'impact est vraiment fort : on ne propose que Python (pour l'instant) car on croit en ce langage que l'on utilise. Sous-entendu : si vous apprenez Python on va probablement bien s'entendre... c'est un énorme coup de pouce !

Il faut bien sûr pondérer l'ensemble des commentaires négatifs que l'on peut lire un peu partout avec le nombre de développeurs web qui ont aujourd'hui entrepris de se mettre à Django, et par extension à Python.

REST

Vous ne pouvez communiquer avec l'extérieur qu'à travers une API REST et la base de donnée BigTable est accessible en REST aussi, du moins c'est ce que le nom des fonctions laisse présager.

Les microprojets vaporwares

Vous voulez faire un twitter en une nuit ? Maintenant ça ne prend plus que quelques heures, de l'idée à la mise en ligne.

C'est un jour noir pour...

Les petits hébergeurs

Qui misaient sur Django et qui vont devoir revoir leurs choix et leur tarification. Google App Engine va devenir la page perso de Free sur laquelle chacun s'est essayé à PHP, pour survivre il va falloir se diversifier et offrir des services plus intéressants (App Engine reste quand même assez restrictif).

OpenID

C'est prévisible, OpenID est loin d'être la priorité d'une entreprise dont le business model est l'information et même si une application est apparue très rapidement pour palier à ce manque, cet « oubli » est un choix délibéré, que l'on ne s'y trompe pas. L'alternative c'est d'utiliser les comptes Google, on ne fait pas mieux en termes de décentralisation.

La confidentialité de vos données

J'ai déjà parlé du grand complot mondial, tout ça, mais il faut quand même garder à l'esprit :

  • que vous pouvez maintenant saisir des informations sur un site tiers qui sont ensuite stockées chez Google ;
  • que Google est une entreprise devant se plier à la loi américaine en ce qui concerne la confidentialité des données ;
  • que vous fournissez le code source de vos applications à Google, imaginez si Facebook était hébergé sur App Engine :-).

Au final, je n'arrive pas du tout à cerner la cible de ce service. Les sites qui atteindraient la limite du paiement ont besoin d'avoir davantage de liberté au niveau de l'infrastructure et Google n'a pas (encore) assez de services pour être exhaustif à ce niveau. 95% des titulaires d'un compte ne vont pas aller plus loin qu'un « Hello world! ». Restent donc les idées rapidement mises en ligne sur App Engine (plus Concept que App finalement) et qui se retrouvent « piégées » lorsqu'elles atteignent une popularité financièrement intéressante pour Google (aucune mention de backup évoquée dans la documentation que j'ai lu). Ça fait léger.

Je trouve la stratégie (apparente) de Google de plus en plus désordonnée avec une multitude de services isolés alors qu'il y aurait vraiment des choses intéressantes à faire en termes de cohérence utile à l'utilisateur final vu la masse d'information qu'ils brassent. Auraient-ils atteint la taille critique qui transforme chaque Leonidas en Xerxès ?

[edit du lendemain] : ça n'a pas traîné, Yoan a déjà codé une alternative à App Engine reposant sur CouchDB. Très fort.

[edit du lundi] : la meilleure analyse que j'ai pu trouvé (en anglais) : Google App Engine: The good, the bad, and the ugly? (ironiquement c'est le titre que j'avais choisi pour ce billet au début :-)).

Articles peut-être en rapport


Commentaires

giz404 le 09/04/2008 :

J'avais entendu parler de Google App Engine, mais sans chercher à en savoir plus. Ton article met en lumière ce qui semble être une petite révolution dans le monde des applis web...

Pour en revenir à RoR qui "retombe comme un soufflet" : je pense que de nombreux programmeurs web se sont engagés là-dedans parce que c'était hype, et que tout semblait simple et dynamique (vive AJAX). En prenant du recul, on se rend compte que la force de RoR, c'est tout simplement d'être un framework. Et en reculant d'un pas de plus, on découvre qu'il existe pléthore de frameworks, dans des langages qu'on maitrise peut-être mieux que Ruby, d'où la montée de frameworks PHP, et l'effet "soufflet" pour RoR.
Cette parenthèse étant faite, il est clair que Google App Engine est un atout indéniable pour qui aimerait se lancer dans Django, puisqu'il résoud le problème de l'hébergement (qui selon moi représentait quand même le point faible de ce framework). Après, on a toutes les raisons d'être parano quand on voit que Google attaque sur deux fronts :
- pour tout le monde : Gmail, Google Docs, Google Desktop Search
- pour les gens du web : Analytics, webmaster tools, Google App Engine

Leur stratégie me semble assez claire : fidéliser les travaileurs du web par leurs excellents services, et devenir leader sur les web-applications (qui gèrent à présent le mode offline) pour s'imposer comme un acteur fondamental du desktop de demain (il suffit de voir certaines distribution Linux, qui reposent beaucoup sur ces webapps - gOS par exemple...)

En route vers le monopole donc...

Olivier G. le 09/04/2008 :

Je ne suis pas certain qu'il y ait une vraie stratégie commerciale derrière tout ça. Ils ont pour politique de laisser leurs développeurs travailler une journée par semaine sur des projets personnels, quelle intérêt cela aurait si ces projets ne voyaient après coup jamais le jour.

En revanche, il est probable qu'en terme de compétences, la résolutions des problèmes de scalabilité que va poser la montée en puissance de ce service va être très bénéfique à google...

Reste l'hypothèse de la conspiration mondiale, mais rappellons nous AT&T...

kib2 le 09/04/2008 :

Salut David,

Comme tu le dis, ce sont les petits hébergeurs qui vont trinquer.

Et aujourd'hui certains commencent à réagir : www.joyeur.com/2008/04/09...

N'oublions pas non plus que tous ces frameworks cachent la forêt, et qu'on ne comprendra pas grand chose à ce qui se passe réèlement dans une application Web si l'on a pas déjà bidouillé un peu avec cgi ou wsgi.

Google se pose dorénavant comme le Monsanto du Web.

Quelques petites lectures supplémentaires:

- valleywag.com/377603/goog...
- www.b-list.org/weblog/200...

Cyril le 09/04/2008 :

Je ne suis pas sûr que ce soit un jour noir pour les petits hébergeurs proposant Django. En l'état, Google App Engine est une solution assez restrictive : il faut utiliser le framework de Google ou un Django modifié et limité. Très sympa pour s'initier ou héberger des petits projets, je doute que la plupart des développeurs se mettent à écrire leurs applis Web spécifiquement pour Google, avec tous les risques que cela comporte.

Au contraire, je pense que ça peut donner un sacré coup de boost à Django (et Python) qui ne peut être que bénéfique aux hébergeurs traditionnels, lesquels proposeront toujours un service plus large de services (SSH, vraies bases de données, etc.).

kib2 le 09/04/2008 :

Cyril :

Content de voir qu'un hébergeur ne se sente pas visé par le mastodonte, d'autant plus que vos services sont impeccables.

Pouvoir communiquer avec vous rapidement et surtout en Français est une aide précieuse.

David, biologeek le 09/04/2008 :

@giz404 : lorsque je parle de manque de cohérence c'est entre les applications, les panels de app engine et analytics pourraient être groupés, il pourrait y avoir une intégration de feedburner pour proposer des flux rss avec app engine, YouTube est bien intégré pour présenter leur produits mais on ne retrouve pas la possibilité de l'intégrer à Google Code, etc.

Après l'objectif à long terme d'avoir une position monopolistique, je n'en doute pas ;-).

@Olivier G. :

> Ils ont pour politique de laisser leurs développeurs travailler une journée par semaine sur des projets personnels, quelle intérêt cela aurait si ces projets ne voyaient après coup jamais le jour.

Tu penses que App Engine a été créé sur ce temps ou que cette plateforme est avant tout destinée aux employés de Google pour qu'ils montrent leur travail ?

Sinon pour la scalabilité, je ne suis pas sûr que ce soit très utile, ils veulent aussi montrer l'intérêt de BigTable (un autre gagnant de la journée pourrait être CouchDB à ce sujet).

@kib2 : merci pour les liens.

@Cyril : je ne vais pas contredire un petit hébergeur là-dessus :-). Je pense même qu'il y a quelque chose à faire pour héberger des sites qui étaient destinés à App Engine avec un script d'export BigTable → import CouchDB...

Fabien le 09/04/2008 :

Je pense que un des points importants sera le prix lorsque le produit sortira de la version beta. Et comment il sera possible de faire "évoluer" les limitations. Par exemple pour faire un webmail avec gestion des pièces jointes, 500 Mo ça va vitre être insuffisant.

Et comme le disais Cyril, je pense que ça peut mettre en lumière Django et les hébergeur Django. J'ai quelques blogues que j'héberge sur mon serveur, et je préfère largement cette solution ou un hébergeur mutualisé que un compte Google App Engine car la montée en charge d'un blog n'est pas trop un problème et je préfère trouver un package de blog Django et l'installer que de devoir en développer un spécifiquement à AppEngine.

Mais pour des services web, je pense que ça peut être très interressant.

Mouette le 09/04/2008 :

Et si la seule stratégie derrière tout ça était que chaque internaute finisse par avoir un Google Account?

Damien B le 09/04/2008 :

"L'alternative c'est d'utiliser les comptes Google, on ne fait pas mieux en termes de décentralisation."

Ha. Donc en terme de décentralisation, le mieux c'est d'avoir un compte unique centralisé chez Google, plutôt que de l'avoir sur un serveur OpenID, qu'on peut installer où on veut en 5 minutes ? (D'ailleurs, peut-on installer DjangoID sur le Django de App Engine). Et n'oubliez pas, le mieux pour décentraliser vos données précieuses, c'est de tout stocker uniquement sur une disquette 5"1/4, chez vous. D'ailleurs David fait comme ça, quand il livre un client, il lui met le livrable à disposition quelque part, et il efface TOUTES les copies : comme ça, il est sûr que c'est parfaitement décentralisé :-D

David, biologeek le 09/04/2008 :

@Mouette : c'est une possibilité oui.

@Damien B. : j'espère que tu auras noté le second degré de la phrase citée. (Oui on peut installer la lib openid python). Ma stratégie de backup dépend de l'importance ET de la confidentialité des données. Selon les accords passés je peux me retrouver dans l'illégalité si je conserve une disquette ;-).

Philippe le 10/04/2008 :

Concernant RoR, il y a, me semble t'il, une période de flottement. Mais l'avenir dira comment cela évolue.

Pour Google, je suis d'accord que cela semble partir dans tout les sens et je suis assez septique sur la confidentialité pour une entreprise qui utiliserait se système. Mais comme toujours cela va faire avancer les choses et il y a fort à parier que des offres alternatives sortiront dans les prochains mois.

Frédéric Sidler le 10/04/2008 :

Avec BigTable ou HyperTable son alternative open source, il n'y a pas besoin de backup. Google assure que tes données sont stockées au minimum à trois endroits différents. C'est également ce que propose S3, la solution de stockage d'Amazon.

Pour l'utilité d'un tel service, je vois simplement que Google est en train de proposer une plate-forme de développement web comme Microsoft l'avait fait pour sa plate-forme de développement Windows.

Apple est en train de faire de même avec son SDK pour l'Iphone.

Je ne serai pas étonné que App Engine n'ait un intérêt pour les gens qui cherchent à développer des services web mobile pour Android.

Le mieux finalement, c'est de garder un oeil ouvert ;-)

Amélie le 11/04/2008 :

salut à tous !

alors on a testé le fameux Google App Engine ;)
notre app est encore en beta mais si ça vous interesse de tester c'est par ici :

jamendogame.appspot.com/

c'est un petit jeu sympa de "quizz" musical.
le jeu est en relation avec le site jamendo.
une piste est jouée et un chrono se met en route, vous et votre adversaire devez taguer ce titre en un minimum de temps. le but est d'avoir un ou deux tags similaires avec votre partenaire.
vous aurez ensuite un récapitualtif des titres entendus et le lien pour les trouver sur jamendo.

c'est avec plaisir que j'accueillerai vos commentaires et suggestions !

David, biologeek le 11/04/2008 :

@Frédéric : je me suis mal exprimé, par backup je voulais dire aussi export, car pour l'instant une fois dans la solution on est pieds et poings liés.

@Amélie : jolie mise en application du social tagging. À terme ça va vraiment taguer les morceaux ou c'est juste pour voir ce que ça donne ?

Qu'est ce que vous avez utilisé en backend ? C'est le téléchargement vers mon client ou la récupération Jamendo -> App Engine qui prend du temps ?

Par ailleurs, Firebug me renvoie l'avertissement suivant avec Firefox 3b4 (le service reste utilisable) : L'utilisation de la fonction « getBoxObjectFor() » est déconseillée. Essayez d'utiliser la fonction « element.getBoundingClientRect() » si possible.

sylvinus le 11/04/2008 :

@david

non tous les calls à l'api jamendo sont faits depuis le javascript ; c'est nos serveurs de streaming qui rament un peu. niveau app engine, on a juste un gros dump de trackids. il faudra que ce soit dynamique dans le futur mais c'est pas fait encore

si tu veux regarder (et même contribuer!!) la source est dispo sur notre google code :)

a+ !

Linux le 14/04/2008 :

Je ne sais pas vous mais je trouve que Google n'a pas encore été assez loin avec app engine.

Je ne vois pas comment on va pouvoir intégrer des applications de différents projet et je pense que cela deviendra un besoin dans le court terme.

Ici on a qu'un langage et tout le monde va se ruer sur Django donc pas de problème. Mais quand Java va arriver pour écrire des applications, on voudra utiliser les projets existant avec les nouveaux site. On pourrait imaginer un forum Java complètement intégré dans un site Python. Des API un peu plus poussée auraient peut être pu gérer ce genre de besoin.

Pour le reste, je trouve ça chouette que Google se lance là dedans. Et je suis ravi qu'ils aient choisi Django :)

syntax_error le 16/04/2008 :

Tout cela est certainement très positif pour python et django, mais selon moi c'est très négatif pour l'évolution à long terme du web.

Au delà de ce nouveau service je fais allusion à tous les autres déjà existants: la tendance actuelle des compagnies web est de devenir un passage obligé, la rentabilité provenant de l'exploitation des informations liées aux connections. Ceci implique un certain degré d'enfermement: utilisation des comptes google pour le login, passage obligatoire par les APIs maison pour avoir accès à des données externes.

Ce modèle implique donc de garder les utilisateurs et les données bien au chaud derrière des barrières propriétaires. Or cela va totalement à l'encontre des principes du web sémantiques, qui propose des techniques pour accéder aux données de manière universelle via des formats ouverts et non des apis fermées.

Le grand perdant dans cet histoire est le web sémantique. Toutes les technologies existent aujourd'hui pour le mettre en oeuvre concrètement, seulement cela va à l'encontre des conditions de rentabilité economiques préconisées par les grandes compagnies qui font le web aujourdhui. Partant de là le web ouvert proposant des information richement qualifiées en libre accès restera anecdotique pour longtemps, les grands acteurs ayant tout intérêt à rester les deux pieds sur le frein, pour conserver leur pré-carré.

David, biologeek le 16/04/2008 :

@sylvinus : j'ai jeté un œil au code mais je n'ai malheureusement pas le temps de contribuer.

@Linux : pour l'instant Google App Engine est surtout destiné à des applications qui vont être créées spécifiquement pour cette plateforme, mais ils travaillent pour avoir une compatibilité totale avec Django et là ça va devenir tout de suite plus intéressant... code.google.com/p/google-...

@syntax_error : Amen. Je n'ai pas développé cette problématique mais merci de l'avoir énoncé aussi clairement, je partage tout à fait cet avis.

labadie le 06/05/2008 :

Dans 01Net, il y a un article sur Google App Engine, et ils soulèvent un point important: tu n'as aucune garantie sur la disponibilité de ton appli Google App Engine. Rien, pas 99% ou 90%, rien. Pareil pour Amazon et Facebook, d'ailleurs.
Si tu bases ta stratégie commerciale dessus et que ton site est HS pendant une semaine, tu fais quoi ?

David, biologeek le 11/05/2008 :

@labadie : remarque très pertinente, d'autant que ça arrive même avec des structures comme Amazon (cf. récente coupure de S3 avec une partie des services 2.0 down...)

William le 20/08/2008 :

On trouve de vraie perles sur Google App. Je suis récémment tombé sur Spy dont j'ai fait l'article http://fanurl.com/w qui n'aurait pas forcément vu le jour sans Google App. En tous cas, bien joué !

Damien B le 20/08/2008 :

"Je suis récémment tombé sur Spy qui n'aurait pas forcément vu le jour sans Google App."

Dans quelle mesure ?

Seb le 07/05/2009 :

Bonjour,

Belle présentation de GAE !

Pour info, pour celles et ceux qui ne seraient pas trés à l'aise avec l'anglais, j'ai mis à disposition une traduction française de la doc de Google App Engine ici:

http://www.gae-en-francais.fr

Seb.

France le 20/01/2011 :

Avec un peu de recul on a quand-même plus d'infos qu'avant, notamment sur les sauvegardes, la disponibilité (cf doc officielle de google mise à jour)