Greg DeMichillie (Google) "Google Container Engine croît au même rythme que Compute Engine"

Containers, Big Data pour tous, PaaS multi-langage, lowcost... Le directeur Product Management de la Google Cloud Platform dévoile ce que sera le cloud du futur selon Google.

JDN. Pensez-vous que les containers représentent le futur du cloud ?

Greg DeMichillie est directeur Product Management pour Google Cloud Platform. Cette interview a été réalisée lors de l'événement Google Next qui avait lieu le 13 octobre à Paris   © Google

Greg DeMichillie. La plupart des entreprises exploitent leurs applications dans le cloud comme elles le faisaient jusqu'alors au sein de leur système d'information. Simplement, elles le font désormais dans un data center virtuel. Nous pensons que, d'ici cinq ans, ces pratiques vont beaucoup évoluer. Elles se calqueront de plus en plus sur celles des grandes entreprises de l'Internet, Google, Facebook, Yahoo... Et de moins en moins s'inspirer des acteurs IT traditionnels comme VMware. Les containers, de type Docker en particulier, vont représenter un des éléments centraux de cette mutation informatique.

Chez Google, nous utilisons les containers en interne depuis 10 ans maintenant. Nous avons développé l'une des technologies originelles des containers dans le noyau Linux [il s'agit de la technologie lmctfy qui s'adosse à Linux LXC NDLR]. Avec Kubernetes, il était important pour nous de développer un projet open source complet basé sur la logique des containers.

Aux côtés des containers, quelles sont donc les autres briques du cloud du futur chez Google ?

L'une des principales problématiques du cloud aujourd'hui réside dans le stockage des données. Elle est en partie réglée aujourd'hui. Pour un coût relativement faible, vous pouvez stocker des pétaoctets de données dans un environnement comme celui de Google. La question est maintenant de savoir comment rendre ces données intelligibles. Pour y répondre, il existe aujourd'hui un grand nombre d'outils spécialisés autour du Big Data.

Kubernetes a pour vocation d'être implémenté par d'autres clouds

Nous pensons que la distinction qui existe entre data et Big Data va disparaître. Tout simplement parce que tout le monde va pouvoir faire du Big Data. Une nouvelle génération de produits est en effet en train d'apparaitre. Des outils beaucoup plus sophistiqués qu'Hadoop, mais aussi beaucoup plus automatisés. Vous savez, Hadoop est aujourd'hui une technologie que nous utilisions il y a 10 ans chez Google.

Pensez-vous déployer d'autres technologies proposées par Docker, comme Swarm, pour gérer de manière plus standardisée les containers sur Google Cloud Platform ?

Tout le monde est d'accord pour dire que Docker est la fondation du container. La question ensuite est de savoir quelle est la meilleure façon de gérer une architecture quand vous avez des dizaines, des centaines ou des milliers de containers. Il y a un certain nombre de projets actifs dans ce domaine. C'est le cas de CloudFoundry, de CoreOS ou de Mesosphere. Nous estimons que notre technologie, Kubernetes, est la meilleure approche pour gérer l'orchestration de containers. Compte tenu de notre expérience de déploiement de containers à l'échelle, nous pensons que notre offre est plus mature que n'importe quelle autre. Chaque semaine, nous déployons pas moins de 2 milliards de containers sur l'ensemble des infrastructures de Google.

D'ailleurs, nous observons une adoption de plus en plus large de Kubernetes au sein de la communauté, et pas seulement de la part de partenaires. Certains grands clients, comme eBay, ont recours à Kubernetes pour gérer leur environnement. C'est aussi le cas de Samsung en entreprise. Des start-up comme Porch ou l'e-commerçant américain Zulily ont également déployé Kubernetes pour gérer leur infrastructure de containers. Notez que Kubernetes est un projet open source et ouvert, qui permet d'utiliser des outils tiers en parallèle comme Swarm.

Mais pour permettre la migration d'application entre clouds, il est important qu'un standard d'orchestration de containers émerge...

Nous gérons des montées charge de 0 à 1 million de requêtes en une seconde

Effectivement. Quand vous optez pour un fournisseur de cloud, vous ne devez pas vous retrouver prisonnier de sa technologie. Chez Google, nous estimons qu'il faut absolument éviter ça. C'est pour cette raison que nous utilisons des API open source, comme Hbase, pour notre produit. C'est aussi pour cette raison que nous contribuons à un grand nombre de projets open source. C'est, enfin, pour cela qu'un des principes fondamentaux de Kubernetes est de pouvoir tourner pas seulement sur le cloud de Google, mais aussi sur Amazon Web Services, Microsoft Azure, OpenStack, VMware... voire même en environnement bare metal.

Dès lors, il est important pour nous que Kubernetes ne soit plus simplement un projet de Google. Nous continuerons probablement à être son leader. Mais il doit impliquer d'autres acteurs. C'est dans cette optique que nous avons lancé une fondation [avec notamment Red Hat, CoreOS, IBM, Intel, Mesosphere, Microsoft ou VMware - Lire l'article : Google confie son infrastructure de container à un consortium open source].

Combien de containers sont aujourd'hui opérés, au total, par vos clients sur Google Cloud Platform ?

Google Cloud est l'un des produits de Google dont la croissance est la plus rapide dans l'histoire du groupe.  La croissance de Google Compute Engine [le IaaS de Google NDLR] est en particulier très rapide. Container Engine, qui est notre version complète de Kubernetes, croît maintenant au même rythme que Google Compute Engine.

Proposez-vous une boutique d'images de container ?

Nous proposons plusieurs voies pour permettre l'installation d'images de container pré configurées. Notre Google Container Registry permet par exemple de gérer et stocker des images privées sur Google Cloud, dans un espace sécurisé. Nous proposons aussi des instances prêtes à l'emploi qui peuvent être démarrées en un clic, dont certaines sont orientées container.

Google App Engine permettra bientôt d'implémenter vos propres langages


Les containers Docker peuvent-ils être utilisés pour les applications critiques en haute performance, et pour le stockage de données ? Il y a encore un débat autour de ces questions.

Docker est conçu pour gérer des montées en charge rapides, avec la capacité de provisionner en temps réel un grand nombre de nouveaux containers. Ce que ne permettent pas de faire les machines virtuelles traditionnelles, beaucoup plus lourdes avec leur OS intégré. Notre PaaS, Google App Engine, grâce à son orchestrateur de containers Kubernetes, permet de gérer des montées charge de 0 à 1 million de requêtes en une seconde. Nos services de stockage sont gérés sur une architecture équivalente. Les systèmes critiques haute performance, avec de gros volumes de données, peuvent par conséquent être pris en charge par ce type d'environnement en container.

La sortie de PHP 7 est prévue le 12 novembre 2015. Quand pensez-vous l'implémenter sur Google App Engine ?

Google App Engine est en train d'être réarchitecturé pour passer d'un environnement tournant sous le système de container historique de Google vers un environnement basé sur Docker et Kubernetes. Pour l'instant, c'est assez compliqué d'ajouter de nouveaux langages sur App Engine tel qu'il est aujourd'hui. Dans les prochaines semaines ou mois, nous allons ouvrir App Engine pour permettre aux utilisateurs d'y porter eux-mêmes les langages de leur choix. C'est un projet que nous avons baptisé Manage VM. Il permettra d'implémenter n'importe quel type de langage en conservant la couche de management d'App Engine et ses dispositifs d'équilibrage de charge automatiques. Cela nous permettra de supporter pas seulement les prochaines versions de PHP ou Java, mais tous les langages souhaités par les clients.

Comme Amazon Web Services et Microsoft, vous ne cessez de réduire les prix de vos services cloud, notamment en matière de stockage. Certains ont qualifié ces stratégies de "course au zéro". Est-ce une stratégie réaliste ?

Je ne dirais pas que notre stratégie est de faire ainsi la course au zéro. Il est vrai que le coût du matériel informatique est de moins en moins cher, et dans le même temps nous optimisons la manière dont nous utilisons le hardware. Vous allez donc continuer à observer des baisses de prix de la ressource informatique en termes de machines virtuelles et de stockage. Mais la valeur d'un cloud ne réside pas uniquement dans la puissance informatique ou du stockage, mais dans sa capacité à analyser les données et leur donner du sens.


Biographie professionnelle : Greg DeMichillie est directeur Product Management pour Google Cloud Platform chez Google. Sa mission principale consiste à gérer les liens entre les équipes produit de Google Cloud Platform et les clients les plus importants et les plus stratégiques du cloud de Google. Il a pour objectif notamment de s'assurer que la feuille de route de Google Cloud Platform est en phase avec leurs besoins. Avant de rejoindre Google, Greg DeMichillie a été directeur Product Management EC2 chez Amazon Web Services. Auparavant, il a travaillé pendant 9 ans comme responsable de l'équipe produit en charge des outils de développement web et mobile chez Adobe.


A lire aussi :

 

Google / Google App Engine