Quelles sont votre approche, votre philosophie sur Docker quand on voit une « fusion » plus ou moins profonde entre les services IaaS et PaaS (Google, AWS et timidement Azure) ? Est-ce le nouveau modèle cloud qui va faciliter le déploiement plus rapide des applications sans avoir à créer des workloads lourds complets ?

Notre approche est pragmatique. Docker a d’abord été conçu comme un moteur pour faire tourner des containers sous Linux. Nous visions la simplicité (faire peu de choses, mais les faire bien !), tout en ayant les fonctionnalités nécessaires pour le rendre utilisable au cœur d’un PAAS public ou privé. Très vite, nous nous sommes rendu compte que Docker pouvait remplir bien d’autres rôles (de nombreuses personnes ont vu en Docker un composant idéal pour des plateformes d’intégration continue, par exemple). Puis, des acteurs majeurs dans le monde de l’hébergement (Rackspace et Google les premiers, suivis par AWS, Azure, et bien d’autres !) ont probablement vu dans Docker un moyen de faire un pont entre leur offre IAAS, et la demande croissante pour une nouvelle offre PAAS. Les équipes, la technologie, et même les valeurs sont très différentes entre ces entreprises faisant de l’hébergement IAAS, et les entreprises offrant un PAAS, comme Heroku. Docker aide à réaliser cette fusion. Ce nouveau modèle va bien entendu faciliter la vie des gens devant déployer des applications distribuées. Il ne faut pas non plus s’imaginer que Docker va résoudre tous les problèmes d’un coup de baguette magique : pour le développeur utilisant une stack LAMP et déployant son code par FTP, Docker n’est pas pertinent, évidemment.

Votre approche permettra aussi d’être réellement portable d’un cloud à un cloud (à condition de supporter docker), cela va-t-il passer par des accords, un support toujours plus large de Docker par les fournisseurs ?

La plupart des clouds supportent déjà Docker, « de gré ou de force », si j’ose dire. Du moment que les serveurs proposés fonctionnent avec un noyau Linux récent, Docker fonctionnera, sans intervention particulière de l’hébergeur. Mais l’utilisateur dispose alors de serveurs Docker « bruts » ; il faut rajouter une couche d’orchestration pour gérer ces ressources. C’est là que chaque opérateur va pouvoir se démarquer. Au lieu d’avoir 1, 10, 100 serveurs Docker et devoir les gérer manuellement, l’opérateur peut exposer un point d’entrée API Docker unique, permettant au client de gérer son cluster comme si c’était un serveur unique. C’est le rôle de libswarm, un des projets qui a été rendu public lors de la conférence DockerCon en juin à San Francisco : offrir une bibliothèque de primitives permettant d’écrire ce genre de services d’orchestration.

Quels outils, API donnez-vous aux développeurs ?

Il y a le « Docker Engine », qui est le composant Open Source qui peut s’installer gratuitement sur n’importe quel serveur Linux et le transformer en hôte Docker. Toutes les fonctionnalités de Docker sont exposées via une API REST, ou bien via un outil en ligne de commande. Ensuite, il y a le « Docker Hub », qui offre une brochette de services variés :

— la « registry », qui est un système de stockage pour les images de containers;

— le « public index », qui permet de référencer les images publiques (cela répond au besoin : « je cherche une image ElasticSearch prête à l’emploi, où la trouver, laquelle utiliser? »);

— « automated builds », qui permet de lier un dépôt de code GitHub ou Bitbucket, et créer automatiquement des images Docker à chaque commit, afin que ces images soient toujours à jour par rapport au code.

D’autres services sont en cours de développement.

Quel est votre modèle économique ?

Nous avons deux sources de revenus. Premièrement, les services et le support de Docker, pour les entreprises qui déploient Docker au sein d’applications critiques. Le modèle est similaire à celui de Red Hat avec RHEL, et peut s’assortir de prestations ponctuelles, par exemple de la formation, par le biais de notre réseau de partenaires. Ensuite, notre offre SAAS articulée autour du Docker Hub. Là aussi, le modèle est classique et éprouvé : la plupart des services du Docker Hub sont accessibles gratuitement pour les projets publics (lorsque le code et les images de containers sont accessibles à tous), mais l’utilisation pour des projets privés est payante. C’est comme cela que fonctionne GitHub (et bien d’autres).

Interview réalisée par François Tonic