Il y a de cela bientôt trois ans jour pour jour, Google annonçait pour la première fois sa plateforme de Cloud PaaS (Platform As A Service). S'appuyant sur Java, Python ou Go comme langages de développement adossés à AppEngine comme infrastructure de services, force est de constater que 3 ans plus tard, l'engouement du départ a laissé place à plus de scepticisme au fil des mois. Les raisons sont multiples. Développer pour le Cloud nécessite de s'approprier de nouveaux outils, de nouveaux frameworks, tous aussi propriétaires les uns que les autres.
Lors de la présentation officielle de GAE en 2009, aucun des standards Java (excepté l'API Servlet) n'était supporté. Il faut le savoir, l'immense majorité des applications Java développées aujourd'hui s'appuient sur des standards, que ce soit Java EE, Spring (qu'on appellera un standard de fait) ou Java Persistence API. Mais le plus bloquant durant toutes ces années a clairement été l'accès aux données.
La plupart des applications en entreprise n'ont pas besoin de gérer des centaines de milliers d'utilisateurs simultanés, ni de monter en charge linéairement à l'infini. Le commun des mortels ne s'appelle pas FaceBook, Google ou Microsoft. En voulant imposer à tout prix des bases de données de type BigTable avec un vocabulaire aux antipodes de ce que nos développeurs maitrisent au quotidien, les fournisseurs de Cloud se sont enfermés dans des technologies puissantes mais peu productives. Dans ce monde, si vous ne parlez pas couramment MapReduce, DataStorage, Entity ou Kind, point de salut. Le langage d'interrogation des données est quasi inexistant car complexe. La gestion des indexs se fait bien souvent à la main, l'import et l'export des données est propriétaires, donc inutile. Et que dire de la partie Décisionnel ou du Data mining.
Quoi qu'en en dise, les bases relationnelles sont là pour durer. Le standard SQL est loin d'être obsolète et les serveurs d'application ne disparaitront pas avec l'avènement du Cloud. Microsoft l'avait d'ailleurs bien compris en fournissant bien avant Google le produit SQL Azure aidé par le fait qu'il éditait déjà la base SQL Server. Amazon de son côté, avec ARDS (Amazon Relationnal Database Service) en avait fait de même. Google ne pouvait rester les bras croisés.
Je le dis haut et fort chers amis, l'an 1 du Cloud à la mode GAE (Google App Engine) démarre officiellement aujourd'hui. Cette fois, nous ne parlons plus d'une pseudo API JDO ou d'un support limité de JPA sur une base BigTable mais d'une vraie, d'une pure et d'une belle base de données relationnelle, j'ai nommé MySQL. En réalité, deux évènements majeurs ont modifié cet écosystème de niche. Le premier a été l'annonce de Google en Novembre d'un support béta (voire alpha) de MySQL (dont le nom officiel est Google Cloud SQL). Un choix stratégique qui adosse GAE à une marque qu'on ne présente plus. Le second a été le support des standards JEE pour l'accès aux bases relationnelles, à savoir JPA 2 (Java Persistence API) depuis une très récente mise à jour du SDK AppEngine (1.6.1). Ajoutez à cela le support d'un framework ORM comme Hibernate et de Spring comme alternative aux API Entreprise Java Beans (non supporté, mais prévu) et vous obtenez la plateforme idéale de développement Java pour le Cloud (des contraintes de sécurité prévenait initialement tous outils instrumentant du byte-code de fonctionner correctement sur GAE).
Non seulement Il est désormais possible de développer avec une base de données relationnelle mais l'architecture applicative du Cloud reprend point pour point toutes les briques logicielles proposées par un serveur d'application lambda du marché. Concrètement, cela signifie qu'une application JEE ne nécessitera aucun changement pour s'exécuter sur le cloud de Google.
Cloud SQL, déjà largement utilisé au sein de Google achèvera d'ici peu sa phase béta et proposera un vrai modèle économique. La base est aujourd'hui gratuite avec un quota de 10 Go (au passage largement suffisant pour un grand nombre d'applications).
Enfin, cette nouvelle donne côté Java ouvre la porte à de nombreux cas d'utilisation. Il est désormais possible de maitriser ses données et de porter d'un simple click son application du Cloud Amazon à celui de Google (via des Dump MySQL). Compte-tenu de cette nouvelle portabilité inter-Cloud, les clients vont enfin pouvoir choisir le modèle économique le plus adapté sans avoir à remettre en cause leur architecture applicative.
Pour vous prouver que tout cela est possible dès à présent, nous vous offrons le code source complet de l'application DNGCloudSQL. Cette application est hébergée gratuitement sur AppEngine et fonctionne avec GWT 2.4, GXT 3.0 beta2, Spring 3.1, JPA 2, Hibernate 3.6 et MySQL 5.5. La démo est disponible ici => http://dngcloudsql.appspot.com/ et le code source ici => http://bit.ly/z7JX2W.
Amusez-vous bien !
Samips1 : il vous faudra au préalable créer un compte Google Cloud SQL => https://developers.google.com/cloud-sql/docs/before_you_begin#enroll
ps2: il vous faudra également utiliser le plugin GPE pour Eclipse avec le dernier SDK 1.6.X et paramétrer le tout avec votre compte AppEngine
ps3 : ne vous fiez pas aux performances de l'application en ligne lors du première accès, les VM GAE sont parfois en hibernation ce qui engendre un temps de cold start. Le second appel en revanche doit être rapide.
Flux XML
