Migration des machines virtuelles après le « lift-and-shift »

J'ai eu cette conversation des dizaines de fois avec des équipes chargées de l'infrastructure. Elles viennent de terminer la migration de machines virtuelles depuis un hyperviseur hérité ou sont en plein cœur d'un tel projet. La partie la plus difficile est presque terminée. C'est du moins ce qu'elles croient.

Voici ce dont la plupart des gens ne parlent pas : la migration elle-même est la partie la plus facile. C'est tactique. Elle a un début, un milieu et une fin clairement définis. L'étape suivante, à savoir la modernisation de l'exécution de votre infrastructure, est celle où commence le véritable travail et, pour être honnête, où se trouve l'essentiel de la valeur.

Les évolutions du secteur à l'origine de ces migrations représentent une opportunité stratégique pour les infrastructures modernes. En améliorant l'efficacité des licences, l'optimisation des coûts et la flexibilité des fournisseurs, les entreprises choisissent Red Hat OpenShift Virtualization à un rythme sans précédent, avec une adoption par les clients qui a bondi de 178 % depuis le début de l'année 2024. Si de nombreuses discussions se concentrent uniquement sur l'acte de migration, la véritable valeur réside dans l'innovation qui survient après le transfert.

Au lieu d'appréhender la migration comme l'objectif final, les entreprises tournées vers l'avenir y voient un tremplin. Cette transition ne se limite pas à relever les défis passés : elle vous permet de poser les bases d'une plateforme d'applications moderne, unifiée et prête pour l'avenir.

Voici à quoi ressemble cette feuille de route plus large en pratique.

Étape 1 : Mettez de l'ordre dans votre parc Linux

Après la migration, vous devriez envisager d'évaluer la prolifération de vos systèmes d'exploitation. La plupart des entreprises disposent d'un mélange de distributions, de versions et de contrats d'assistance accumulés au fil des années de croissance organique plutôt que par choix délibéré. Que les choses soient claires : En tant qu'entreprise Open Source, nous ne sommes pas là pour vous dire que les monocultures sont toujours la solution. L'hétérogénéité présente de réels avantages. Elle peut réduire les modes de défaillance partagés et limiter le rayon d'impact d'une seule classe de défauts. Une partie de cette diversité est intentionnelle et justifiable.

Mais dans les grandes entreprises, une grande partie ne l'est pas. C'est de la dette technique. C'est l'instance Ubuntu déployée pour un projet en 2019 qui exécute désormais une application critique. C'est le système CentOS que personne n'a corrigé après l'annonce de la fin de vie (EOL). C'est le système Windows XP dont personne ne sait vraiment ce qu'il fait, mais dont l'arrêt vous mettrait dans l'embarras.

Une fois que vous avez standardisé la couche hyperviseur, l'étape naturelle suivante consiste à examiner le paysage de vos systèmes d'exploitation invités. L'exécution de Red Hat Enterprise Linux (RHEL) en parallèle de Red Hat OpenShift vous offre un modèle d'exploitation plus cohérent : des correctifs unifiés, des parcours d'assistance cohérents et une application des politiques réellement efficace dans l'ensemble de votre environnement. L'enquête Red Hat Global Tech Trends 2024 a révélé que 45 % des entreprises placent la modernisation de leur pile applicative en tête de leurs priorités. Les efforts de modernisation qui fonctionnent réellement suivent tous le même principe : éliminer la diversité des systèmes d'exploitation non justifiée et conserver ceux qui reposent sur une justification métier valable.

Étape 2 : Arrêtez de gérer la nouvelle plateforme comme l'ancienne

C'est l'erreur que nous observons le plus souvent. Les équipes terminent une migration, puis continuent de gérer le nouvel environnement exactement de la même façon qu'elles géraient l'ancien. Mêmes processus manuels. Mêmes cycles de correction basés sur des tickets. Mêmes changements ad hoc via une console.

L'environnement post-migration est une page blanche. C'est probablement la meilleure occasion que vous aurez de réussir votre stratégie d'automatisation.

Avec Red Hat Ansible Automation Platform, les équipes peuvent passer de plusieurs semaines de déploiement manuel à seulement quelques heures. Une fois les playbooks en place, le provisionnement, l'application des correctifs et la mise en conformité se font automatiquement.

Si votre équipe utilise déjà GitOps, Red Hat Advanced Cluster Management for Kubernetes apporte cette même rigueur à la virtualisation. La politique devient du code, stocké dans Git. Plus de dérives liées à l'utilisation de la console. Cela permet un meilleur contrôle de la dérive, des déploiements plus rapides et des opérations de maintenance plus prévisibles.

Voici la réalité pratique : l'automatisation n'est pas un simple luxe sur le chemin de la modernisation. C'est ce qui rend les étapes ultérieures possibles.

Étape 3 : Exécutez vos charges de travail là où elles doivent l'être

Toutes les charges de travail ne doivent pas rester indéfiniment des machines virtuelles (VM). Certaines sont naturellement adaptées à la conteneurisation. Toutefois, l'objectif n'est pas de tout conteneuriser. L'objectif est d'exécuter chaque charge de travail là où cela est le plus pertinent.

OpenShift vous permet de gérer les machines virtuelles et les conteneurs sur la même plateforme, ce qui signifie que vous n'avez pas à choisir entre une approche « tout lift-and-shift » et « tout réécrire en mode cloud-native ». Ce faux dilemme a fait perdre un temps et un argent considérables à l'ensemble du secteur. PNC Bank est un bon exemple d'approche pragmatique. Elle a adopté de nouvelles normes et a réduit son délai de livraison de huit semaines à un objectif de 10 jours.

C'est à cette étape que beaucoup d'équipes marquent le pas. La technologie n'est pas la partie la plus difficile. Le plus difficile est de déterminer quelles charges de travail déplacer, quand et dans quel ordre. Bénéficier de l'aide de quelqu'un qui a déjà vécu cette expérience peut faire la différence entre un cycle de modernisation de six mois et un cycle de 13 mois. L'étude de Forrester le confirme. Grâce à des conseils expérimentés, une entreprise composite a pu ramener le déploiement d'OpenShift et la migration de ses machines virtuelles de 13 mois à sept mois.

Étape 4 : Pensez à l'IA avant d'en avoir besoin

Voici ce qu'il faut savoir sur l'IA : personne n'a réussi à la déployer en la greffant sur une infrastructure qui était déjà désordonnée. Selon Gartner®, les dépenses mondiales liées à l'IA s'élèveront à 2 500 milliards de dollars au total en 2026.

Je ne suggère pas de planifier l'adoption de l'IA avant d'avoir terminé la migration. Mais les équipes que j'ai vu réussir avaient un point commun : une infrastructure sous-jacente propre et automatisée. Les charges de travail d'IA sont exigeantes en matière de calcul, de stockage et d'observabilité. Mieux vaut résoudre ces questions sur une plateforme standardisée native pour Kubernetes plutôt que de devoir démêler des années de croissance organique.

La migration vous fait avancer. La modernisation vous transforme.

La migration vous éloigne d'une plateforme sur laquelle vous ne vouliez pas rester. La modernisation vous permet de construire la plateforme dont vous avez réellement besoin. Ce sont des concepts fondamentalement différents, et c'est dans l'écart entre les deux que résident le véritable travail (et la véritable valeur).

Communiqué de presse de Gartner, Gartner prévoit que les dépenses mondiales en IA atteindront 2 500 milliards de dollars en 2026, 15 janvier 2026

GARTNER est une marque commerciale de Gartner, Inc. et/ou de ses filiales.