Google a annoncé le support de Java et de Groovy pour la plate-forme de CloudComputing, Google AppEngine. L’annonce finalement a été faite dans la nuit de mardi à mercredi, nous savions donc le contenu de la soirée mystère. Car il faut aussi vous raconter que tout ceci a commencé il y a un mois. Google a organisé discrètement ce rendez-vous avec 50 personnes. Pour mon égo-mètre qui ne demande qu’à partir au quart de tour, j’étais très content de faire partie des happy-few. Bon, en fait nous nous sommes retrouvés comme par hasard avec les Usual Suspects, à part quelques têtes plus rares, ou venues de loin comme Nicolas de Loof ou Sami Jaber.
Dans la première partie de la soirée Maxime TIRAN de Google France nous présente la démarche de Google. Le navigateur est le client du futur, l’effort d’un navigateur comme Chrome est de proposer un outil puissant, afin de pouvoir proposer de nouveaux services. Les dernières technologies Webs comme HTML5 basées sur des standards ouverts visent à rattraper Flash, Java FX et Silverlight. Google se positionne aussi sur l’objectif de faciliter l’accès aux données et d’offrir un socle de Partage. Maxime mentionne le projet Shindig hébergé par Apache, un conteneur OpenSocial qui est une implémentation de l’API OpenSocial. Google souhaite proposer à la communauté des développeurs des présentations, comme cela se fait aux Etats-Unis, afin de prendre en compte votre point de vue. Il rappelle que les projets sur code.google.com sont suivis par les équipes en interne chez Google.
Dans la deuxième partie de la présentation, Didier Girard de SFEIR nous propose une présentation des nouveautés de cette version d’AppEngine. Didier explique en quelques mots le principe du Cloud-Computing et les 3 types de service. Il y a tout d’abord le cloud computing physique, où l’infrastructure est un service (IaaS). C’est l’hébergement classique comme chez Gandi.net qui vous permet de rajouter du CPU ou de la mémoire sur votre serveur. Vient ensuite l’hébergement de services, comme Salesforce.com. Le principe est d’hébergé à l’extérieur un service comme la gestion client (CRM) ou vos emails (Google Mail). Enfin, et c’est le principe d’AppEngine, l’hébergement de type plateforme (Plateform As A Service). Google AppEngine est un serveur d’application qui vous permet de faire tourner des applications écrites en python (depuis un an) ou en Java/Groovy (depuis mercredi dernier).
Ses équipes ont développé deux applications qu’il nous montrera ensuite plus tard dans la soirée. Il a eu en effet la possibilité de tester il y a plus de deux mois, les premières versions bétâ du support de Java, avant l’ouverture aux développeurs.
Un exemple d’application hébergée sur Google AppEngine assez célèbre : http://www.whitehouse.gov/openforquestions/. Oui il s’agit bien de la maison blanche de Barack Obama. Il s’agit d’une application développée à l’occasion d’une séance de questions ouvertes posées par les Internautes. La plate-forme de Google a permis d’offrir des performances le soir de l’événement assez importante. Il y a aussi d’ailleurs du GWT. C’est une application en Python.
Les 5 nouveautés de cette nouvelle version de Google AppEngine sont :
1) La possibilité d’acheter de la puissance supplémentaire
2) Le support de tâches type cron déclenchées par une URL
3) Support d’une base de données type BigTable
4) L’accès à travers votre firewall à vos applications d’entreprise (SDC)
5) Early look at Java Support -> premier regard au support de Java
Concernant le point 1 : l’offre est gratuite jusqu’à 5 millions de pages vues par mois. Autant dire, on a le temps de voir venir. Je n’ai aucuns détails sur le pricing, nada, rien. Impossible de comparer avec Amazon EC2. Les offres ne sont de toutes les façons pas comparables.
Le support des tâches de type cron : il suffit de placer un fichier XML spécial dans son WEB-INF, avec une URL et une syntaxe type Cron. Au déploiement, le moteur de Google AppEngine voit que vous souhaitez qu’il appelle l’url /mail/sendMailingList.do par exemple… Bref il faut que votre service soit exposé sous la forme d’une URL. Nada sur la sécurité… je pense cependant qu’il est faisable de protéger cette url. Peut-on ne pas la déclarer dans le web.xml ? non. Je dois creuser ce sujet.
Concernant le support du stockage de données, Didier nous a montré sur une petite application le principe de l’utilisation de JDO. Basé sur DataNucleus, un projet en license Apache v2, le support JDO permet de vraiment écrire du code portable. C’est plutôt une bonne nouvelle. Plus de détails sur cette page.
Vient ensuite un sujet intéressant. Si je code demain une application pour mon client, et que je la déploie sur Google AppEngine, se pose alors le problème de l’accès aux donnés du SI. Google propose le Secure Data Connector (SDC).
SDC est un logiciel client déployé de l’autre côté de votre firewall qui communique via HTTPS avec la plate-forme Google AppEngine. Ce système permet de construire un pont entre le SI de l’entreprise et le monde de Google. Du coté de votre SI, il faut que vos services soient exposés sous la forme d’URL. J’ai donc compris qu’il faut que votre système d’information s’expose sous forme d’url HTTP, avec une architecture de type REST. Je vois déjà les administrateurs de sécurité avec un lance-roquette sur l’épaule… C’est pas gagné, même si la solution d’un point de vue technique est bonne.
Le code du client SDC est libre, open-source. Tout le monde peut le regarder, ce qui permet aussi à tout le monde de trouver des failles de sécurité. Ce sera bien entendu le point le plus sensible, même s’il n’y a pas d’autres solutions pour l’instant.
Enfin pour le 5ème point, le support de Java et de Groovy. J’ai discuté ensuite avec Guillaume Laforge, qui m’a expliqué le travail réalisé avec les équipes de Google, situées à Atlanta. Avec l’aide des équipes de Google AppEngine, les développeurs de Groovy ont adapté la dernière version afin qu’elle fonctionne sur l’AppEngine. La difficulté, comme Guillaume l’explique, c’est que Groovy étant un langage dynamique, il a besoin de certains droits avec le SecurityManager afin d’instrumenter le code. Par contre il semble que le support de Grails ne sera pas possible, vu la complexité et les efforts à fournir. Je pense que Guillaume pourra expliquer mieux que moi les détails techniques.
Didier a ensuite fait plusieurs démonstrations. Google AppEngine vous propose un plugin pour Eclipse, afin de démarrer rapidement l’écriture de sa première application. Je pense à Maven2 dans ma tête quand Nicolas de Loof précise qu’un plugin pour l’appEngine est dans son sac à dos et devrait être disponible d’ici quelques jours. Nicolas propose un petit plugin maven afin de faciliter le déploiement d’une application à partir de maven. Allez sur son blog, hop, et revenez après j’ai pas terminé.
J’ai vu que les équipes de SFEIR ont sacrément bossé sur un moteur de Blog écrit en Java, hébergé sur Google AppEngine. L’idée est de basculer les blogs de SFEIR vers cette plateforme si j’ai bien compris. Le projet est open-source, à quand un Touilleur Express sur l’AppEngine ? Si j’avais un peu de temps, mais pour l’instant je préfère attendre encore un peu. Peut-être d’ici 6 mois.
Est-ce que Google AppEngine est pour vous ?
Oui définitivement si votre service Web doit gérer une charge fluctuante de visites, si vous avez développé un Gadget pour Facebook ou une application Open-Social par exemple. C’est un moyen de déployer sur une grosse machine énorme votre application, sans vous soucier de devoir réinstaller un jour votre machine. Vous n’aurez plus à gérer la sécurité, la mise à jour, les patches, les sauvegardes… Zéro administration système.
J’ai pour l’instant un peu de mal à imaginer une application d’entreprise type extranet, ou une application CRM. Comment s’interfacer avec un Siebel ou un SAP ? Nous avons ce connecteur SDC pour connecter notre SI à Google AppEngine. Mais avouez que pour convaincre l’équipe sécurité… C’est pas gagné.
Les services Google
La plateforme AppEngine offre des services tels que l’authentification ou l’envoi des emails. La page « Services API » donne la liste des services que nous pouvons utiliser dans nos applications Java déployées sur Google AppEngine:
* Memcache est un cache mémoire simple et partagé
* URL Fetch permet d’utilser java.net.URLConnection pour parler avec d’autres applications, HTTP et HTTPS
* Mail permet d’envoyer des emails avec l’api Java Mail
* Images est un service pour manipuler des photos ou des images : retailler, améliorer, agrandir, basculer etc.
* Google Accounts permet d’authentifier les utilisateurs avec le système de Google. Cela vous décharge de la gestion des users, des mots de passes.
Il y a un énorme écosystème autour de Google : Calendar, Blogs, News, Recherche, Traduction, Paiement, Photos… j’attends maintenant que Google nous offre des services plus intégrés. Certes nous pouvons tous prendre la doc de chacune de ces APIs puis commencer à coder. Mais rêvons un peu, et imaginons un peu de code qui permet de prendre rendez-vous chez votre Coiffeur en prépayant par carte bleu votre séance…
public class TouilleurHairCutServlet extends HttpServlet { public void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { GoogleCalendarService calendarService = GoogleRepository.getCalendarService(); Rendezvous rd=RendezvousHelper.fetch(req); calendarService.createEvent(rd.getDate(),rd.getSubject()); //........ GoogleCheckOutService checkoutService=GoogleRepository.getCheckoutService(); try{ checkoutService.bill(req); }catch(GoogleCheckoutServiceException e) { // cancel event in calendar and say bye ..... } // Send an email with Google Calendar event, Google Map for address... ... ... // Fin resp.setContentType("text/plain"); resp.getWriter().println("Votre rendez-vous est confirmé et payé... "); } }
Rêvons un peu… une application Web où vous pourriez consommer facilement différents services Google. Je pense plus particulièrement à tout ce qui est OpenSocial afin de créer des gadgets pour HiFive, Salesforce.com, LinkedIn.com ou MySpaces…
J’écris ce code (bien timbré il faut le reconnaître) et je repense à ce que disait Nicolas : où est Google Guice ? A priori rien ne nous empêche d’utiliser Guice, Spring ou autre. Il y a cependant un dernier point, et après je vous laisse : toutes les APIs de Java ne sont pas supportées. Et bien oui… pas possible de créer une Thread ou de vous balader sur le filesystem… qui n’existe pas au sens classique. Il va donc y avoir un sacré effort pour lister les frameworks supportés et ceux non supportés, ce qui va alimenter la blogoshpère rapidement. C’est donc un facteur important à prendre en compte : tout n’est pas supporté, car comme toute application hébergé sur une plateforme de type PaaS, vous êtes sur un système virtuel. Oubliez l’idée de créer des fichiers plats, des sockets. Utilisez URL Fetch ou BigTable. Il y a un sujet d’architecture intéressant.
Si j’étais didier, je profiterai bien de l’USI pour parler un peu du type d’application que l’on peut faire avec Google AppEngine.
Merci à Google et à SFEIR pour l’organisation de la soirée, et à bientôt.
0 no like
Salut Nicolas,
Merci encore une fois pour ce super résumé. Je ne pense pas que tu ais raté quoi que ce soit, à part peut-être les discussions autour d’Android, l’OS mobile open source promu par Google qui débarque en France.
Pour la liste des frameworks supportés, il y a une page que Google maintient:
http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine
J’en profiter pour annoncer que l’on vient de porter Restlet sur GAE:
http://blog.noelios.com/2009/04/11/restlet-in-the-cloud-with-google-app-engine/
Tu as raison, ça va alimenter la blogosphère pour un petit moment! 🙂
Je veux bien voir mon nom avec un joli lien vers http://blog.loof.fr comme pour Sami 😉
Ce qui m’inquiète le plus sur la plateforme GAE Java c’est l’utilisation de JDO/JPA pour accéder à BigTable. Ce n’est pas du tout un modèle relationnel, et le fort niveau d’abstraction de JPA risque de nous faire écrire des requêtes qui n’ont pas leur place sur AppEngine.
Il va rapidement falloir identifier les « bonne pratiques » liées à BigTable (déjà qu’on avait du mal pour les bonnes pratiques JPA tout court)
Pour le soucis des frameworks compatibles, j’ai créé une page wiki ouverte à tout ceux qui veulent bien contribuer pour donner plus de visibilité : http://code.google.com/p/works-on-gae/wiki/Index