Didier : Didier Girard je suis le directeur des opérations et de l'innovation chez Sfeir. Alexis : Et je m'appelle Alexis Moussine-Pouchkine, je travaille chez Google et je suis responsable des relations développeurs en France.
2. Vous êtes donc ici pour nous parler du Cloud Google, expliquez-nous de quoi il s'agit ?
Alexis : À la base c'est mettre à disposition l'infrastructure de Google, qui est un investissement massif à travers beaucoup de datacenters, de gros investissements en infrastructure, au sens large, donc réseaux, machines. Mettre cette infrastructure à disposition de vos applications, sous différentes formes, de stockage, d'exécution d'applications et c'est vraiment les mêmes machines, les mêmes infrastructures qu'on met à disposition de développeurs qui souhaitent utiliser le cloud Google.
3. Quels sont les cas d'utilisation classiques de l'offre Cloud de Google ?
Didier : Ce que l'on peut dire déjà c'est qu'il y a de moins en moins de scénarios qui ne rentrent pas dans l'offre plateforme Cloud de Google. Donc plutôt que de parler de Cloud de Google, maintenant je pense qu'il faut plus parler de plateforme, on parle d'une plateforme qui offre énormément de services. Par exemple vous avez besoin d'héberger une application Java, Python ou Go, vous pouvez le faire sur la plateforme Google. Pareil si cette application doit encaisser de très gros pics de charge et que vous voulez du scaling automatique de votre application, la plateforme Google est très bien adaptée à ce scénario. Vous voulez du stockage massif, par exemple stocker des vidéos, des photos en très grande quantité. Quand je dis très grande quantité je parle de plusieurs Tera-Octets de données, la plateforme est très bien adaptée à ça. Vous voulez faire par exemple du datamining, vous avez une API qui vous permet de faire ça, c'est l'API qu'on appelle "Prediction API". Vous pouvez aussi construire une API au-dessus de votre propre plateforme, que vous allez exposer à travers ce qu'on appelle des "Endpoints". Vous pouvez faire du Full-Text search. Vous pouvez faire de la BI aussi avec BigQuery. Maintenant il y a énormément de services qui sont proposés par la plateforme Cloud de Google.
Alexis : L'histoire du Cloud chez Google remonte à 2007, n'est-ce pas ?, ou 2008, avec l'arrivée d'App Engine, avec une version Java qui est arrivée derrière. Donc historiquement le cloud Google est très orienté Platform-as-a-Service et récemment il y a beaucoup de services qui ont été rajoutés, qui font qu'aujourd'hui on a vraiment une offre extrêmement complète, je pense, qui va de l'approche Platform-as-a-Service où on abandonne volontairement toute responsabilité d'administration, on délègue ça à Google qui a les technologies et les personnes pour je pense le faire de manière plus efficace, et puis ensuite il y a vraiment une complétude de l'offre avec tout ce qui est gestion de données à la fois en termes de stockage, d'analyse de ces données. Et puis tout ça encore une fois sur le Cloud Google, c’est-à-dire avec l'infrastructure, la performance, les dispos qui font la caractéristique de Google et de ses services.
5. Quelles sont les nouveautés apparues dans App Engine ces derniers mois ?
Alexis : Alors App Engine est en version 1.7.7 à ce jour. Et parmi les nouveautés importantes, on a généralisé l'utilisation de Java 7. Donc ça c'est quelque chose qui est important, qui nous a permis d'utiliser certaines nouveautés de Java 7 tout en proposant tout ce qu'on faisait avant avec App Engine. Un point important est "Google Cloud Endpoints". C'est la possibilité de publier sous forme d'API REST un certain nombre de ces fonctions existantes dans Java, ou en Python, ou en Go. Et d'être capable de générer du code côté client pour trois types de clients que sont les applications Android, les applications iOS et le Web au sens large des applications JavaScript. Donc non seulement on va exposer et mettre à disposition toute l'infrastructure de gestion d'APIs qui est connue chez Google, celle qui est utilisée par les Google Maps et toutes les autres APIs, mettre ceci pour publier des APIs et puis on va générer du code pour le bootstrap qui permettra de manipuler des objets en Java, pour des applications Android, d'avoir quelque chose de fortement typé côté client, en Objective-C pour iOS, et en JavaScript pour toutes les applications Web. Donc ces endpoints sont quelque chose d'important. On a beaucoup travaillé sur le plugin Maven qui est synchronisé maintenant avec les développements d'AppEngine. Cloud SQL a vu beaucoup d'évolutions, c'est MySQL hautement disponible dans le cloud. Et enfin on a des datacenters maintenant en Europe donc on a la possibilité de déployer ces applications et ces données et de garantir que les données resteront en Union Européenne.
6. Après 1 an de Compute Engine, où en est l'adoption de cet outil ?
Alexis : Alors Compute Engine a été annoncé lors de Google I/O 2012, donc c'est une offre plutôt orientée infrastructure. On est en train de parler de machines virtuelles, on est root sur sa machine virtuelle, il en existe différents types, on peut faire des snapshots, toujours sur l'infrastructure Google, ça c'est important. On a eu beaucoup de résultats de performance sur des jobs qui sont plutôt intensifs en termes de calcul. Il y a un certain nombre d'analyses qui ont été faites, je vous renvoie à des articles qui ont été écrits et publiés dans la presse. Toujours l'infrastructure Google donc ce qui nous a permis d'avoir de très bons résultats sur des temps de démarrage de ces instances, de l'utilisation du réseau, extrêmement performant. Et donc aujourd'hui ça n'est pas encore ouvert à tout le monde ; c'est ouvert aux gens qui sont sous contrat de support Gold, qui est une offre assez récente de support sur le cloud qui a été annoncée. Et on espère très prochainement une ouverture à tous de cette plateforme qui est un très bon complément je pense à App Engine qui permet d'ouvrir le capot quand on en a besoin parce qu'on avait un vrai cas d'usage qui ne fonctionnait pas dans cet environnement de Platform-as-a-Service qu'est App Engine.
7. Didier, as-tu des exemples concrets de mise en place réussie de Cloud Google ?
Didier : Oui donc j'en ai plusieurs. Il y en a un que beaucoup des auditeurs doivent connaître c'est "À bon entendeur". C'est une application que j'ai déployée sur App Engine il y a maintenant 4 ans. Il y a eu plus d'un million d'utilisateurs de l'application donc c'est quelque chose d'assez gros. En 4 ans j'ai eu 0 souci, l'application a toujours répondu présente malgré des pics à plus de 6000 utilisateurs simultanés, plus de 120 requêtes sur les serveurs. Ça répondait toujours très bien, et tout ça pour des couts modiques. Ça on va dire que c'est plus dans le domaine de l'expérimentation, du jeu… mais ça fonctionne très bien dans ce cadre-là. Il y a beaucoup de startups maintenant qui adoptent cette plateforme. Aussi dans le domaine de la mobilité, il y a des très grosses applications mobiles qui ont pour backend App Engine, c'est vraiment une offre qui est très bien adaptée à la mobilité. Et puis après dans des comptes plus institutionnels, on a travaillé avec un groupe qui s'appelle Malakoff Médéric, dans le domaine de la retraite, où chez Sfeir on a développé pour eux un Dashboard de reporting, toujours basé sur App Engine. On travaille actuellement avec un grand équipementier automobile, dans lequel on est en train de leur développer plusieurs applications, entre autres des applications avec des pics de charge très importants en fin de mois. Donc du coup la plateforme répond bien à ce scénario. Puis dernier exemple, la conférence des évêques de France utilise App Engine pour diffuser les horaires de la messe. À nouveau c'est quelque chose avec une activité extrêmement cyclique, et donc la plateforme App Engine est bien adaptée à ça en fait.
Alexis : Alors je pense qu'il y a toujours le scénario de vouloir prendre son développement existant de l'emmener dans le cloud, ce qui fonctionne dans une certaine mesure, mais je pense qu'il faut essayer de comprendre ce qu'est le Cloud, c'est vraiment un environnement où il y a des contraintes parce qu'on est dans un environnement mutualisé et parce que c'est ça qui fait fonctionner le Cloud, l'équation économique du Cloud, c'est la densité d'applications que l'on va être capable de mettre de manière sécurisée et performante sur une même infrastructure. Ça a des implications sur la manière dont on conçoit son application, sur le temps de démarrage de son application. Si on devait ne dire qu'une chose par rapport à ne donner qu'un seul conseil d'architecture ou de choix de technologie de développement, je pense que tu seras d'accord c'est vraiment sur le temps de démarrage de son application parce qu'on est dans un environnement où on peut sacrifier et on va sacrifier des instances en permanence dans cet environnement Cloud.
Didier : Donc l'idée quand on est sur le cloud, si on veut pouvoir encaisser des très gros pics de charge, il faut pouvoir provisionner des instances très rapidement. Si pour provisionner une instance ça prend plusieurs dizaines de secondes, le côté je vais encaisser un pic de charge de manière très rapide ça ne fonctionnera pas. Donc sur le cloud, il faut être capable de bootstrapper une application en 2-3 secondes. Ça veut dire quoi ? Ça veut dire que les serveurs d'application classiques ne vont en général pas être adaptés à ce type de fonctionnement. Par ailleurs, les frameworks qui ont été pensés pour l'informatique d'entreprise, frameworks de type JavaEE, ne seront pas forcément adaptés au Cloud parce qu'ils ont souvent des temps de startup et d'introspection de jar très important en fait. Et de ce fait, prendre une application qu'on a pensé pour un serveur d'application classique et la porter sur le Cloud, ça va fonctionner, mais on ne sera pas sur un fonctionnement optimum et ce qu'on peut dire c'est que dans 5 ans on ne fonctionnera plus du tout comme ça.
Alexis : Et d'un point de vue technique, mais un peu psychologique aussi, un des vrais problèmes que l'on peut rencontrer c'est l'abandon de responsabilités de l'administration, quand on est dans un monde Platform-as-a-Service, lorsque l'on déploie son application. C'est tout ce qu'on maitrise et ensuite il y a assez peu de choses à "tuner", à configurer. Et le technicien en nous à chaque fois, a toujours un petit peu envie de jouer avec l'infrastructure. Et là il n'y a pas besoin, car ça fonctionne et il faut l'admettre, il faut abandonner officiellement la responsabilité à Google de gérer cette infrastructure.
Didier : Ce que je peux dire aussi c'est que une des manières de penser la construction de son application, c'est en cherchant à comprendre le coût qu'elle va générer. On parle de "Design by Cost", c’est-à-dire que quand on développe quelque chose on va aussi s'attarder sur "Le traitement que je suis en train de faire, combien il va me couter", s'il est sollicité fréquemment, il va falloir que je cherche vraiment à optimiser de manière à minimiser les couts.
Alexis : Alors il y a un outil qui s'appelle AppStats qui permet, pour chaque requête reçue par une application hébergée dans App Engine, de traduire ça en cout et de découper ça en "Ceci est le cout associé au traitement par le frontend, ceci est un cout associé à l'écriture ou à la lecture dans le Datastore ou dans tel système de stockage" et vraiment d'être capable d'éclater les couts, et à chaque fois on parle de "micro-cent" ou "micro-penny". Donc c'est quelque chose très petit, mais on peut vraiment l'associer à chaque requête et on peut optimiser à ce titre-là son développement et faire du Cost Driven Development. Et donc c'est un outil vraiment très important, je pense, à intégrer facilement, mais tôt, dans les cycles de développement. Et puis ensuite il y a des sociétés qui se spécialisent aujourd'hui dans l'optimisation de coût, y compris sur les Clouds de type Google, qui vont permettre d'avoir un Dashboard, de voir où on en est, faire des recommandations sur le meilleur usage et ce sont des choses que l'on encourage nous aussi.
Alexis : Alors je pense qu'il y a beaucoup d'énergie qui est consacrée chez Google à l'investissement matériel, à tous les étages, sur les Datacenters. Il y a beaucoup d'investissement qui est consenti sur la sécurité. Ça se traduit par un certain nombre de certifications de la plateforme Cloud en termes de sécurité. Et puis ce sont des gens qui, au-delà du produit que l'on pense être bon, au-delà de l'investissement, c'est aussi des personnes, des sortes de "Super DevOps", qui sont là pour, en temps réel, regarder l'infrastructure qui héberge vos applications, pour de manière proactive, être capable de basculer d'un datacenter à un autre. Donc c'est vraiment cette combinaison de sécurité, d'investissement dans le matériel, les Datacenters, et dans les personnes qui sont hautement qualifiées et qui sont souvent les gens qui ont écrit cette même infrasturture, qui sont l'anti-thèse j'allais dire, du pupitreur qui va appuyer sur restart, qui va faire les choses beaucoup plus proactives, plus intelligentes que ça.
Didier : Moi ce que j'ai envie de dire à ce niveau-là c'est que dans 5 ans, je n'imagine pas qu'un DSI achète encore des serveurs. Je ne l'imagine pas. Il y a une information récente qu'il semblerait qu'IBM cherche à vendre sa division "Serveurs". C'est bien la preuve qu'ils ne voient pas ça comme un marché important pour le futur. C'est important déjà de se dire que dans 5 ans, il est probable que l'on n'achète plus de serveurs. Un DSI actuellement, il doit réfléchir à ça et se dire, quelle stratégie Cloud j'adopte. Et ne pas avoir une stratégie Cloud au niveau d'une DSI actuellement, je pense qu'on est proche de l'erreur de jugement. C'est nécessaire d'avoir cette ambition. Après pour ce qui est de la sécurité, pour moi, est-il plus délicat d'héberger son information chez un infogéreur, ou sur un cloud de type Google. Je ne sais pas, je pense qu'il faut poser ces questions dans ces termes-là : où est-ce que l'information est la plus sécurisée ? J'ai un peu tendance à dire que sur des Clouds de type Google l'information sera plus sécurisée que chez un infogéreur classique.
11. Merci Alexis et Didier d'avoir répondu à nos questions et à bientôt
Didier : Merci
Alexis : Merci InfoQ