Devoxx 2012 – Quoi de neuf dans Google App Engine et Compute Engine ?

De nos jours on parle de plus en plus de Cloud Computing, tant pour les solutions de type “PaaS” (Plateforme as a Service) ou “IaaS” (Infrastructure as a Service).

Google a été un des pionniers dans le domaine du PaaS avec son fameux Google App Engine (GAE) sorti en avril 2009 pour sa version Java.
En ce qui concerne le IaaS, Google a annoncé lors de sa conférence annuelle (Google IO), l’arrivée de Google Compute Engine (GCE).

Les speakers

Alexis Moussine Pouchkine et Ludovic Champenois travaillent tous les deux chez Google et sont respectivement “Developper Relations” et Ingénieur Logiciel travaillant chez Google dans la technologie Cloud.

Mais pourquoi utiliser le cloud ?

En tant qu’Architecte IT, je me pose toujours les questions suivantes :

  • Combien d’utilisateurs vont utiliser mon application ?
  • De combien de machines vais-je avoir besoin ?
  • De quelle puissance CPU / quantité de RAM vais-je avoir besoin ?

Dans un environnement totalement maîtrisé, je peux totalement répondre à ces questions et anticiper les éventuels pics de charge et provisionner les machines nécessaires pour l’hébergement de mes applications. Donc, pas besoin de “cloud” !

Je peux avoir besoin de GAE dans les conditions suivantes :

  • Je n’ai pas de datacenter dans ma cave.
  • Pas besoin d’administrateur système.
  • La scalabilité est automatique.
  • … et c’est beau…

Google AppEngine

Google AppEngine a désormais plus de 4 ans. Ce PaaS a atteint sa vitesse de croisière et est prêt pour le monde de l’Entreprise !

Quelques chiffres sur GAE :

  • plus de 7,5 milliards de hits par jour.
  • plus de 500 000 applications actives.
  • plus de 100 000 développeurs.
  • plus de 2 trillions d’opérations sur le datastore. (pour rappel 1 trillion = 10^18)

Mais comment GAE stocke mes données ?

Depuis peu de temps, GAE nous donne la possibilité de stocker nos données de deux manières différentes, soit en utilisant le “Datastore”, soit en utilisant le “Google Cloud Sql”.

Le DataStore

Si vous venez à utiliser le Datastore, vous entrez de plein pied dans le monde merveilleux du NoSQL, sans schéma. Si vous comprenez ce qu’est une table de hachage, vous risquez fort d’être très productif avec le NoSQL. Le stockage des entités dans le datastore se fait de façon transactionnelle.
Afin de garantir une intégrité des données, ces dernières sont stockées dans plusieurs datacenters (en profitant du fonctionnement “natif” du Google File System et de BigTable).
Enfin, chose intéressante, le HDR (High Replication Datastore) est très stable (100% de dispo pour sa première année d’existence).

Bon, je l’avoue, le NoSQL c’est super mais il est quand même plus simple de travailler avec un langage permettant d’interroger des données structurées, le SQL). D’accord, ce n’est pas à la mode, ce n’est pas toujours ce qu’il y a de plus rapide mais ça fonctionne très bien et ça a fait ses preuves !

Le Google Cloud SQL

Le Google Cloud SQL fournit une base de données relationnelle totalement gérée par Google et hautement disponible. Avec Google Cloud SQL, nous disposons des fonctionnalités suivantes :

  • Une console spécifique permettant d’effectuer les requêtes sur ma base de données.
  • Synchronisation synchrone entre plusieurs Datacenters.
  • Intégration facile avec GAE par l’utilisation de standards tels que JDBC, JPA2, EclipseLink,…
  • Effectuer des imports/exports de données périodiquement.
  •  La possibilité de faire co-exister le “Datastore” et le “Google Cloud SQL”.

Le traffic splitting

“Traffic splitting” permet d’avoir deux versions d’application déployées sur GAE fonctionnant en même temps. Cette fonctionnalité vous permettra, par exemple, d’effectuer un A/B testing.

Le “splitting” peut se faire de deux façons différentes :

  • A partir de l’adresse IP (le plus simple à gérer)
  • A partir d’un cookie HTTP (positionner GOOAPPUID)

Suivi des versions de Google App Engine

Désormais, une version de Google App Engine sortira tous les mois.

AppStats

AppStats permet de mesurer les performances d’une application déployée sur Google App Engine. AppStats s’intègre très aisément par l’ajout d’un listener dans notre application Java (dans le web.xml). Ceci permet, par exemple, de détecter un problème de conception (comme un manque de cache applicatif),…

Une fois déployée, nous pouvons visualiser les résultats dans la console de Google App Engine (exemple ci-dessous).

Google Cloud Endpoints

Annoncé à Google IO 2012, Google cloud Endpoint permet de construire aisément des API scalables (et optimisées) au-dessus de nos application GAE pour les clients WEB et mobiles.

Cloud Endpoints vous autorise à créer vos propres API REST et/ou RPC et utiliser la même architecture que Google pour les héberger. Ensuite, vous pouvez utiliser rapidement votre API et obtenir des clients fortement typés pour Android, IOS et client léger pour faire un développement Javascript côté client.

Google Compute Engine

Google Compute Engine est une solution de IaaS (Infrastructure as a Service) qui a été annoncée à Google IO 2012. Cette solution est en concurrence directe des “Amazon EC2, Microsoft Azure,…” et vient en renfort de la solution Google App Engine.

Une chose qui m’a marqué sur GCE, c’est la simplicité. En effet, toute configuration effectuée depuis la console d’administration peut se faire en JSON (ou par API).

Pour l’instant, seules quelques personnes ont eu l’occasion de tester ce produit mais d’après ce que nous avons pu voir à Devoxx, ça semble être très prometteur.

Conclusion

Google nous habitue de plus en plus à des présentations de qualité réalisé par de très bons speakers qui connaissent leurs sujets sur le bout des doigts.

Il y a 1313 jours, je déployais ma première application sur Google App Engine. Depuis, ce produit est devenu réellement utilisable sur des applications “Entreprise”. Je peux enfin recevoir mes factures en euro, localiser mes données en Europe et avoir un SLA !

Concernant GCE, difficile de se prononcer. J’espère que l’arrivée de Google sur le marché de l’IaaS va tirer le niveau de service vers le haut et que les “grands” du cloud vont s’entendre sur quelques standards.

Nombre de vue : 41

COMMENTAIRES 3 commentaires

  1. Bonjour François,

    Une raison essentielle que tu ne mentionnes pas pour utiliser le cloud est que même dans le cas où tu connais ton pic, ton infra doit être dimensionnée en fonction de ce dernier.

    Si ton activité est saisonnière, toute cette puissance ne servira à rien la plupart du temps et ton infra prendra la poussière. Ce cas d’utilisation peut être facilement poussé pour de simples raisons de coût.

    A +,

    Nicolas

  2. François Ostyn dit :

    Salut Nicolas,
    Tu as entièrement raison ! Que dire de plus ?
    A très bientôt
    François

  3. AMROUCHE dit :

    Très bon post. merci pour ce résumé.

AJOUTER UN COMMENTAIRE