Sommaire
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.
Bien définir ses objectifs de migration
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.
Kubernetes est un moyen et non un objectif
Rappelons les principes directeurs de l’orchestrateur Kubernetes.
- Kubernetes se veut agnostique des plateformes. Il faut choisir parmi pléthore de services managés proposés par les différents cloud providers ou une solution on-premises.
- C’est un orchestrateur de processus mutables à l’échelle. Le mot mutable est lâché, nous reviendrons sur l’importance de la notion de mutable plus loin dans ce plan de migration.
- Kubernetes facilite le déploiement avec son approche déclarative. L'automatisation facilite les opérations de maintenance.
- Kubernetes permet une scalabilité sur mesure de ces processus. La solution offre ainsi une optimisation des ressources.
- Kubernetes est une solution Open Source.
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.
Première étape : la catégorisation
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
- L’application s’exécute sur un seul processus
- La machine où l’application est déployée n’a pas d’adhérence avec l’infrastructure ou le réseau existant (pas d’IP dans le fichier host par exemple)
- La configuration de l’application est externalisable (variables d'environnement ou fichier de configuration)
Ressources
- L’application est légère (peu d’utilisation de CPU/RAM)
- La consommation en ressources de l'application est maîtrisée
- L’application met peu de temps à démarrer (< 60 secondes)
Installation/Déploiement
- Le package de l’application contient toutes les dépendances nécessaires pour la faire tourner
- Le package requiert peu de ressources en stockage local
- L’installation de l’application est documentée, voire automatisée
- La procédure de rollback est simple et maîtrisée
- L'application supporte les redémarrages non prévus et forcés
- On sait reconstruire l’application et la déployer
- Le nombre de composants du produit est réduit
- L’architecture du produit est modulaire
- Il y a peu d’environnements à migrer
- Il est possible de faire tourner plusieurs instances de l’application en parallèle
Observabilité
- L’application peut rediriger ses logs vers la sortie standard
- Il existe au moins un point d’accès indiquant l’état de santé de l’application
- L’application sait exposer ses métriques
Sécurité
- L’application repose sur des versions logicielles encore supportées
- L’application tourne sur un OS dont la version est à jour
- L’application sait fermer ses connections actives proprement
Scalabilité
- L’application supporte une scalabilité horizontale (plutôt que verticale)
- L’application est stateless
- L’application peut s'arrêter à tout moment (aspect mutable)
SLA
- L’application a un taux de disponibilité défini, raisonnable, mais pas très engageant
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 :
- L’application est stateful
- L'installation de l'application est moyennement ou pas documentée
- Le package de l’application a une volumétrie importante (plusieurs Go)
- Le démarrage de l’application prend de 60 à 300 secondes
- L'application nécessite une configuration spécifique sur certains paramètres systèmes
- etc.
Les applications ne répondant à aucun des critères cités sont de taille XXL. Voici des cas d’usages, par exemple :
- L’application n’est pas modifiable en l’état pour répondre aux critères précédents
- L’application a un fichier de configuration de plus de 1000 lignes. Elle n’est pas déployable facilement sur des environnements différents.
- L’application a des flux externes synchrones
- L’application n’a que très peu d’API
- C’est un produit logiciel soumis à licence (l’effet boîte noire)
- L’application requiert une OS spécifique
- C’est une application gourmande en ressources ( > à 2 CPU et 8 Go de RAM)
- Des utilisateurs se connectent à l’application à l’aide d’outils de type remote desktop
Avec cette catégorisation, on peut facilement jauger qualitativement une application.
Comment fait-on l'état des lieux ?
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.
Deuxième étape : le choix
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.
Troisième étape : l’activation
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.
Conclusion
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.
Pour tous vos besoins de migration ou de formation.
