Google App Engine et Java: une révolution ?
Intro
Annoncé lors du Google Campfire (littéralement feu de camp) du 7 avril dernier, le support du langage Java dans Google App Engine (GAE) est une grande nouvelle pour ceux qui développent dans ce langage.
Flashback
Un petit flashback s’impose en effet: GAE est un service qui permet de déployer des applications web sur l’infrastructure Google sorti il y a un an mais avec comme seul langage de développement Python.
Depuis la sortie de GAE, le support de Java comme langage figurait comme la première demande (même devant PHP). Demande exaucée donc depuis le 7 avril par Google.
GAE c’est quoi ?
Google App Engine est une une plateforme permettant de déployer des applications web Python et maintenant Java de type servlet/JSP en profitant gratuitement jusqu’à une certaine limite (quota) de l’infrastructure de Google.
C’est presque une révolution car dans le monde de l’hébergement, l’hébergement d’application web java n’est pas très répandu. Il y a bien quelques hébergeurs spécialisés dans ce domaine mais au vu des prix et des contraintes la solution la plus simple reste souvent de louer un serveur et d’installer soit même son JDK/Tomcat. On est très loin du niveau de support de PHP que presque tous les fournisseurs d’accès à internet offrent à leurs clients.
C’est là que Google App Engine Java change la donne.
On peut enfin déployer facilement une application web java comme on le ferait sur un serveur d’application en local mais surtout profiter de l’infrastructure de Google pour tenir une charge importante en répartissant la charge sur plusieurs serveurs si nécessaire.
C’est un des points fort de GAE par rapport à un serveur dédié: on déploit son application et c’est Google qui s’occupe de gérer la montée en charge de l’application selon les besoins.
Contraintes et persistence de données
Pour pouvoir assurer cela, GAE impose certaines contraintes à bien prendre en compte:
- il n’est pas possible d’écrire dans un fichier
- pas de possibilités de créer des threads
- pas de connexion de type socket directe à des serveurs externes (les requêtes HTTP sont par contre autorisées)
- une limite d’exécution de 30s par requête (depuis)
- support des apis java limité à une whitelist : http://code.google.com/appengine/docs/java/jrewhitelist.html
- pas d’accès à des bases de données relationnelles type MySQL (par contre JDO et JPA sont disponibles)
Il faut bien comprendre que ces limites permettent à Google d’assurer une montée en charge en déployant une même application sur plusieurs serveurs.
Dans ce cas on comprend pourquoi l’écriture de fichier est interdite : elle n’a aucun sens quand l’application est distribuée. Un fichier généré par une instance d’une application ne peut pas être utilisé par une autre instance de l’application sur un autre serveur tel quel.
Avant de vous révolter sur ces contraintes, relisez les restrictions à respecter dans le développement des EJB (http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html), on y retrouve presque les mêmes contraintes.
L’aspect absence de base de données est plus délicat: mettre à disposition une base de données relationnelles de type MySQL à l’ensemble des applications distribuées sur plusieurs serveurs est un problème qui n’est pas simple. Les Facebook, Google, LinkedIn, Flickr, Amazon et autres gros consommateurs de ressources n’ont apparemment pas trouver de solution simple et s’appuient sur des systèmes alternatifs plus simples en plus de bases de données relationnelles traditionnelles: Cassandra pour Facebook, BigTable pour Google, Dynamo pour Amazon, …
La persistence des données dans GAE s’appuit donc sur un système « Datastore » plus simple et plus « scalable » comme on dit, ce système dispose d’APIs mais pour nous faciliter la vie, les standards Java de persistence de données JDO et JPA sont disponibles via une implémentation basée sur le Datastore.
La gestion des sessions web est elle-même gérée via ce Datastore ce qui permet d’avoir des sessions distribuées sur plusieurs serveurs (besoin classique quand il s’agit de distribuer une application gérant des sessions utilisateurs sur plusieurs serveurs, la méthode la plus simple étant l’affinité de serveur, un client est « fixé » sur un serveur donné et toutes ses requêtes ultérieures sont dirigés sur ce même serveur).
Console d’Administration
GAE met à votre disposition une interface d’administration dont on aimerait bien avoir plus souvent l’équivalent dans le monde professionnel: statistiques de requêtes à la secondes, de temps par requêtes, de consommation CPU, nombre d’octets envoyés/reçus, …
Petite remarque: c’est une vue consolidée des différents serveurs sur lesquels peuvent tourner votre application (à prendre en compte avant de dire que le serveur d’application X ou Y fournit la même chose…).
Versioning
GAE gère les versions de vos applications: à chaque fois que vous déployer vous pouvez préciser la version de l’application que vous déployez, les différentes versions sont ainsi conservées sur GAE et même accessibles simultanément individuellement via une URL spécifique. Une fois déployée, vous pouvez choisir quelle version doit être celle par défaut. Point intéressant pour pouvoir tester une nouvelle version en réel sans l’activer pour tout le monde (hors problème de gestion de version de la structure des données …).
Développement/Déploiement & GWT:
En plus de l’App Engine SKD, un plugin pour Eclipse est disponible pour développer/tester votre application en local puis la déployer sur GAE. Le JDK utilisé est 1.6. Le plugin intégre aussi en option le plugin Google Web Toolkit (GWT) permettant de développer en java des applications Ajax.
Coûts ?
Et oui, GAE est gratuit jusqu’à un certain niveau (nb de requêtes, octets, …), mais au delà l’application est bloquée par un message d’erreur. Ces quotas sont extensibles en payant.
Voici ci-dessous une partie des quotas sur les ressources:
La liste complète: http://code.google.com/appengine/docs/quotas.html
Ouverture de GAE à d’autres langages
Le support de Java par Java permet à des langages qui ont été porté sur la JVM comme par exemple Ruby avec JRuby de pouvoir être exécuté sur GAE:
Groovy qui s’appuie directement sur la JVM est lui aussi disponible:
Cron , Secure Data connector
GAE dispose aussi d’un ordonnanceur (cron) permettant d’appeler une URL de votre application, bien utile pour mettre à jour des statistiques, remplir des caches, …
Secure Data Connector est un service permettant de pouvoir accèder depuis GAE à des données au sein de l’entreprise.
Conclusion : Révolution ?
Je ne sais pas encore si GAE Java est une révolution mais c’est clairement un gros changement dans le paysage Java car GAE abaisse fortement la barrière de déploiement d’application web Java sur Internet. Plus besoins de serveurs dédiés, plus de gestion de montée en charge sur différents serveurs.
On se demande (enfin surtout moi 
), pourquoi ce n’est pas Sun, père de Java qui a eu cette initiative ?
Pourquoi Sun n’a pas populariser davantage Java chez les hébergeurs webs ou en offrant lui-même un hébergement de ce type ?
Quel dilemme pour un pro Java d’être obligé d’utiliser PHP pour son blog perso car c’est le langage le plus répandu chez les hébergeurs mutualisés gratuits et payants. Quelle frustration de ne pas pouvoir déployer ses applications web java aussi facilement que d’autres lancent leur blog ou leur applis PHP !
C’est pourquoi GAE est à mon avis, une avancée importante pour le développement de Java dans le web.
Sources:
- Google App Engine
- Liste des propriétés systèmes et moteur de servlet utilisé (Jetty)
- What you cannot do using Java in Google App Engine :
- Standards-based Persistence For Java™ Apps On Google App Engine
- L’annonce sur le blog Google Code
- Import des données dans GAE
- Secure Data connector (permet d’accèder à des données de l’entrepris depuis GAE)
- Google App Engine Will Change Java Web Development
- Overview of Java support in Google App Engine (avec un schéma d’ensemble)
- Google Brings App Engine’s Pros and Cons to Java (InfoQ)
Je reste sur mon idée que tout n’est pas rose. C’est bien simple, chaque framework ou bibliothèque, qui fonctionne pourtant dans tout serveur d’application *avec* les restrictions que tu cites, ont nécessité des modifs pour fonctionner sur GAE/j. C’est ce que j’appelle une portabilité toute relative.
Pour ce qui est de l’hébergement, oui, je partage ta frustration. Qq chez Sun n’a pas fait son boulot… Pour autant ca ne donne pas à Google le droit de proposer des versions presque standard de servlet, JPA, etc. et de supprimer Swing/AWT.
J’aimerai mettre tout ceci sur le compte de la « preview ».
Franchement Alexis, GAE est une des meilleures choses qui soit arrivée à Java depuis longtemps, je comprends ta frustration : c’est certain que c’était à Sun de faire ça en premier. Mais ce n’est pas une raison pour virer à la mauvaise foi en reprochant à Google ‘de supprimer Swing et AWT’…
D’autant plus que cet argument semble faire un parallèle avec l’attitude de Microsoft il y a 10 ans avec son son JDK modifié, Sun ne va quand même pas faire un procès à Google sur ce coup là !?
Que Sun lance une offre concurrente, par exemple avec un hébergement sur Glassfish V3, et ça sera encore mieux pour le monde Java d’avoir le choix entre plusieurs solutions.
Google n’est pas Microsoft.
Swing et AWT (il y a d’autres exemples) sur le serveur sont plus utiles que tu sembles le penser.
Je sais bien que certaines applications serveurs utilisent Swing et AWT pour la génératiion dynamique d’images, mais c’est vraiment faire la fine bouche que de dénigrer GAE pour ne pas supporter ce genre de choses. Personnellement je suis fan d’OSGi, ma première réaction n’a pas été de critiqué Google pour ne pas permettre d’utiliser OSGi sur GAE… (limitation sur les classloaders, les threads, les accès fichiers, …).
La question est simplement de savoir s’il est possible de faire une platefome d’hébergement mutualisée en Java sans imposer des contraintes drastiques, à mon avis l’approche de Google est la plus logique on commence avec bcp de restrictions et peut être seront elles allégées dans le futur.
J’en reviens à ton premier message et je trouve dommage de ne même pas saluer cette initiative (si tu l’as fait ailleurs, je retire ma critique).
S’il existe une meilleure solution ou si Sun nous en prépare une ça serait super, en attendant GAE/j est vraiment une très bonne nouvelle pour le monde Java.
La restriction sur AWT me fait un peu sourire :
Rappelez-vous, il a fallu attendre le JDK 1.4 pour avoir le mode « headless » permettant de manipuler des images via awt
sans avoir de carte graphique sur un serveur UNIX (le fameux message d’erreur « Can’t connect to X11 window server »).
Un comble quand on pense que la plupart des serveurs UNIX (y compris ceux de Sun) étaient utilisés justement sans carte graphique non nécessaire sur un serveur.
Je me rappelle d’avoir utiliser Xvfb (un serveur X virtuel simulant une carte graphique) puis des librairies AWT alternatives comme PJA (Pure Java Toolkit) de eTeks (http://www.eteks.com/pja/).
Maintenant il y aussi Apache Sanselan (http://incubator.apache.org/sanselan/site/index.html).
Alexis, je comprends ta remarque mais j’ai néanmoins bien peur que GAE rencontre un vrai succès car comme le dit Franck c’est la seule offre actuelle d’hébergement java qui répond à un besoin quasi universel : pourvoir déployer rapidement, facilement et « presque » gratuitement une application web écrite en java. Quand un service génère autant de valeur, les dommages collatéraux portés aux standards ont un poids tout relatif. Et en disant cela, je ne porte pas de jugement de valeurs !
Salut Freddy. C’est bien le succès probable de GAE qui me fait réagir. Le standard est et doit rester plus important qu’une seul implémentation aussi novatrice et bienvenue soit elle. Sinon ca devient du chacun pour soi et tout code Java coté serveur va commencer par un if(isGAE) { … }.
Bonjour,
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.
« On se demande (enfin surtout moi
), pourquoi ce n’est pas Sun, père de Java qui a eu cette initiative ? »
…Alors la on est bien d’accord !, Je me suis toujours pose cette question…J’ai moi aussi du utiliser PHP pour mon site, la ou j’aurai aime du Java. pour integrer moi meme d’autres fonctionnalites plus facilement….
Donc adios un Mashup Grails avec Yahoo Map + Weather, en requetant yahoo.com avec HttpClient
Malin Google, t donc oblige d’utiliser leurs services dont Google Map… z’ont bien verrouiller leur affaire.
“On se demande (enfin surtout moi
), pourquoi ce n’est pas Sun, père de Java qui a eu cette initiative ?”
J’essaie de répondre à cette question
Parce que Google a beaucoup plus avancé sur le cloud computing (techno et nombre de serveur mis en place …)