Le Google Cloud Platform Tour s’est déroulé mardi 1er Octobre et vendredi 4 Octobre, dans les locaux parisiens de Google, pour présenter l’offre et les principaux services de Google Cloud. En effet, Google est en train de mettre le paquet sur son Cloud avec en particulier l’arrivée de Google Compute Engine (GCE), annoncé lors du Google IO 2012 et ouvert à tous depuis IO 2013
Globalement, l’offre se structure de la manière suivante :
- IAAS
- Compute engine
- Cloud Storage
- Cloud Datastore
- Cloud SQL
- PAAS
- Google App Engine
- SAAS
- GMail, Drive, …
Dans cet article nous allons nous intéresser sur les parties IAAS et PAAS qui nous concernent plus.
Google Compute engine
Tout d’abord un gros plan est fait sur Google Compute Engine (GCE) le petit dernier de la famille et pas le moindre, puisqu’avec GCE, on a clairement un concurrent direct de EC2. Nous avons donc eu une démonstration rapide de son utilisation via l’interface Web : démarrage d’une instance, au bout d’une vingtaine de seconde l’instance est disponible pour s’y connecter en ssh. La présentation insiste sur la rapidité de démarrage des instances avec GCE par le lancement d’un script qui démarre 100 VM prêtes en moins de 4 minutes … impressionnant !
Quand on arrive pour la première fois dans un projet GCE, on se sent tout de suite à l’aise avec l’interface Web. De plus, cerise sur le gateau, pour toutes les opérations que vous faites dans l’interface Web, vous pouvez récupérer l’équivalent pour la ligne de commande ou l’api REST, offrant ainsi un apprentissage et une transition simplifiée vers ces modes d’interactions.
Du point de vue système d’exploitation supporté par GCE, le choix est actuellement limité à centos 6 ou debian 6 et 7.
En ce qui concerne le pricing de l’offre GCE, Google innove en proposant une facturation à la minute avec un minimum de 10 minutes facturées pour chaque VM démarrée.
Un point important soulevé par les speakers est l’existence de périodes de maintenance dans les datacenter Google. En effet, lorsque l’on crée une VM, il faut choisir la zone (un datacenter google) dans laquelle elle va s’exécuter : vous aurez alors la visibilité de la prochaine période de maintenance de la zone dans laquelle vous avez créé votre VM. Il est donc primordial de concevoir une application capable de ne pas être victime de ces périodes de maintenance : votre application doit pouvoir être répartie dans plusieurs zones afin de continuer à fonctionner. Pour les ingénieurs Google, c’est le même fonctionnement que pour les applications internes et cela permet de concevoir des applications résistantes.
Finalement, les Persistent Disk apportent une solution de stockage à vos VM. Lorsque vous démarrez une VM, vous pouvez la démarrer avec un scratch disk, mais cette solution n’est pas conseillée (cela dépend de votre besoin bien entendu) puisque lorsque votre VM s’éteindra, vous perdrez toutes les données stockées dessus. C’est là qu’intervient le Persistent Disk, il va conserver vos données même après l’arrêt de la VM.
Les persistent disk offres les caractéristiques/fonctionnalités suivantes :
- cryptés
- redondés
- snapshot incrémental (pour le pricing vous ne payez que l’espace utilisé donc uniquement l’incrément du snapshot)
- il est possible de booter une nouvelle instance en prenant un snapshot comme source pour le persistent disk.
- partageable par plusieurs VM
- jusqu’à 10 To
Je vous invite à allez faire un tour sur le github de Google Cloud Platform qui regorge de projet d’exemples.
L’offre de stockage
Côté stockage Google offre les services suivants :
Cloud Storage
Service Google existant depuis 2010, c’est l’offre de stockage de fichier dans le Cloud et accessible par l’intermédaire d’une api REST.
Cloud Datastore
Base de données NoSQL type bigtable. Historiquement disponible uniquement dans le contexte d’un projet Google App Engine, c’est désormais un service à part entière accessible de GAE et GCE bien sûr, mais également de n’importe quel autre serveur qui ne serait pas hébergé par Google. Disponible depuis le Google IO 2013, l’API pour y accéder en dehors de GAE (qui lui propose en surcouche JPA, JDO ou Objectify) est pour l’instant bas niveau et très verbeuse. Cependant, il ne faut pas oublier que le pricing du Datastore est entre autre fondé sur la quantité de requêtes, d’accès read, write au Datastore, donc l’utilisation d’une API bas niveau peut permettre d’optimiser les coûts. Par ailleurs, les ingénieurs de Google conseillent de mettre en cache vos données autant que possible afin de faire baisser vos coûts mais également de gagner en rapidité.
Cloud SQL
Google propose une base de données MySql “as a service”, vous n’aurez donc pas à vous occuper de l’administration de votre base de données (réplication, patch, backup). Votre base de données sera accessible depuis GCE, GAE et d’une feuille de calcul Google Drive.
BigQuery
Implémentation public de Dremel, BigQuery vous permet de requêter les données, que vous aurez préalablement stockées dans BigQuery, à l’aide d’un langage proche du SQL.Par exemple, voici une requête très simple pour trouver dans Wikipedia (publicdata:samples.wikipedia est un des datasets d’exemple proposé par Google) tous les titres contenant java:
select count(*) from publicdata:samples.wikipedia where REGEXP_MATCH (title, 'java');
BigQuery est donc un outil d’analyse interactive de très gros jeux de données, avec pour objectif de permettre à des personnes non développeur de pouvoir également facilement s’en servir. Son équivalent Open Source actuel est Apache Drill.
Pour vous donner une idée de l’utilisation, vous pouvez essayer BigQuery très rapidement (après avoir créé votre projet GCE) en utilisant l’interface Web et commencer à jouer avec les exemples de dataset publics que Google vous propose.
Et pour clôturer la partie stockage…
Rien ne vous empêche d’installer et de gérer votre propre serveur MySQL, Cassandra, Mongo, Hadoop ou autres dans un projet GCE, mais dans ce cas ce sera à vous de gérer la scalabilité et répartition géographique, tandis qu’avec les services Google, ce sera inclus.
Google App Engine
C’est un peu le vieux de la vieille de l’offre Google Cloud, ouvert en 2008 avec initialement uniquement Python, puis Java en 2009, Go en 2011, et PHP cette année.
A noter que GAE n’est plus en bêta depuis novembre 2011 et donc avec un support officiel de Google depuis cette date.
GAE souffre d’une image assez négative du fait du lockin qu’il impose en n’autorisant pas toutes les classes du JDK à s’exécuter dans une instance GAE : il est ainsi impossible d’écrire sur le système de fichiers, d’ouvrir un socket, générer un sous-processus ou un thread. Le speaker, Ludovic Champenois (lead developper et project manager sur GAE), nous explique que ces limitations existent avant tout pour des raisons de sécurité et que les multiples mises à jour de sécurité déployées par Oracle depuis le début de l’année montrent bien que Google a eu raison d’imposer ces limitations. Toutefois, puisque ces limitations sont perçues comme un lockin, Google a créé un TCK (Test Compatibility Kit) pour le framework App Engine, permettant ainsi potentiellement de transférer votre appli vers une autre offre Cloud. Redhat travaille ainsi sur son implémentation (Capedwarf de l’API App Engine pour son offre PAAS OpenShift.
Cette ouverture vous permettra de partir chez un PAAS concurrent mais ne vous libérera pas de la blacklist de certaines classes du JDK. Pour ce dernier point, nous avons eu l’annonce que Google travaille également sur la possibilité de déployer votre projet App Engine sur une instance GCE : vous pourrez alors utiliser toutes les classes du JDK. Mais attention : dans ce cas, vous ne profiterez plus des capacités de scalabilité de GAE et vous aurez également l’entière responsabilité de l’administration système de vos instances GAE.
Conclusion
La plateforme Google Cloud va gagner en maturité dans les mois qui viennent, des fonctionnalités continue d’arriver au fil de l’eau : un service de load balancing est disponible depuis Août, le streaming dans BigQuery est disponible depuis début Octobre. On s’attend également à l’amélioration de l’intégration des éléments de l’offre, par exemple une IHM unifiée GCE et GAE, …
Je teste GCE depuis Juin 2013 et je me suis senti à l’aise dés le départ, l’interface Web est claire et met en confiance.
Les termes utilisés (Instance, Disks , Snapshot, …) sont explicites, on s’y retrouve très rapidement. La documentation est plutôt bien faite et elle existe, dans la plupart des cas, en français, pour ceux que l’anglais rebute. La courbe d’apprentissage est rapide, j’ai eu quelques occasions d’utiliser Amazon AWS et je n’avais pas été autant emballé que je ne le suis aujourd’hui pour GCE !
Nous allons très bientôt proposer un atelier sur GCE et si vous n’avez pas l’occasion de tester par vous même d’ici là vous pourrez venir à Xebia pour vous faire votre propre opinion !
Les speakers pour ces présentations étaient : Mandy Waite, Ludovic Champenois,William Vambenepe et Alexis Moussine-Pouchkine