Soirée AppEngine chez Google : compte-rendu

google-app-engine.pngJeudi soir, Google avait convié une quarantaine d'invités à une soirée au cours de laquelle un nouveau produit "top-secret" devait être présenté.
En réalité, le mystère était éventé depuis quelques jours déjà, sur les blogs et sur Twitter : il s'agissait tout simplement du support des applications Java sur le Google App Engine (GAE), la solution de cloud computing de Google. Il faut dire qu'un indice nous avait été fourni dans le mail d'invitation : un QR-Code révélait le mot "Duke", qui est le nom de la mascotte du langage Java.

On pouvait reconnaître dans la salle quelques habitués des événements informatiques parisiens, des architectes de grandes entreprises utilisatrices de Java, ainsi que des personnalités comme Antonio Goncalves ou Guillaume Laforge. Et tout le monde a joyeusement prononcé Engine "Enjaïne" pendant toute la soirée...

La soirée s'est déroulée en trois parties :

  • Un récapitulatif du portfolio des technologies de Google, ainsi que sa vision à long terme du web.
  • Une présentation pratique du Google App Engine
  • Et enfin, un buffet permettant aux participants de discuter tranquillement.

Le Cloud Computing, mode d'emploi

Le Cloud Computing est un grand mot signifiant tout simplement la mise à disposition de ressources informatiques sur un réseau (et en particulier, Internet). On peut le décomposer en trois couches : - Les services d'infrastructure matérielle : Amazon EC2 et S3... - Software as a service (SaaS), les services informatiques accessibles en ligne : Salesforce... - Et entre les deux, les fournisseurs de frameworks de cloud computing : Google App Engine.

Tout cela est bien joli, mais concrètement, à quoi ça sert ? Tout simplement à répondre à un simple problème de coût de l'infrastructure : pour déployer une application sur internet, une entreprise a aujourd'hui le choix de mettre en place ses propres serveurs, avec les problèmes et coûts associés (maintenance, alimentation, backup, sécurité, formation du personnel...), ou utiliser un service pré-configuré comme une plateforme de cloud computing. Pour des opérations ponctuelles (un sondage, une campagne publicitaire, un événement) ou à la fréquentation très variable, la seconde solution semble idéale.

Google et le Web

La première partie était animée (avec un micro éteint) par Maxime Tiran, ingénieur et commercial Google.

Le web a beaucoup évolué en quinze ans. Il suffit de comparer l'état de l'art en 1995 (Netscape, pages statiques) et en 2009 (Firefox, Chrome, Opera, et des contenus toujours plus riches et interactifs). De nouvelles technologies sont apparues, rapprochant toujours davantage le web du desktop : HTML, puis DOM et CSS, puis Ajax, Flex et Silverlight...

Dans ce panorama technologique, Google développe sa stratégie en trois points :

  1. Rendre le navigateur plus puissant : Chrome (ou Chromium, la version non "brandée" de Chrome), V8 (machine virtuelle Javascript) et Webkit
  2. Améliorer l'accès au réseau, notamment via les appareils mobiles : Android et l'Open Handset Alliance
  3. Faciliter le développement et le déploiement d'applications sur le réseau : GWT, Google App Engine

Un des points remarquables de cette stratégie est le refus de développer ou d'utiliser des technologies propriétaires. Google base en effet son modèle économique sur l'utilisation du réseau par les internautes, et apporte donc un soin particulier à toucher le plus large public possible en évitant toute forme d'incompatibilité ou de "vendor lock-in".
Par exemple, toutes les applications Google sont accessibles via des API utilisant le format AtomPub (plus d'un milliard de hits par jour !), GWT génère du code javascript compatible avec la majorité des navigateurs récents, et la gestion des widgets est réalisé via OpenSocial (une API standard permettant d'interagir, via des connecteurs spécialisés, avec différents réseaux sociaux comme Facebook).

Google App Engine

La seconde partie était animée par Didier Girard (SFEIR), spécialiste des technologies Google.

Google App Engine a un an aujourd'hui, et rassemble environ 150'000 développeurs et plus de 50'000 applications : BestBuy, eBay, Forbes...
La première version, qui ne gérait que le langage Python, connut certaines success stories surprenantes, comme BuddyPoke, qui permet de choisir un avatar et de "poker" ses amis ; son déploiement sur l'App Engine lui a permis de scaler instantanément et de s'adapter à son succès foudroyant. Un autre exemple est le site de la Maison Blanche, qui a mis en place un site permettant de proposer et sélectionner les questions posées au président lors d'un débat télévisé ; en pic, il y eu jusqu'à 700 requêtes/seconde.

Le déploiement et l'hébergement d'une application sur le Cloud sont gratuits, dans la limite de certains quotas (bande passante, CPU utilisé, etc.) par tranche de 24h. Cette limite est toutefois assez large (ex: 5 millions de pages servies), et devrait suffire à la plupart des applications.
Au-delà, il est nécessaire d'activer le système de facturation pour acheter des services supplémentaires. Un bon point, il est possible de paramétrer un plafond de facturation, et de répartir cette somme entre les différents services.

Google App Engine est en constante évolution, et de nouvelles fonctionnalités sont ajoutées régulièrement, en fonction de leur popularité sur le bugtracker : memcache, la manipulation d'images, le support Java et Groovy, HTTPS, les tâches cron...
Voici quelques services disponibles :

  • Les tâches périodiques doivent être implémentées sous forme de servlets, dont l'URL sera appelée régulièrement. Un fichier XML permet de définir la fréquence et l'URL d'appel. Ce qui peut soulever des craintes quant à la sécurité d'un tel système.
  • Database import/export : cette API permet d'importer/exporter les données sur/depuis BigTable. Cette fonctionnalité était très demandée par les entreprises, qui souhaitaient pouvoir sauvegarder localement leurs données.
  • SDC : Secure Data Connector. Il permet aux applications déployées sur GAE d'accéder à des données externes, notamment placées derrière un firewall (ex: données dans Siebel hébergées dans l'entreprise). Il faut alors installer un agent sur un serveur local à l'entreprise, qui ouvre le port 443 et permet de faire le pont entre l'application sur le cloud et les données sur l'intranet.

Pour finir, Didier a réalisé une démonstration du développement d'une application avec Eclipse et son plugin Google App Engine.

  • Pour créer une application minimale, rien de plus simple : il suffit d'utiliser l'assistant de création de projet, qui propose d'utiliser GAE et GWT, puis de la lancer localement à l'aide d'un clic droit -> RunAs -> Google App Engine.
  • Ensuite, il faut éditer le fichier appengine-web.xml pour spécifier le nom de l'application (préalablement déclaré via la console d'administration en ligne), déployer l'application sur le cloud à l'aide d'un simple bouton de la barre d'outils.
  • Enfin, Didier a démontré l'utilisation de l'API JDO pour gérer la presistance (il y a aussi une API pour gérer les transactions). La console d'administration permet de visualiser les données sauvegardées et de les requêter en SQL, mais c'est plutôt prévu pour les données très peu volumineuses.

Questions et réponses

  • Question : si les briques de GAE évoluent (ex: GWT 1.6 -> 2.0), que se passe-t-il pour les applications ? Est-on obligé de migrer ?
    Réponse : les jars sont embarqués dans l'application (ex: appengine-api.jar, gwt-servlet.jar...), donc en principe aucun problème.
  • Question : comment monétiser les applications développées sur le cloud ?
    Réponse : utiliser les API standard (AdSense, etc)
  • Question : quels frameworks d'IOC sont supportés ?
    Réponse : Guice fonctionne ; Spring pas encore, mais il est plébiscité sur le bugtrack, et SpringSource devrait travailler dessus.
  • Question : les développeurs d'applications peuvent-ils blacklister certaines IP pour éviter de se faire spammer et de payer pour la bande passante utilisée ?
    Réponse : rien n'est prévu dans ce sens en standard, mais on peut limiter la facturation.

Conclusion

Au final, cette soirée, bien que très sympathique (Google sait recevoir, aucun doute), aura eu des airs de pétard mouillé. L'audience était assez déçue de ne pas repartir avec une information juteuse, une annonce exclusive ou une démonstration technologique fracassante, malgré les petites cachotteries de Google (le mail "secret", l'accord NDA signé avant la réunion...).

Quoiqu'il en soit, Google App Engine a l'air prometteur, et j'essaierai de le tester rapidement. Restez à l'écoute !


Commentaires

1. Le lundi 13 avril 2009, 12:51 par Alexis MP

Hum... pas de Spring sur GAE/j c'est une limitation importante.
Je n'ai pas compris le sens de la réponse Google: c'est à SpringSource de faire le boulot, ou bien il sont déjà dessus?
Y-a-t-il un seul framework qui n'a pas eu à faire des modifs pour GAE/j?

2. Le lundi 13 avril 2009, 14:21 par Olivier Croisier

D'après ce que j'ai compris, Google se penche en priorité sur les problèmes qui obtiennent le plus de votes sur leur bugtrack, et l'intégration avec Spring figure parmi les premiers. Je pense donc que Google travaillera dessus très prochainement, même si SpringSource ne restera sûrement pas les bras croisés non plus. Sans doute travailleront-ils en coopération, comme ils l'ont déjà fait pour l'intégration de Groovy avec Guillaume.

Ce qui me semble étrange, c'est qu'ils ont invoqué le fait que Spring posait des problèmes à cause de son utilisation de librairies bas niveau comme java.lang.reflect, qui sont pourtant présentes dans la ''white list'' de l'App Engine. Mystère, mystère...

3. Le lundi 13 avril 2009, 18:43 par Alexis MP

Merci pour la précision.

Sinon, je ne vois pas java.lang.reflect.ReflectAccess.
C'est rusé de faire une "white list" et pas le contraire...

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.