Google App Engine
Laurent Caillette
Encore une fois Google assène une énorme claque avec App Engine, qui
va modifier durablement notre façon de penser la réalisation et
l'hébergement d'un service en ligne.
Google App, encore en version beta et disponible pour un petit nombre
de développeurs, offre un SDK et un hébergement pour des applications
Web. En-dessous de certains seuils (stockage, bande passante, cycles
CPU) par ailleurs confortables, c'est gratuit !
Un aspect majeur est la mise à disposition des infrastructures Google
pour la montée en charge : déploiement sur leur grid, APIs pour
accéder au Google File System et à la Big Table. En un clic de souris
on déploie sur un cluster à tolérance de panne avec des possibilités
de montée en charge virtuellement illimitées.
Pour l'instant, les applications se développent en Python mais les
infrastructures de déploiement ne dépendent pas du langage et l'équipe
d'App Engine promet d'en supporter d'autres. La nature interprétée de
Python offre un roundtrip très rapide lors du développement avec le
SDK qui émule l'environnement de déploiement : je sauve mon fichier en
local, je clique sur "refresh" dans mon browser et je vois ce que ça
donne, c'est magique. Quand je suis content je déploie ma nouvelle
version en lançant juste un script.
Le déploiement sur un cluster a évidemment nécessité la désactivation
de certaines primitives standard de Python : threads, accès au
filesystem, ouverture de sockets, etc. Mais les orientations les plus
fortes se retrouvent au niveau du système de persistance : plus de
base de donnée relationnelle mais une API de stockage basée sur les
fonctionnalités de la Big Table développée en interne par Google et
qui fonctionne sur des clusters de très grande taille.
La Datastore API supporte les transactions et un schéma avec des
contraintes sur les types. Les types sont par exemple des propriétés
ou des énumérations ou des listes. Une entité stockée peut référencer
une autre entité (la jointure s'effectue alors à la mimine). La
Datastore API offre également un mini-langage de requêtage, des clés
uniques, des index. Les exemples en Python sont impressionnants de
clarté.
Parmi les API liées aux infrastructures on note celle pour l'envoi de
mails, et celle pour accéder à des URL externes aux domaines Google.
Des frameworks Python viennent en standard (Django, YAML, logging...)
mais il est possible de déployer ceux de son choix. Pour l'instant
seules les requêtes HTTP GET et POST sont supportées. Il n'y a pas de
scheduler. Par contre rien ne s'oppose à des applications non-Web
(accédées par un client riche).
La console d'administration permet de choisir la version de
l'application déployée, de rediriger un nom de domaine existant, de
voir les URLs les plus requêtées, celles qui ont généré des erreurs,
ainsi que de requêter et d'éditer le contenu de la Big Table.
Il est facile de trouver à App Engine tout un tas de défauts. Python
n'est pas typé, la console d'administration a l'air très légère pour
fouiller dans les logs générés par des millions d'accès simultanés,
l'argument "pas de migration de données avec la Big Table" est
fallacieux, blablabla. Ce qui est important, c'est le niveau de
simplicité atteint pour masquer la plomberie de clustering derrière.
Même si l'objectif avoué de Google est de nous scotcher vingt heures
par jour devant nos écrans ils le font avec un talent monstre et
donnent de plus en plus *envie* de leur confier nos données les plus
critiques.
Pour l'instant la concurrence se limite à Amazon EC3, qui offre un
environnement beaucoup moins guidé : on a les mains libres face à un
tas de machines virtuelles où on installe tout ce qu'on veut, et on
tape dans leur système de stockage S3 qui n'offre ni schéma ni
transactions. Et il n'y a pas d'accès gratuit.
Même si certains contextes ne permettent pas de laisser sortir
l'information des murs de l'entreprise, les fournisseurs de solutions
J2EE (et toutes celles fonctionnellement équivalentes) se retrouvent
avec une pression monstrueuse en ce qui concerne la simplicité
d'accès. Maintenant que les bases conceptuelles sont posées, on peut
s'attendre à voir fleurir des solutions OSS reprenant les bonnes idées
de App Engine, tout comme Hadoop a repris nombre d'idées de
l'infrastructure Google (dont la Big Table avec HBase).
Même si App Engine ne s'adresse qu'à une gamme d'application assez
restreinte, sa seule existence doit nous faire reconsidérer la façon
de penser les mécanismes de persistance pour des environnements à
haute disponibilité. Qu'importe depuis combien de temps le SGBDR est
potentiellement mort, ce qui compte c'est que ça finisse par se savoir
! Même si le déploiement semble le point le plus fort d'App Engine,
inviter des masses de développeurs à se forger de nouvelles habitudes
qui les extraie du dogme relationnel est pour moi son aspect le plus
révolutionnaire.
L'évolution de l'offre Google est de plus en plus passionnante et on
peut s'interroger sur la façon dont App Engine se marie avec le reste.
Au fur et à mesure que cette offre grossit, j'ai l'impression que le
vide s'agrandit proportionnellement dans le domaine du desktop. Des
idées sur ce qu'ils pourrait proposer de ce côté-là ?
Références :
http://code.google.com/appengine
http://hadoop.apache.org
http://radar.oreilly.com/archives/2008/04/app-engine-host-your-python-apps-with-google.html
Enjoy !
c.
lauren...@bnpparibas.com
Je suis toujours perplexe de voir Google ne pas capitaliser sur les outils
qu'il veut nous faire utiliser.
Premier exemple avec GWT qui aurait mérité de se retrouvé en première ligne
avec Google App; gageons que Java sera bien dans les prochains langages
supportés.
Deuxième exemple avec Google Chart API dont la simplicité (un serveur de
graph en REST !) est bluffante, mais pas de Google Chart dans Google
Analytics (du Flash à la place).
Google Docs est-il hébergés sur Google App ? oui, s'il est écrit en python
? ou non parceque Google Docs, c'est du sérieux ? je m'y perds.
Je trouve l'offre Google globalement hétérogène et peu lisible; et que dire
du move Android qui met en scène encore autre chose ?
Evidemment, on s'extasie devant les réalisations singulières, mais avouez
que le tout manque sérieusement de cohérence.
Ou alors, il faut prendre tellement de recul et se dire, se persuader que
la démonstration Google est que la techologie n'a aucune importance et qu'a
chaque besoin son langage, son environnement.
C'est un état d'esprit totalement in-transposable au monde de l'entreprise
qui rame exactement dans le sens inverse en essayant de factoriser les
technos.
Bref, si Google a raison, alors je voudrais l'argumentaire pour vendre
l'idée d'un SICOB à ma DSI.
Finalement, l'innovation sans cette contrainte, c'est presque facile.
Pour revenir à Google App, le concept est simple, mais trop.
Comme d'ailleurs Amazon EC2; d'où l'existance de sociétés comme RightScale
qui comble le gap entre la prouesse technologique et sa mise en oeuvre dans
la vraie vie.
Laurent.
Références:
http://www.rightscale.com/m/index.html
Internet
laurent.caille
t...@gmail.com Pour
tec...@googlegroups.com
Envoyé par : cc
techos@googleg
roups.com Objet
Google App Engine
04/10/08 12:25
PM
Veuillez
répondre à
techos@googleg
roups.com
Bonjour,
Références :
Enjoy !
c.
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
Do not print this message unless it is necessary,
consider the environment.
---------------------------------------------
Ce message et toutes les pieces jointes (ci-apres le
"message") sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
N'imprimez ce message que si necessaire,
pensez a l'environnement.
Dominique Jocal
Ce qui est génial, c'est le second effet kisscool : l'image de google qui fait que les gens achètent celle nouvelle offre techno, pourtant volontairement en décalage avec leurs succès réels. GMail n'est pas fait avec Gwt; les gens trouvent GMail génial et veulent faire la même chose, et Google leur propose un outil pour faire ce "genre" d'appli = compilation !! Le chemin qui sépare les deux a été fait par les utilisateurs, pas par le fournisseur; c'est génial ! Une sorte d'assimilation abusive. (un sophisme, je ne trouve plus lequel).
Il devrait arriver à App Engine la même chose qu'à GWT
- conquête immédiate des utilisateurs, par assimilation abusive (gmail <-> gwt; google search <-> app engine)
- légère désillusion lors des premières versions, limitées, mais qui ne diminuera aucunement l'espoir - par manque de concurrent à la hauteur, l'herbe n'est pas plus verte ailleurs, elle est même cramoisie
- (ré)jouissance périodique à chaque montée de version qui montreront de vraies et indiscutables améliorations, voire d'impressionnantes innovations (gwt a vraiment trouvé des trucs sur javascript) - parce que les mecs sont qd même vraiment bons.
Enfin, pas de lézard avec leur base de données, c'est le seul moyen raisonnable (en terme de coût) de monter massivement en charge.
mmm ce teste m'a couté 20 minutes, je vais le blogger...
Laurent Caillette
Tout à fait d'accord, l'offre de Google tient plus de la cathédrale
que du bazar, avec tout ce que ça implique. Une différence de taille
avec un SI qui fournit les infrastructures au métier, c'est que Google
n'a besoin pour vivre que de peu des produits qu'il propose (ne
rapportent du fric qu'AdSense et AdWords je crois). Ne rien factoriser
permet à Google d'économiser sur l'effort de coordination et d'obtenir
de meilleurs délais de mise en oeuvre.
Pour ce qui est d'App Engine, je parie que ses auteurs voulaient
d'abord rendre le produit séduisants avec des exemples peu verbeux.
Ensuite, Python est un langage plus facile à bricoler que Java : ils
se sont payés l'auteur de Python ! J'imagine qu'ils ont rendu Python
complètement séquentiel et ajouté un décompte des cycles d'horloge
consommés pour faire marcher le tout en multitâche coopératif. C'est
plus facile que de modifier le multithreading d'une JVM ! A l'évidence
App Engine essaye de marcher dans les traces de Rails en provoquant la
venue d'une foule d'applications torchées en un week-end de laquelle
émergeront quelques winners. D'ici à ce que le buzz s'alimente, ils
auront le temps de plancher sur l'intégration Java qui demeure
incontournable. Je viens à l'instant de lire le mail du Doj qui résume
ça parfaitement.
A propos d'Androïd je pense que c'est le résultat d'une réflexion sur
l'élément qui peut faire décoller les applications mobiles. La
mainmise des opérateurs sur l'OS étant un élément critique sur lequel
il était possible d'intervenir. C'est comme leur modeleur 3D,
techniquement c'est très loin du reste mais ça reste connecté à une
stratégie d'ensemble.
A prendre des leçons chez Google, on serait tenté de ne pas trop
regarder du côté de l'homogénéité des plate-formes... et ce serait
dommage ! Au niveau technologique le vrai fonds de commerce de Google
ce n'est pas Java ou Flash ou Javascript ou un autre langage, c'est
bien l'infrastructure de grid et là ils réutilisent à fond. Et pour ce
qui est de faire intéropérer les différents stands du SICOB (j'aime
bien la métaphore) il y a cette approche REST basée sur des URLs qui
n'induisent aucune dépendance à un langage donné. Il y a quelques SI
qui feraient bien d'en prendre de la graine !
Lorsque certaines parties de l'offre seront suffisamment stabilisées,
je parie qu'on verra passer un effort de reengineering comme pour
Google "integrated" Search il y a quelques mois.
Evidemment il restera toujours une place pour RightScale ou même la
pile J2EE mais ce sont des produits de "seconde ligne" qui n'apportent
que des finitions aux concepts amenés par les outils de "première
ligne" comme, aussi, EC2 (pas EC3).
A force d'en discuter, je me dis qu'une évolution possible de l'offre
Google serait d'accentuer son exposition de tout sous forme de
services, mais avec des outils supplémentaires pour surveiller l'état
des URLs qui tissent les liens entre les différentes briques des
systèmes. Par exemple, en enregistrant une URL paramétrable, on peut
être informé a priori que tel pan de l'application ne marchera plus
parce qu'en face il n'y a plus personne. Le bénéfice pour Google c'est
d'obtenir un graphe "social" de toutes les applications, une sorte
d'urbanisme a posteriori pour continuer les parallèles hasardeux.
Toujours pas d'idées en ce qui concerne le desktop ?
c.
Pascal Thivent
Comme tu l'as mentionné, Adwords génère la plus grosse partie des
revenus de Google (+ de 2/3) et contribue donc majoritairement à leur
croissance et la constitution de cette capitalisation boursière
supérieure à Intel et tout juste inférieure à Chevron, compagnie
pétrolière la plus rentable du monde. En d'autres termes, Adwords est
la plus grosse machine à cash du monde. Donc pour l'instant, leur
métier reste selon moi la pub.
Tout le reste, c'est pour moi le fruit du modèle d'organisation adopté
par Google. Avec tout leur argent, Google a créé des environnements de
travail hyper attractif, recruté les meilleurs cerveaux de la planète,
mis en place des dispositifs favorables à l'épanouissement personnel
et à la créativité (lire ou relire l'excellent post
http://tinyurl.com/5a6dr3 si vous ne l'avez jamais lu). Bref, ils ont
créé un labo de recherche pluri disciplinaire où la "synthèse
créative" se produit, un endroit propice à l'innovation et celle-ci
emerge effectivement du bazar. A tel point que je me demande s'ils ont
un véritable plan...
2008/4/10 Laurent Caillette <laurent....@gmail.com>:
--
Pascal
Laurent Caillette
penser à l'inverse de la théorie du complot ! La théorie du complot
consiste à expliquer un ensemble de faits apparemment déconnectés par
un complot qui en serait l'unique cause. L'inverse consiste à décrire
les connexions à l'intérieur d'un ensemble de faits comme
non-intentionnelles, c'est à dire qu'elles ne suivent pas de direction
prédéterminée.
C'est vrai qu'avec sa politique de recrutement et de management
complètement dingue, Google a tout l'air de payer des geeks à faire
joujou avec du Python et du Javascript au milieu de bureaux démentiels
comme l'attestent les reportages sur leur nouveau site de Zürich :
http://gizmodo.com/376603/googles-zurich-hq-office-fun-for-everyone-who-works-there-anyway
Au secours ! Je ne vois pas comment il est possible de travailler dans
un environnement pareil ! Plus sérieusement, regardons ce que propose
vraiment Google :
http://bizsolutions.google.com/services
On est d'abord choqué la prédominance des applications gratuites,
l'absence d'homogénéité des plate-formes techniques (déjà évoquée),
mais si l'on regarde mieux des tendances se dégagent.
D'abord, il y a AdSense et AdWords, les vaches à lait. Pour les faire
durer on aide le client final à améliorer son site avec Analytics,
Website Optimizer, Webmaster Central et Site Search.
La publicité est un business fragile. Si on réfléchit au rôle de
l'annonceur on débouche sur un travail *d'intermédiation* avec une
facturation astucieuse (les enchères sur les mots). Dans ce cas Google
Checkout est une tentative de reproduire ce rôle d'intermédiaire à une
autre étape du cycle de vente.
Après il y a des produits à vocation plurielle, comme tout Google Apps
qui génère de l'exposition médiatique à bon marché (buzz), et applique
une délicate pression psychologique sur les concurrents, Microsoft en
premier lieu. Il faut se souvenir qu'à leur sortie, Google Docs /
Spreadsheet avaient l'air de jouets mais maintenant Google développe
une offre d'entreprise autour. Il n'est pas exclu que ça leur rapporte
un jour du vrai pognon.
Il y a ensuite les produits en cours d'incubation, en attendant qu'on
trouve une façon de les monétiser. Il est évident que la video en
ligne et la géolocalisation vont devenir brûlants dans un avenir plus
ou moins proche. Tant pis si d'autres petits malins trouvent la
martingale, l'essentiel c'est d'avoir 60% des parts de marché à ce
moment-là ! Androïd et Sketchup se posent comme des compléments, voire
des déclencheurs.
Les outils comme Google Base, Google Charts et App Engine fournissent
une réponse au besoin d'adresser des segments de marché très précis
dans lesquels Google ne souhaite pas s'investir au premier degré. Mais
cette approche est l'écho du succès d'AdWords qui a mis la publicité
en ligne à la portée d'entités qui n'en avaient jamais acheté
auparavant. Là, il s'agit de laisser des développeurs faire du Web en
les délivrant de fardeaux qui auraient pu les décourager, puis de
regarder ce que ça donne. La relation de confiance développée avec
Google à travers des outils gratuits et de qualité les conduira
naturellement à préférer Google Checkout ou AdWords.
Voilà pour l'offre Google, qui inclut des positionnements avec
plusieurs coups d'avance. Après, on peut se livrer à différents
pronostics sur l'avenir de chacun des produits mais je pense qu'une
cohérence certaine se dégage de l'ensemble. Je ne pense pas qu'il y
ait de plan au sens "il faut livrer Windows 2000 avant... heu, fin
2000" mais des directions vers lesquelles on pousse peu ou prou. Pas
vraiment un complot avec des capes noires, mais rien qui relève du
hasard non plus.
c.
Dominique Jocal
http://www.universite-du-si.com/Parcourslibre.aspx (Les sessions sont pas encore dispos en lien direct, à venir)