Kube is the new mainframe - Compte-rendu du talk de Désiré ATANGA à la Duck Conf 2020
Alors qu’une cinquantaine d’années séparent Mainframe et Kubernetes, Désiré ATANGA a ouvert l’édition 2020 de la Duck Conf en tentant de répondre à la question suivante : Kubernetes peut-il s’installer dans nos SI et occuper une place aussi importante que le si robuste mainframe ?
Qui se ressemble s’assemble ?
Tout d’abord, commençons par définir ces deux technologies dans notre contexte :
- Le mainframe est un ordinateur de grande puissance de traitement qui répond aux besoins de robustesse, performance et résilience requis pour l’exécution d’applications critiques. C’est une technologie propriétaire et particulièrement implantée dans les SI des organisations du monde de la banque et de l’assurance.
- Kubernetes (ou Kube ou k8s) est un orchestrateur intelligent et dynamique de conteneurs s’appuyant sur un cahier des charges (le manifeste). Cette technologie du monde open s’apparente à un automate capable de piloter le déploiement d’applications en respectant les objectifs de performance, robustesse, résistance, résilience et scalabilité définis dans le manifeste.
Même si la similarité n’est pas immédiate, un point commun se dessine entre ces deux technologies : permettre l’exécution d’applications critiques.
Dans le mainframe, la puissance et la scalabilité nécessaires à l’exécution des applications sont embarquées par le hardware. Par contre, dans k8s l’approche est différente et dans l’idéal ce sont les applications déployées qui portent la robustesse et la scalabilité au sein d’une architecture bien plus complexe que leur équivalent sur le mainframe. Une chose est sûre, l’une ou l’autre de ces technologies représente véritablement la « colonne vertébrale » du SI.
Un contexte technologique moins favorable
Il n’est pas rare d’associer au succès des technologies une dimension contextuelle (époque, tendances ou structure du marché...) qui dépend de multiples facteurs. Désiré nous propose d’analyser et de mettre en exergue la vitesse d’adoption de Kubernetes selon quatre facteurs :
- Dans les années 60, le mainframe apportait une solution aux nouveaux besoins de puissance de traitement des organisations, dans un environnement très peu concurrentiel.
- Le monde open n’a pas attendu l’arrivée de Kube pour répondre aux besoins de scalabilité, de performance et de robustesse. Il existe pléthores d’architectures, de patterns et de solutions techniques au sein d’une communauté aussi riche que dynamique.
- C’était mieux avant ! Nous sommes programmés comme averses au changement, et avons besoin d’une véritable rupture pour provoquer le glissement vers Kubernetes. En réalité, nous pouvons considérer que ce type de changement ne s’opère que lorsque « le coût du changement est inférieur au coût du statu quo ».
- Les équipes de production ont capitalisé sur une forte expérience et expertise de la technologie mainframe et ont construit de multiples outillages. Les applications y sont correctement monitorées et supervisées. Cet argument met en valeur la notion de risque, métrique cachée et intégrante du coût du changement.
À cela s’ajoute la méfiance encore avérée envers les outils open source dont la pérennité n’est pas garantie et qui, malgré un coût d’acquisition nul, comportent un risque fort identifié en matière de maîtrise et de supervision de production. Donc, le contexte favorable ayant permis une adoption logique du mainframe n’est plus tant d’actualité et rend forcément l’adoption de Kubernetes plus compliquée.
Faut-il vraiment tout remettre en question ?
Même si Désiré pense que l’adoption de Kubernetes va se réaliser, à l’instar d’indicateurs faibles comme la croissance du nombre de participants à La KubeCon ces dernières années ou la fusion de KubeCon et CloudNativeCon, au moins six croyances constituent également un frein à sa vitesse d’adoption.
Croyance #1 : Le monde open est moins robuste et moins résilient que ne l’est le mainframe.
Cette croyance reflète une habitude contestable, qui consiste à penser que les solutions d’éditeurs sont plus robustes car beaucoup plus chères. Pour autant, certaines de ces solutions sont seulement des versions packagées des outils open source et reposent sur des versions obsolètes. En terme de résilience, Kubernetes est pourtant très bien conçu et permet, entre autres fonctionnalités, de détruire et re-déployer (Destroy & Deploy) une application à l’infini, en fonction de son état de fonctionnement.
Croyance #2 : Les modèles comptables qui servent à la production des business cases de projets restent pessimistes.
Le mode de fonctionnement de Kubernetes n’est pas tout à fait compatible avec les processus économiques et comptables des organisations à ce jour. En effet, estimer ou prévoir son coût annuel d'infrastructure oscille entre un indice minimum et maximum de consommation de ressources (le cluster peut n’utiliser qu’un seul nœud comme l’intégralité de ses nœuds pendant toute une période à durée indéterminée).
Croyance #3 : Les coûts d’administration d’un cluster Open sont supérieurs aux coûts d’administration d’un mainframe.
Difficile de ne pas réfuter cette croyance lorsqu’il s’agit d’administrer un cluster de 400 nœuds manuellement. Ce pourquoi, le choix de Kubernetes passe aussi par la bascule des architectures du SI sur des standards plus flexibles et fidèles à la méthodologie « IaC » (Infrastructure As Code).
Croyance #4 : Une offre de service de l’infrastructure permet de répondre à tous les besoins de l’entreprise.
Même si Kubernetes commence à apparaître dans les services proposés par les DSI, les offres sont souvent limitées et ne permettent pas aux équipes de développement consommatrices des services de profiter de ses pleines fonctionnalités et de ses bénéfices.
Croyance #5 : La résilience applicative s’obtient en durcissant uniquement les couches d’infrastructure et les middlewares.
C’est une croyance ambigüe car au delà d’un certain seuil de criticité, même si l’infrastructure « ne tombe pas », si les applications ne possèdent pas les gènes comportementaux, elles ne bénéficieront pas des capacités de résilience de l'infrastructure.
Croyance #6 : Construire une application critique est synonyme de « aucun composant du système ne doit tomber ».
Cette croyance s’est construite autour d’un biais ces dernières années et se montre particulièrement redoutable vis à vis du concept de Kubernetes qui se base sur un ensemble de composants « bon marché ».
Mais alors, c’est quand le meilleur moment ?
Un proverbe chinois a déjà la réponse : « Le meilleur moment pour planter un arbre était il y a 20 ans. Le deuxième meilleur moment est maintenant ».
De plus, comme architecte d’expérience, Désiré recommande le développement d’applications « cloud ready » qui seront potentiellement déployées sur Kubernetes. En prenant l’habitude de concevoir - ou revoir - vos applications selon les néo-pratiques de développement (Design for failure, IaC, 12 factors, cloud-ready), vous pourrez profiter pleinement de la puissance de cette technologie et votre migration se résumerait en un mot : bascule !
Alors n’attendez pas le grand soir, et débutez dès maintenant la transition vers le Kube.