Il faut avant tout déterminer le périmètre de la migration en auditant l'existant:
Par exemple, mon infra est composée de 4 APIs A, B, C et D, et je décide de migrer A, B et C sur Kubernetes.
Si la réponse paraît assez intuitive, il est essentiel de prendre le temps d’y réfléchir en équipe car de là, découlent toutes les actions et la définition des priorités du projet.
Pour définir les véritables objectifs, vous pouvez commencer par vous poser (entre autres) les questions suivantes :
À partir de ces réponses, est-ce que mes objectifs sur le projet sont :
Il est important de définir 2 à 3 objectifs maximum pour ne pas s’éparpiller sur les sujets et rester focus sur l’essentiel.
Un bon objectif s’accompagne toujours d’un indicateur de réussite.
Exemples de bons indicateurs :
|
Objectif |
Date cible |
État |
Indicateur |
|
En tant qu’Ops j’ai migré l’API avocado |
03/12 |
OK / KO ? |
- les anciens environnements sont éteints - en tant que développeur j’utilise le nouveau flux de déploiement |
|
En tant qu’Ops je sais recréer un environnement de staging en moins de 10 minutes |
15/12 |
9 minutes |
temps de création d’un environnement de staging |
À cette étape, on peut commencer à définir les jalons de la migration, c’est-à-dire les étapes principales sur lesquelles il faut travailler avant de pouvoir migrer. Chaque situation est spécifique, mais voilà un exemple de jalons classiques pour une migration Kubernetes :
|
l’équipe est au courant de la migration |
|
j’ai une procédure de test |
|
j’ai dockerisé mon app |
|
j’ai déployé mon app dans le cluster Kubernetes |
|
j’ai un plan de migration |
|
j’ai des logs en place pour le monitoring |
|
j’ai fait les tests de montée en charge |
|
J’ai fait la recette de la prod |
|
D-Day : je migre sur Kubernetes |
De la même manière que pour les objectifs, il faut être capable de définir comment on valide chacun de ces jalons et leur donner une mesure précise.
Exemple sur le dimensionnement :
|
Jalon |
Date cible |
État |
Indicateur |
|
ETQOps j’ai fait les tests de montée en charge |
18/04 |
OK / KO ? |
Mon infra tient X utilisateurs en Y temps* |
*avec X et Y à définir selon les besoins de l’équipe
Une fois les jalons déterminés, il s’agit de les planifier. Étape délicate car il faut anticiper au maximum les problèmes qu’on sera susceptible de rencontrer, prévoir suffisamment de temps pour chaque étape tout en mettant du rythme pour ne pas démotiver les troupes !
Deux éléments clés pour cette partie :
Il existe milles manières de représenter ce planning, avec un niveau de complexité et de détail plus ou moins élevé. Je vous en partage une :
Ici, le niveau d’information est assez épuré (on présente seulement les jalons) mais la représentation permet de voir d’un coup d’oeil où on en est à date. Est-qu’on est dans les temps ? Est-ce qu’on a pris du retard ? Quel est l’impact sur les autres jalons et le projet au global ?
Il est possible d’afficher davantage de détails, par exemple :
… etc
Une fois le plan de vol en place, reste à passer au niveau de granularité le plus élevé : le découpage en tâches.
Plus les tâches techniques seront découpées finement, plus elles feront ressortir les problématiques techniques et nous pousserontt à nous poser les bonnes questions et à identifier rapidement les dépendances externes.
Pour appréhender les (très) nombreuses tâches qu’implique une migration Kubernetes, travailler en mode agile (avec des sprint d’une à deux semaines) permet d’entamer ce grand chantier par petits bouts tout en ayant des guidelines (les jalons) précises.
De nombreux outils permettent de créer et gérer ses tâches au quotidien, notamment Trello (simple et intuitif) ou JIRA (plus complet et complexe).
Il faut maintenant faire les tâches ! Il est important de faire un suivi quotidien et de mettre à jour les outils de suivi, au niveau micro (les tâches) et macros (les jalons) pour toujours être au clair sur :
Sans aucun doute le facteur de réussite le plus important.
Pour constituer une équipe solide, les questions à se poser sont les suivantes :
Si le niveau d’expertise n’est pas suffisant ou s’il n’y a pas d’équipe Ops en place, on peut toujours se faire aider par des acteurs extérieurs : par des équipes expertes de Kubernetes, par des freelances...
Le deuxième réflexe à avoir en amont du projet est d’identifier les acteurs clés dans l’entreprise (PM/PO, Lead Dev, Sponsor...) et les préparer à la migration Kubernetes : quel est son intérêt, quelle est la timeline, sur quels points on aura besoin de leur aide.
Anticiper au maximum les dépendances externes permet de les lever rapidement et de ne pas se retrouver bloqué pendant plusieurs jours ou plusieurs semaines au milieu du projet.
Quelques exemples :
Dans une optique DevOps, il est important d’impliquer les développeurs le plus tôt possible : la migration va les impacter et changer leurs habitudes de travail. Plus tôt on les inclut dans le projet, en communiquant, en les formant, en produisant de la documentation qu’ils pourront utiliser, plus la transition sera simple.
Se lancer sur une migration Kubernetes, c’est souvent ouvrir une douzaine de boîtes de Pandore simultanément. Et face à toutes ces problématiques qui remontent soudainement, on a vite tendance à s’enfoncer dans les détails techniques. Attention à prendre du recul sur les sujets, à se remettre en question et à se challenger en permanence sur :
Un bon moyen de prendre du recul est de se faire challenger régulièrement (à chaque sprint par exemple) par une personne (tech ou non-tech) qui ne prend pas part au projet sur le plan technique, mais qui connaît bien les enjeux et les problématiques (le CTO, un coach agile...).
La théorie est simple, la pratique l’est moins : une migration Kubernetes implique d’avoir de longues discussions sur les enjeux techniques, une architecture claire en tête, de savoir comment gérer les imprévus et les dépendances, contourner ou résoudre tel problème technique… et autres joies du quotidien d’un Ops ! Le message à retenir de cet article, c’est qu’avoir des outils clairs de gestion de projet est certes important, mais que l’humain derrière est essentiel : motiver l’équipe, impliquer les développeurs, se challenger, former et communiquer sont les clés d’une migration Kubernetes réussie !