Il était une fois, un artisan en informatique. Il aimait écrire des applications qui correspondaient à ses clients. Et ses clients appréciaient d’avoir des programmes qui répondaient à leurs besoins. Ainsi, sa réputation se fit dans tout le royaume. Toutefois, l’artisan rencontrait quelques difficultés. Chaque fois qu’il installait ses créations se posait la question de la plateforme.
Si le client voulait avoir l’application chez lui, l’artisan devait se déplacer et l’installer complètement avant de pouvoir la faire tourner. Ainsi, notre maître devait s’adapter à la plateforme cliente avec les contraintes possibles : puissance de l’infrastructure, droits d’accès, …
Si le client acceptait que l’application reste chez l’artisan, il fallait l’isoler des autres applications clientes. Bien qu’il possédait de nombreuses machines, il fallait une bonne organisation pour retrouver les applications correspondants aux clients lorsque ceux-ci demandaient des évolutions, des interventions ou des maintenances.
Bref, plus le temps passait et moins notre artisan avait de temps à consacrer à la création de nouvelles applications. La gestion des multiples configurations l’occupait de plus en plus. Notre artisan ne se retrouvait plus par rapport à ces nouvelles obligations. Comme tout passionné, il décida de regarder les solutions existantes.
Les conteneurs facilitaient un peu son travail. Ainsi, il isolait plus simplement les projets de ses clients. Notre artisan put donc reprendre son œuvre et répondre aux demandes de ses clients. Mais le temps passant, les problèmes revinrent. On ne pouvait multiplier à l’infini les conteneurs sur un serveur. Il suffisait d’installer un nouveau serveur.
Grâce à Internet, les serveurs n’avaient plus à être situés dans un même lieu. Notre artisan louait donc des serveurs dans des fermes privées. Oui, il existait des fermes de serveurs. On les appelait des clouds. Cela permettait à notre artisan de ne pas avoir à s’occuper de la gestion physique (électricité, câblage, …) de ses machines.
Mais ses clients étaient inquiets. Que se passerait-il si un serveur tombait en panne ? Notre artisan dû organiser ses journées. Avant de développer ses applications, il s’assurait que les serveurs étaient en ligne, que les sauvegardes étaient réalisées, qu’il existait des copies dans d’autres lieux, …
En cas d’incident, il se devait de réagir rapidement pour remonter une machine et installer les conteneurs après avoir réinjecté les sauvegardes. Certes, cela arrivait rarement mais ses clients l’appelaient à toute heure dès que leurs applications ne répondaient plus. L’artisan devait tout lâcher pour les satisfaire.
Encore une fois, la réponse vint d’Internet. Un guide populaire avait développé une solution pour répondre à toute heure du jour ou de la nuit aux questions de ses clients. Le guide avait de nombreux employés et chacun suivait les mêmes procédures en recherchant dans l’immense bibliothèque les bonnes références. Son astuce ? Il avait industrialisé le déploiement de ses services.
Concrètement, il possédait un carnet magique, le Kubernetes. Ce qui était écrit dans ce carnet devenait réalité. Ainsi, le guide y listait ses serveurs (nodes) loués chez le fermier. Il listait aussi les services de ses clients (deployments). Enfin, il indiquait les règles de fonctionnement des services (pods). Et comme par magie, ce qui était écrit devenait réalité.
Si un service devait être actif 24/7, il suffisait d’avoir au moins 3 pods situés sur des nodes présents dans des lieux différents. Si un client voulait que son service soit plus performant, il suffisait d’ajouter des pods et de rediriger une partie des demandes sur ces nouveaux pods. Si une machine s’arrêtait, le carnet créait automatiquement un pod sur un autre node pour respecter la règle écrite.
De temps en temps, il corrigeait les règles du carnet et négociait avec les fermiers suivant ses besoins. Mais ces dernières activités étaient devenus négligeables. Débarrassé des contraintes matérielles, l’artisan put ainsi se concentrer pleinement à son activité.