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 ?
Tout d’abord, commençons par définir ces deux technologies dans notre contexte :
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.
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 :
À 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.
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.
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.
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).
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).
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.
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.
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é ».
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.