On peut tout migrer sur Kubernetes, oui, mais à quel prix ? Une migration n’est jamais aisée, surtout à l’échelle d’un Système d’Information, avec ses adhérences, ses contraintes de sécurité, son legacy, ses organisations en silos, etc.
Une migration a un coût, requiert des experts, des formations, des bonnes pratiques, une restructuration des équipes et une organisation dédiée à la migration.
Nous avons tous en tête plusieurs success stories de sociétés qui ont migré sur Kubernetes dans l’optique de migrer sur le cloud. Elles y sont arrivées, comme toujours, mais souvent dans la douleur et avec quelques désillusions …
Cet article propose une méthode permettant d’appréhender plus sereinement une migration vers Kubernetes.
Avant d’appréhender une migration vers Kubernetes, il faut se poser la question : pour quel objectif ? Il n'y a pas de bonnes ou de mauvaises réponses ; cela dépend de son contexte. Il faut cependant arriver à différencier les objectifs des moyens à mettre en œuvre. S’il y a trop d’objectifs, il faut les prioriser en choisissant les plus importants.
Par exemple : “Ma stratégie est d’aller sur du Kubernetes dans le cloud. Je veux quitter mon datacenter on-premises et j’ai besoin de réduire les coûts inhérents au run de mon SI”.
Tous ces éléments sont louables et surement pertinents, mais il faut définir le principal objectif. Un seul objectif permet de décider de la complétude de cette migration et de son succès. Nous parlons ici de Definition Of Done.
Dans l’exemple cité, l'intention serait : “J'ai migré toutes mes applications de mon Datacenter vers un Cloud Provider. J’ai pu piloter mes coûts tout au long de la migration.”
Penser petit et simple pour voir grand par la suite.
Rappelons les principes directeurs de l’orchestrateur Kubernetes.
Kubernetes est l’orchestrateur de conteneurs incontournable pour l’hébergement d’applications. L’approche GitOps facilement couplée à Kubernetes permet un déploiement continu. Kubernetes offre enfin une scalabilité “automatique” et de facto la résilience des applications.
La catégorisation des applications est une approche empirique. Elle consiste à segmenter les applications du Système d’Information sur plusieurs critères factuels et de déterminer une complexité.
Cette première étape donne un état des lieux clair de toutes les applications. Celui-ci révèle des besoins transverses comme la gestion du stockage, les flux réseaux externes, les contraintes de sécurité, etc. Ces besoins sont complexes à traiter s’ils ne sont pas vus en amont de la migration.
Définissons ici une application : c’est un composant packageable et déployable. Un produit ou une feature est ainsi constitué de plusieurs applications.
Dans l’optique de migrer sur Kubernetes, on parlera d’applications conteneurisables.
Établissons une notation des applications. Nous préférons une approche en taille de T-shirt plutôt qu’un système de scoring. La taille S définit une application simple à conteneuriser, M/L moyenne ou complexe et XXL, très complexe. Keep it simple!
En général, dans un Système d’Information, les applications les plus récentes sont de taille S ou M/L alors que sur les applications legacy sont de taille XXL. Mais tâchons de définir des critères plus concrets.
Isolation/Adhérence
Ressources
Installation/Déploiement
Observabilité
Sécurité
Scalabilité
SLA
Avec notre système de notation, une application répondant à tous ces critères aura une taille S.
Quant à une application de taille M/L, elle y répondra en partie. Elle peut répondre à ces typologies :
Les applications ne répondant à aucun des critères cités sont de taille XXL. Voici des cas d’usages, par exemple :
Avec cette catégorisation, on peut facilement jauger qualitativement une application.
L'état des lieux d’un Système d’Information se fait par le biais de différentes méthodes et d’outils de gestion de ressources. Il faut parfois s’armer de patience et faire du retro engineering, voire de l’archéologie !
La CMDB (Configuration Management DataBase) reste l'incontournable référentiel du Système d’Information. La CMDB n’est souvent pas à jour, mais elle constitue tout de même un référentiel à un instant T.
Il existe aussi des outils de scan d’infrastructure. Ils calculent les ressources allouées pendant une période donnée (CPU, RAM, stockage, etc.).
Il ne faut pas oublier également les flux réseau inter-applications. Si l’on ne dispose pas de référentiels, il peut être aussi utile de disposer d’outils de scan réseau.
Les résultats des scans sont à traiter avec un œil critique car ils ne sont pas exhaustifs. Chaque application est unique, a sa propre période d’activité et ses périodes de fortes charges.
Les documents d’architecture technique, d'architecture logicielle, les manuels d’installation, les dépôts de sources d’Infrastructure As Code ou les outils de configuration sont autant de moyens supplémentaires pour en apprendre un peu plus sur les applications.
Enfin et surtout interroger les sachants : les ops, les devs, les leads, les testeurs, les intégrateurs, les architectes, la sécurité, les PO et tous ceux et celles qui ont participé au build et au run de l’application.
Nous avons maintenant établi notre état des lieux. Nos différentes applications sont catégorisées de la plus facile à migrer à la plus complexe.
Il est à présent temps de choisir quelques applications à migrer (1% de la taille du parc). On choisira, par souci d’efficacité, par efficacité des applications sur les deux premières catégories (S et M). Nous recommandons d’avoir plusieurs applications de taille S et au moins une application de taille M.
Il y a peut-être des irritants, des dysfonctionnements sur les applications à migrer. La “Definition Of Done” de la migration ne va pas forcément y répondre. La migration ne résoudra pas tous ces problèmes : on migrera “iso bugs”. Il conviendra ainsi de mettre en place des points de mesure précis et corrélables avant / après migration. Ces métriques seront aussi bien techniques que business (CPU, RAM, taux d’erreurs applicatives, etc.).
Nous devons estimer le chiffrage de la migration des applications choisies et élaborer la roadmap correspondante. Ce premier chiffrage servira d’abaque pour la suite de la migration à l’échelle.
Une décision stratégique s’impose également pour les applications moyennes à complexes. Est-il possible de transformer ces applications pour les rendre plus simples à migrer ? D’envisager dans certains cas du serverless ?
Est-il au contraire possible de ne pas migrer certaines applications et de les décommissionner ? Ce cas est souvent minimisé, il est néanmoins nécessaire de se poser la question et de pouvoir challenger la réponse. Dans les autres cas, il faudra accepter une migration longue et généralement coûteuse.
Nous allons choisir la solution Kubernetes adaptée à notre besoin et nos contraintes. Elle pourra être managée sur du Cloud, on-premises ou hybride.
C’est parti pour le design de la plateforme, la mise en place des plans de tests et des déploiements. Une fois les premières briques posées, le design de l’architecture des applications choisies peut démarrer.
Des points d’étapes à chaque sprint sont positionnés afin de suivre ces migrations au niveau équipe et au niveau pilotage. Nous suivons les coûts, l’avancement et les points de blocage. Nous encourageons le partage et les démonstrations.
En avançant ainsi pas à pas, nous affinons la catégorisation des applications et notre planning de migration. Nous montons également en connaissance sur Kubernetes et ses bonnes pratiques. Nous améliorons sans cesse le socle technique et notre apprentissage. La solution Kubernetes reste complexe : il faut maîtriser beaucoup de stacks techniques en incluant la sécurité et le réseau.
Un retour d’expérience devra être communiqué en fin de migration. Il s'ensuivra une revue de la catégorisation, du chiffrage et de la timeline.
Avec cette méthode, nous avons pu faire un état des lieux, catégoriser nos applications et décider lesquelles devaient migrer. Nous avons avancé de manière itérative et nous nous sommes améliorés en continu.
Forts de notre première expérience, nous pouvons mieux appréhender et planifier notre migration à l’échelle et amorcer une réorganisation sine qua non. Cette nouvelle organisation prendra en compte la conduite du changement, des formations, des sessions de vulgarisation à l’échelle de l’entreprise, etc.