Google vient de lancer la pré-version béta limitée (donc "web 2.0" ;-p) de son tout nouveau service d'hébergement d'application.
L'idée est simple : vous développez votre petite application web en utilisant toutes les ressources des API Google (BigTable, Google File System, ...) et Google se propose d'héberger l'application sur son infrastructure - y compris la promesse d'un réseau hautement fiabilisé, capable d'absorber sans broncher les pointes de traffic, et de supporter l'incompréhensible engouement des internautes pour votre site "mon-chien.net".
Google App Engine s'accompagne de son SDK pour aider au développement. Les applications sont écrites en Python, seul runtime supporté pour l'instant. L'architecture est prévue pour permettre à l'avenir d'autres langages/runtimes.
Quelle différence avec l'offre existante ?
Pour de "petits sites", PHP+MySQL est l'offre courante, mais généralement accompagnée de restrictions de traffic / bande passante / charge CPU. Aussi, vous devez être capable d'évaluer vos objectifs de traffic au plus juste, tout en n'étant pas à l'abris de rencontrer le succès. Rien de plus déplaisant que de voir son site préféré - devenu indispensable - "déménager" vers un autre hébergeur et être indisponible pendant plusieurs longues journées...
Pour les "gros sites d'entreprise", J2EE ou .Net, il faut maîtriser toute la chaîne d'hébergement - serveur, base de données, sécurisation, déploiement, monitoring ...
D'ou la question : quelle techno retenir pour mon site de vente de chewing-gums d'occasion ? Sans hésiter Google App Engine :
- Gratuit, dans la limite de restrictions très raisonnables (500Mo stockage, 5Mon pages/mois)
- Prométeur : le SDK va probablement s'enrichir pour faciliter l'accès aux services Google.
- Cool : c'est encoure tout chaud !
Seule limitations, bloquantes :
- je n'y connais strictement rien en Python
- Je ne fais pas partie des 10000 chanceux qui ont obtenu les ID de test de cette pré-version béta ;-(
Le bug n°1 dans la gestion googleAppEngine réclame le support de Java. Pas étonnant vu l'absence (presque) totale d'offre d'hébergement Java. Les PHP-iste se feront sans doute égallement entendre, mais ils n'en sont pas réduit à lancer tomcat sur leur PC perso accessible d'Internet par la ligne ADSL, eux !
Comme quoi, J2EE a raté quelque chose ! Ce n'est qu'une bonne grosse norme bien compliquée, bien vendue par les grands éditeurs, rapidement dénigrée (qui fait encore de l'EJB2 CMP ?), et inadaptée à l'hébergement mutualisé - vu l'absence d'offre.
La cause (à mon avis) étant l'impossibilité de :
- limiter les ressources attribués à une application web (un while(true) {} et tout le serveur est bloqué) - sauf extension propriétaire ...
- l'impossibilité de recharger les classes à chaud (c'est si simple de remplacer un .php)
- le packaging inutilement compliquée (seul Axis2 fait pire)
Je pense qu'il y a une place à prendre pour les applications Groovy : sue la base d'une structure WAR (explosée), incluant les jars de librairies utilitaires, Chaque fichier .java peut être interprété comme un script Groovy. On pourrait donc modifier un .java et observer les effets immédiatement. -- juste une idée, si quelqu'un à du temps devant lui...
