Kubernetes est intéressant, mais pas pour les raisons auxquelles tout le monde pense habituellement. Pendant un temps, les gens ont adhéré à Kubernetes parce qu’ils pensaient que la plateforme open source automatisant le déploiement, la mise à l'échelle et la gestion des applications conteneurisées serait une autre technologie cloud géniale, un peu comme OpenStack (sans tous ses problèmes). Mais la réalité de Kubernetes n’a pas été à la hauteur des promesses. La plateforme n’a pas été pas non plus, loin de là, le remède magique au lock-in, ni la réponse à la demande de portabilité débridée. Au contraire, comme je l'ai écrit, Kubernetes est devenu le nouveau Linux. Ou, peut-être plus exactement, un nouveau serveur d'applications, comme l'a suggéré Alexis Richardson, le CEO de Weaveworks, lors d'une interview. Au lieu de laisser les entreprises essayer de créer leurs propres cloud, ce dernier propose de « laisser les équipes de développement gérer les clusters Kubernetes provisoires qui sont comme des serveurs d'applications ». Mais, qu'est-ce que cela signifie exactement ?

Jargon technologique et charabia

Alexis Richardson et moi-même étions censés parler du multicluster Kubernetes sur bare metal avec des microVM alimentées par Firecracker. Au bout de cinq secondes, tout est devenu flou pour moi, ce qui posait problème puisque je menais l’interview téléphonique. « En plus d'être adapté au scénario edge, le mode mixte permet d'améliorer considérablement l'efficacité de la gestion des clusters Kubernetes sur bare metal en déplaçant les nœuds du plan de contrôle des serveurs bare metal dédiés vers les microVM, ce qui réduit considérablement le nombre total de nœuds requis dans un pool bare metal ! », a-t-il lancé, faisant référence à un billet de blog posté par Weaveworks sur le sujet.

J'essayais désespérément de me sentir concerné, étant donné que mon employeur (AWS) avait livré Firecracker en tant que projet open source. Mais je n'y arrivais pas. Je ne pouvais pas m'enthousiasmer à l'idée que les opérateurs de télécommunications déploient des « applications 5G où la 'fonction réseau' (charge de travail 5G) peut être exécutée aux côtés des fonctions de signalisation, des fonctions de gestion, des applications Web et des applications client sur le même matériel avec une forte isolation et un contrôle des ressources ». Pas trop le genre de chose dont je me soucie… C’est à ce moment-là qu’Alexis Richardson a dit : « Est-ce que je suis logique ? Vous êtes toujours là ? ». J’ai pensé raccrocher en prétextant que je n’avais plus de réseau. Mais ensuite, il a déclaré que cette « solution était particulièrement efficace pour démarrer des flottes de clusters Kubernetes avec un minimum ressources ». C’est là que j’ai commencé à retrouver un peu de clarté.

Kubernetes comme serveur d'applications

Mais c'est quand il a comparé Kubernetes à Linux ou à un serveur d'applications que son propos a pris tout son sens. Ayant grandi dans la technologie des serveurs d'applications JBoss/BEA, c'est un monde que je connaissais. Un serveur d'applications est une série de fonctions génériques que l’on peut utiliser pour exécuter une application, soit en l'intégrant à l'application, soit en l'exécutant d'abord, puis en exécutant l'application par-dessus. Même si l’on n’en parle plus beaucoup, ils sont très courants dans les entreprises. Dans le modèle de serveur d'applications, le cycle de vie de l'application est associé au cycle de vie de la pile ou du cluster de l'application sur laquelle elle est exécutée. Quand on n’a plus besoin de l'infrastructure, on la ferme et on la jette. Le cloud est différent par le fait qu’il est permanent, même si les ressources qui y sont exécutées ne le sont pas forcément. L'idée du cloud est de laisser quelqu'un s'en occuper et qu'il persiste au-delà de ses besoins d'utilisation. Au lieu d’inciter les entreprises à construire leurs propres clouds, M. Richardson propose de « laisser Amazon, Google et Microsoft gérer les clouds et de confier à leurs équipes de développement la gestion des clusters Kubernetes éphémères, assimilables à des serveurs d'applications ».

Implicitement, la proposition d’Alexis Richardson sur l’usage de Kubernetes comme serveur d'applications véhicule un message puissant pour l’IT d'entreprise : il invite l’IT à libérer ses équipes de développement. « Je pense que c’est beaucoup mieux de laisser les équipes d'application individuelles mettre en place leur propre infrastructure à l'aide de clusters Kubernetes plutôt que de provisionner des ressources de cluster d'entreprise auprès d’une IT centralisée », a-ti-il fait remarquer. Au lieu de mettre en place un cluster Kubernetes massif en obligeant les équipes de développement de s’y alimenter, une meilleure stratégie consiste à encourager « la gestion d’applications à usage unique ou de groupes d'applications par à un petit groupe de personnes, voire à une seule personne. La meilleure pratique pour l'utiliser est d'avoir beaucoup de clusters Kubernetes, beaucoup d'applications soutenues par Kubernetes, plutôt que d'essayer de le gérer comme un cloud ».

Une réponse à la complexité de Kubernetes

Cette proposition va à l'encontre de l'idée reçue selon laquelle Kubernetes est compliqué et difficile. C'est peut-être vrai. Mais cette difficulté vient souvent du fait que l'on essaie de traiter Kubernetes comme un cloud centralisé, au lieu de permettre à des équipes plus petites d'utiliser des fonctionnalités semblables à celles d'un serveur d'applications. C'est une question d'autonomie, explique encore M. Richardson : « Les équipes de développement seront productives si elles sont autorisées à s'approprier les opérations. Elles doivent savoir qu'elles peuvent réparer les choses en cas de problème. Sinon, elles ne peuvent pas assumer la responsabilité de la sécurité et des performances. C'est ce que nous faisons chez Weaveworks. Kubernetes et GitOps ont été d'une aide précieuse, car les équipes de développement peuvent faire de l'infrastructure, du cluster, de la pile, et peuvent tout mettre en route et tout arrêter à volonté. Elles peuvent provisionner ces ressources à la demande. Autrefois, les développeurs démarraient et arrêtaient Tomcat à volonté. Ils ne demandaient pas la permission à quelqu'un de le faire, n'est-ce pas ? C'est ainsi que fonctionne Kubernetes. Et cela fonctionne exactement de la même manière dans l'entreprise ».

Le point de vue du CEO de Weaveworks peut avoir un effet incroyablement libérateur pour l’IT moderne. C'est aussi un excellent moyen de donner un sens au jargon technologique à l’origine de notre conversation. « Dans le billet de blog que j'ai partagé avec vous, nous montrons simplement que nous pouvons le faire plus efficacement pour des cas d’usage plus variés, y compris les charges de travail à la périphérie », a-t-il déclaré. Je me demande encore pourquoi il n’a pas commencé notre conversation en disant exactement cela !