Interview Cornelia Davis, VP Technology de Pivotal : «DevOps, l'équipe chargée

Avec le rachat de Pivotal, annoncé fin août, VMware ramène dans son giron le PaaS Cloud Foundry, Pivotal Container Service qui permet de gérer les clusters Kubernetes en production, ainsi que le service event-driven Function, actuellement en version bêta. Ce dernier est bâti au-dessus de Knative, projet d'extension de Kubernetes en direction des développeurs pour déployer les charges de travail serverless, issu d'un partenariat entre Pivotal et Google. Il y a quelques mois, la rédaction du Monde Informatique a eu l'opportunité de rencontrer Cornelia Davis, vice-présidente chargée de la technologie chez Pivotal. L'occasion de revenir avec elle sur la stratégie de l'éditeur californien et la façon dont son offre s'est construite en prenant acte de l'adoption de Kubernetes par les entreprises.

Le Monde Informatique : Depuis de nombreuses années, chez EMC puis comme vice-présidente, responsable de la technologie chez Pivotal, vous suivez de très près tout ce qui touche au PaaS en général, à Cloud Foundry en particulier, aux containers, aux microservices et à DevOps. Quels sont selon vous les évolutions les plus importantes, en termes de technologies et d’organisation des équipes IT ? Plus précisément, quelles sont les évolutions du catalogue Pivotal ?

Cornelia Davis : J’aimerais commencer par DevOps et vous livrer quelques éléments d’historique. J’ai rejoint Pivotal lorsque cette spin-off a été créée NDLR par VMWare et EMC [en 2013]. Je viens d’EMC où je travaillais déjà sur le PaaS. Ce qui est intéressant dans la façon dont nous avons amené le PaaS sur le marché, c’est précisément tout ce qui tourne autour de DevOps et des différents personas. Traditionnellement dans l’IT, nous avions des développeurs qui travaillaient sur le code et qui le transmettaient aux équipes opérationnelles pour qu’elles prennent le relais, construisent et configurent l’architecture pour ce code, qu’elles le déploient et l’exécutent en production. De nombreuses organisations fonctionnaient comme cela et le développement se situait toujours à l'extérieur. Maintenant, nous avons bâti le PaaS de telle façon que les applications puissent être déployées sur la plateforme à travers un contrat très clairement défini. Par contrat, j’entends évidemment les API - quels sont les appels d’API que vous mentionnez dans le contrat - mais je veux également parler de la façon dont les équipes travaillent ensemble, la façon dont elles communiquent et se transmettent le travail les unes aux autres, etc. Il s’agit de comprendre très clairement si nous voulons rendre les équipes chargées des applications auto-suffisantes et remarquez bien que je parle des équipes chargées des applications et pas seulement des développeurs. C’est-à-dire des développeurs ET des opérationnels chargés des applications. Et de l’autre côté, nous avons les équipes chargées de provisionner la plateforme, de faire du développement et des opérations pour la plateforme.

Qu'entendez-vous par rendre les équipes des applications auto-suffisantes ?

Nous avons examiné très attentivement la situation pour nous demander ce dont les équipes des applications avaient besoin pour être auto-suffisantes. Car à chaque fois qu’elles doivent parler à l’équipe chargée de provisionner la plateforme - elle aussi composée de développeurs et d’opérationnels - les choses ralentissent, il y a des problèmes de communication et ainsi de suite. A travers le contrat dont je parle, il y a donc un ensemble de choses que les équipes des applications peuvent simplement utiliser selon leurs besoins sans avoir à soumettre un ticket pour faire une demande à l’équipe chargée de la plateforme. Tout est en self-service et cela a rencontré un énorme succès. Ainsi, les opérationnels de la partie applications n’ont pas à se préoccuper des serveurs. Dans le cadre du contrat établi, ils monitorent les applications et si celles-ci sont très sollicitées, ils peuvent les faire passer à l’échelle sans avoir à demander à l’équipe de la plateforme de faire quoi que ce soit. Ils disent simplement : « J’ai besoin de davantage de capacité pour l’application ». Ils peuvent le faire tant qu’ils restent dans les quotas de leur contrat. Si quelque chose se passe mal avec l’une des applications dont ils s’occupent, ils peuvent la redémarrer eux-mêmes, ils n’ont pas besoin de demander à l’équipe de la plateforme de le faire. Ils ont un contrôle complet sur tout ce qui se passe avec cette application. Voici comment nous avons conçu notre PaaS Cloud Foundry. De son côté, l’équipe des développeurs et des opérationnels chargée de la plateforme se consacre entièrement au développement et aux opérations de la plateforme. Ce contrat entre les deux équipes a permis à nos clients d’accomplir d’énormes changements en termes d’efficacité et de réduction de coûts. Et c’est probablement ce qui leur a apporté le plus de succès. Je suis intervenue il y a déjà deux ans sur ce sujet lors du DevOps Enterprise Summit de Londres. NDLR : une conférence bi-annuelle organisée par [Gene Kim, auteur du livre Phoenix Project. La session de Cornelia Davis sur DevOps Enterprise Summit s’intitulait « DevOps : Who does what ? »]

Pour rappel, quels sont les environnements de clouds privés ou publics sur lesquels fonctionne Cloud Foundry ?

Notre PaaS fonctionne au-dessus d’AWS, de GCP, d’Azure, de VSphere et d’OpenStack. Nous supportons aussi quelques autres environnements que des communautés ont construits. Cela dit, OpenStack est sur le déclin, nous ne voyons plus personne investir vraiment dans cette direction. Il y a 5 ans, nous avons vu des gens quitter vSphere pour OpenStack et maintenant, nous en voyons qui ont testé OpenStack revenir vers vSphere.

Avez-vous des exemples de clients ayant accompli ce que vous décrivez sur DevOps ?

Nous en avons de nombreux. L’opérateur de télécommunications T-Mobile, par exemple, a accompli une très importante transformation. Et une grande partie de cela est venue de la façon dont ils ont fait évoluer leur IT. L'équipe Platform Engineering de T-Mobile est intervenue sur la conférence Kubecon de Seattle en décembre 2018 pour parler de Kubernetes et de ce qu’ils font avec PKS, Pivotal Container Service. Ils avaient un PaaS Cloud Foundry depuis 4 ans - plateforme bâtie avant la sortie de Kubernetes - et ils se sont réorganisés avec beaucoup de succès en mettant des applications en production pour le lancement de l’iPhone 10. Ils ont expliqué tout ce qu’ils avaient appris en déployant la plateforme Cloud Foundry, sur la façon de former les équipes respectivement chargées des applications et de la plateforme et de supporter ce type de contrat. Ils ont expliqué qu’ils avaient tellement appris dans ce domaine qu’à la suite de cette expérience, ils appliquaient maintenant les mêmes enseignements à la façon dont ils déployaient Kubernetes en tant que plateforme.

A propos de Kubernetes, Pivotal a progressivement renforcé ses capacités de gestion des clusters Kubernetes en production avec sa solution PKS (Pivotal Container Service).

Oui. La première chose que je veux rappeler, c’est que notre plateforme Cloud Foundry est basée sur les containers depuis 6 ou 7 ans. Les images Docker n’existaient pas, alors nous avons conçu les droplets, c’est à peu près équivalent. Kubernetes n’existait pas non plus mais notre moteur d’orchestration, Diego, s’approche beaucoup de ce qu’il fait. Nous avons bâti tout cela essentiellement parce que les créateurs techniques de Cloud Foundry venaient de Google où ils faisaient des containers. Ils ont rejoint VMware où Cloud Foundry a été originellement incubé avant le spin off de Pivotal. Ils ont apporté tout ce qu’ils savaient sur les containers. Nous avons donc cette technologie depuis toujours sans laquelle nous n’aurions pas pu disposer des capacités qu’elle apporte, de son efficacité et de sa stabilité. Les containers sont un élément essentiel de ce type de plateforme. Cloud Foundry est sur le marché depuis plus de six ans et elle est idéalement adaptée aux applications natives pour le cloud. C’est-à-dire tout ce qui est moderne, quand vos applications sont stateless et que les liens avec les services stateful comme les bases de données ou la gestion des files de messages [message queues] sont séparés. Vous n’utilisez pas de stockage local, vous concevez vos applications de telle façon que si l’une des instances - sur une dizaine d’instances - tombe, cela ne pose aucun problème, on les démarre sur de nouvelles machines. Mais ces applications doivent être écrites d’une certaine façon pour le permettre et pour être déplacées si facilement. Et c’est le type d’applications avec lesquelles nos clients ont eu le plus de succès sur les 5 ou 6 dernières années. Il peut s’agir d’applications nouvellement développées, mais aussi d’applications qui avaient une bonne architecture et sur lesquelles nous les avons aidés à faire de petits ajustements pour les rendre un peu plus « cloud natives ».

Sur ce sujet, vous avez récemment publié un ouvrage qui décrit l’architecture sur laquelle doivent reposer les applications clouds pour être facilement déplaçables NDLR : « [Cloud native patterns » chez Manning].

J’insiste toujours sur le fait que le cloud natif est hautement distribué et en constante évolution. C’est fondamentalement ce dont il s’agit. Et pour pouvoir gérer des applications hautement distribuées qui changent en permanence, il faut obligatoirement s’appuyer sur des containers. Maintenant, lorsque vous demandez aux grandes entreprises quelle est la proportion de leurs charges de travail qu’elles considèrent commet étant natives cloud, elles répondent 10 à 15%. Ce n’est pas surprenant parce qu’elles ont des applications écrites il y 10 ou 20 ans. Il y a environ 3 ans, nos clients qui avaient le mieux réussi dans la mise en oeuvre de Cloud Foundry ont commencé à nous dire : « vous nous avez aidé à faire des choses extraordinaires sur 10 à 15% de nos workloads. Aidez-nous maintenant à faire la même chose avec les 90 ou 85% restants ». C’est à ce moment-là que le moteur d’orchestration de containers Kubernetes a émergé sur le marché en étant beaucoup plus proche d’une abstraction d’infrastructure que d’une abstraction applicative. Or, rappelez-vous, un PaaS, cela concerne avant tout les applications. Ces équipes ne doivent absolument pas se préoccuper d’infrastructure. Mais si vous regardez les applications les plus anciennes, elles sont un peu plus exigeantes sur leurs besoins en infrastructure. Donc Kubernetes est une abstraction qui leur donne un peu plus d’accès à l’infrastructure. Et nous voyons cela comme une opportunité pour contrôler davantage l’infrastructure. Et c’est justement ce que demandent justement les applications plus anciennes. Et c’est alors que nous avons commencé à l’expérimenter avec PKS.

Vous saviez que vos clients allaient recourir à Kubernetes...

Cela dit, nous avons un avantage concurrentiel car notre plateforme, entièrement basée sur les containers, dispose aussi avec Bosh d’une couche située à bas niveau et qui est entièrement destinée à gérer notre plateforme. Cette dernière comporte une douzaine de composants de différentes natures - la machine où s’exécute les charges de travail, l’agrégateur de logs, l’outil de monitoring, le terminal d’API... - tout un ensemble de composants. Ce que fait Bosh, c’est de s’assurer que la plateforme tourne, pour que les upgrades puissent se faire, etc. Nous utilisons donc Bosh pour gérer le cycle de vie des clusters Kubernetes et de les automatiser. Car si vous vous penchez un peu sur Kubernetes pour comprendre son architecture, la mise en route des clusters était très manuelle, comme l’explique Kelsey Hightower dans son tutoriel « Kubernetes the hard way ». Et jusqu’à très récemment, il n’y avait aucun système pour manager Kubernetes. Vous deviez créer le vôtre. Et c’est ce que nous pouvions faire. Nous avons pu prendre les charges de travail en production sur 5 ans sur notre PaaS et mettre en oeuvre Bosh pour fournir des clusters Kubernetes. Et le fait d’automatiser les clusters Kubernetes, c’est ce qui permet de faire du multi-clusters. Si ce n’est pas automatisé, vous ne pouvez pas gérer manuellement une centaine de clusters. Mais si vous avez une gestion du cycle de vie entièrement automatisée pour les clusters, vous pouvez alors en avoir des centaines.

Vous avez déjà eu l'occasion d'insister sur l’intérêt du multi-cluster. Pouvez-vous revenir sur ce point avec un exemple ?

Oui, c’est très utile d’avoir de multiples clusters. Quand nous avons commencé à en parler, il y a un peu plus de deux ans, nous étions pratiquement les seuls. Il y avait très peu de monde qui le faisait à part quelques cas notables comme la marque de mode Zalando, spécialisée dans le e-commerce qui est intervenue en mai 2018 sur la Kubecon EMEA. C’était une exception. Kubernetes est utilisé sur l’ensemble de leur plateforme de commerce électronique avec deux clusters pour supporter le développement, une demi-douzaine de clusters pour le test et, en production, près d’une centaine de clusters Kubernetes. Chaque composant de la plateforme s’exécute sur son propre cluster, ce qui permet à l’équipe chargée des applications d’être complètement autonome, parce que la configuration du cluster change en fonction de ses charges de travail. Rappelez-vous ce que je disais, les différents workloads doivent avoir davantage de contrôle sur l’infrastructure. C’est ce que vous obtenez en configurant vos clusters Kubernetes. Cela permet ainsi à chaque équipe d’avoir une configuration différente. Si quelque chose se passe mal avec un cluster, les autres fonctionnent encore. Alors que si la totalité de la plateforme e-commerce tourne sur un seul cluster, l’ensemble tombe en cas de problème. Et donc, en 2018, certains utilisateurs précoces parmi les entreprises ayant un profit très technologique avait déjà bâti de l’automatisation autour de leurs clusters Kubernetes. Et ce que j’ai trouvé intéressant sur la Kubecon de Seattle, en décembre 2018, et que je n’avais jamais vu auparavant, c’est qu’il y avait tant de monde qui commençait à parler de multi-clusters que cela devenait maintenant un courant dominant. Ce qui était un différentiateur pour nous allait donc cesser doucement de l’être. Ce que j'ai trouvé également intéressant, c’est que la communauté open source s'engageait sur le sujet avec Cluster API.

Qu'est-ce qui se prépare avec Cluster API ?

Cluster API est similaire à ce que nous faisons avec Bosh. En fait, c’est une petite part de ce que nous faisons avec Bosh, mais c’est une part critique. Et nous travaillons avec Heptio qui a été racheté par VMware [en novembre 2018]. Heptio a été créée par deux fondateurs de Kubernetes, Joe Beda et Craig McLuckie, qui en étaient le CEO et le CTO. Ils étaient une petite centaine de personnes, principalement des consultants Kubernetes, les meilleurs des meilleurs dans le domaine de Kubernetes. Un grand nombre d’entre eux sont très engagés dans des projets open source dont Cluster API. Nous travaillons avec eux pour réunir le meilleur de Cluster API et de Bosh pour la gestion des clusters Kubernetes et cela va être extraordinaire. Cela inclut le multi-clustering qui est un espace d’innovation énorme chez Pivotal. Maintenant que Kubernetes est devenu tellement fondamental sur le marché, nous l’adoptons de plus en plus dans notre plateforme PaaS que nous faisons constamment évoluer. Mais nous le faisons de telle façon que… Diego est le 2ème moteur d’orchestration, il a remplacé le DEA [NDLR : droplet execution agent]. Lorsque nous avons procédé à ce remplacement, nos clients ne s’en sont pas aperçus, il n’y a pas eu de migration, pas de disruption. Les clients ont simplement commencé à déployer Diego et ils ont pu faire tourner les deux pendant un temps et à un moment donné, ils ont simplement arrêté le DEA. Ce n’est pas ainsi que se présente Kubernetes et tous nos clients doivent passer par une migration. Et les migrations sont pénibles.

Function Service figure parmi les offres les plus récentes de Pivotal. Pouvez-vous nous en parler ?

Nous avons commencé à la construire il y a environ deux ans. Au sein de Pivotal, nous avons le framework Spring et c’est principalement l’équipe d’ingénierie de Spring qui a démarré le travail sur Function service. Au départ, c’était une couche d’abstraction qui permettait d’écrire du code qui puisse aller sur AWS Lambda ou Google Cloud Functions. Mais en fait, nous avons ensuite commencé à bâtir le moteur de Function en tant que service. Il est destiné à ces petites fonctions qui s’exécutent en étant principalement déclenchées par les événements, il comporte donc aussi un bus d’événements. Depuis le début, nous avons utilisé Kafka et RabbitMQ et d’autres choses de ce genre pour la gestion d’événements. Et, au départ, nous construisions le moteur qui exécutait ces fonctions au-dessus du PaaS. Mais, lorsque Kubernetes a commencé à émerger, il s’est produit quelque choses d’intéressant. Rappelez-vous deux choses : d’une part, les gens s’intéressent de plus en plus au multi-cluster, d’autre part, Kubernetes est une abstraction pour l’infrastructure. Les développeurs ont donc besoin d’une abstraction de plus haut niveau et c’est quelque chose dont on entendait de plus en plus parler. Et en février 2018, Google a approché Pivotal en disant que Kubernetes devenait un standard de l’industrie, ce avec quoi nous étions d’accord, et qu’ils souhaitaient développer une nouvelle abstraction développeur au-dessus, un sujet que nous connaissions bien avec Cloud Foundry. Et nous avons débuté un partenariat. En juin suivant, nous l’avons annoncé publiquement sous le nom de Knative. Et notre service Function est construit au-dessus de Knative, lui-même bâti au-dessus de Kubernetes. Cela dit, Knative est quelque chose de relativement bas niveau. Cela nous donne des primitives permettant de bâtir Pivotal Function Service, PFS, qui est vraiment simple pour exécuter des fonctions en réponse aux événements. Le service est actuellement en version bêta. Ainsi donc, un grand nombre de nos innovations produits exploitent Kubernetes au-dessus duquel, désormais, nous apportons l’expérience développeur que nous avons mis en oeuvre depuis l’origine de Pivotal. C’est une grande partie de notre stratégie.

Pour conclure, quel est le conseil le plus important que vous donneriez aujourd'hui aux départements informatiques ?

Le principal conseil que je donnerais nous fait revenir au 1er point abordé, DevOps. Je leur dirais : Commencez à penser ou à repenser la façon dont vous faites de l’informatique pour devenir des fournisseurs de produits. Nous appelons cela « platform as a product ». Parce que, traditionnellement, l’IT intervient un peu comme un cuisinier travaillant sur commande. De telle façon que l’équipe de développement vient et dit : « j’ai besoin de cela et de cela, s’il vous plaît, donnez moi ça et ça ». Et elle attend, parce que à chacune de ses demandes correspondent souvent des conditions et des exigences uniques : un logiciel particulier, un matériel particulier, etc.

Mais il est clair, si l'on considère le succès d’un Amazon, que les gens peuvent bâtir des choses incroyables à partir d’un menu fixe. Le conseil le plus important que je donnerai aux organisations IT est donc le suivant : votre IT doit commencer à agir comme Amazon Web Services qui délivre une plateforme sous la forme d’un produit. Vous devrez alors publier une feuille de route et si vos utilisateurs ont besoin de quelque chose que vous n’avez pas dans votre plateforme, ils devront faire une demande. Exactement comme Amazon qui reste à l’écoute de ce dont ses utilisateurs vont avoir besoin par la suite et propose de nouveaux produits et des améliorations aux produits existants. Mais ils ne le font pas parce que quelqu’un a dit qu’il s’agissait de la priorité la plus urgente. Non, ils le font parce qu’ils ont une feuille de route sur leur produit, exactement comme sur n’importe quel autre produit. C’est ce que nous appelons la plateforme vue comme un produit. Et je pense que c’est le changement le plus important et le plus stimulant que les équipes IT peuvent faire et qui fera complètement évoluer la façon dont se fait l’IT : « Platform as a product » !