Migrer vers Google Cloud : premiers pas

Last reviewed 2023-10-09 UTC

Ce document vous aide à planifier, concevoir et mettre en œuvre le processus de migration de vos charges de travail vers Google Cloud. Le transfert d'applications d'un environnement à un autre peut s'avérer difficile, même pour des équipes expérimentées. Vous devez donc planifier et effectuer votre migration avec soin.

Ce document fait partie d'une série d'articles sur la migration vers Google Cloud :

Ce document est utile si vous planifiez une migration depuis un environnement sur site, un environnement d'hébergement privé, un autre fournisseur de cloud, ou si vous évaluez l'opportunité de migrer et souhaitez savoir à quoi la migration pourrait ressembler.

Prémices de la migration

Lors de la planification d'une migration vers Google Cloud, commencez par définir les environnements impliqués. Votre point de départ peut être un environnement sur site, un environnement d'hébergement privé ou un autre environnement de cloud public.

Un environnement sur site est un environnement qui vous appartient entièrement et dont vous êtes pleinement responsable. Vous conservez un contrôle total sur tous les aspects de l'environnement, tels que le refroidissement, la sécurité physique et la maintenance matérielle.

Dans un environnement d'hébergement privé, tel qu'une installation hébergée en colocation, vous sous-traitez une partie de l'infrastructure physique et de sa gestion à une partie externe. Cette infrastructure est généralement partagée par plusieurs clients. Dans ce type d'environnement, vous n'avez pas besoin de gérer les services de sécurité physique. Certains environnements d'hébergement vous permettent de gérer une partie du matériel physique, tels que les serveurs, les baies de serveurs et les appareils réseau, tandis que d'autres le gèrent pour vous. Généralement, l'alimentation et le câblage réseau sont fournis en tant que service, ce qui vous évite d'avoir à les gérer. Vous conservez un contrôle total sur les hyperviseurs qui virtualisent les ressources physiques, l'infrastructure virtualisée que vous provisionnez et les charges de travail que vous exécutez sur celle-ci.

L'avantage d'un environnement de cloud public est que vous n'avez pas à gérer la totalité de la pile de ressources vous-même. Vous pouvez vous concentrer sur l'aspect de la pile qui vous intéresse le plus. Comme dans un environnement d'hébergement privé, vous n'avez pas non plus à gérer l'infrastructure physique sous-jacente. De plus, aucune gestion de l'hyperviseur de virtualisation des ressources n'est requise. Vous pouvez créer une infrastructure virtualisée et déployer vos charges de travail sur cette nouvelle infrastructure. Vous pouvez également acquérir des services entièrement gérés, qui vous permettent de vous concentrer exclusivement sur vos charges de travail sans avoir à vous soucier de la charge opérationnelle liée à la gestion des environnements d'exécution.

Pour chaque environnement, ce document évalue les aspects suivants et indique qui doit se charger de la fourniture et de la gestion des services pertinents :

Ressources Environnement sur site Environnement d'hébergement privé Environnement de cloud public
Sécurité physique Vous Fournisseur de services Fournisseur de services
Alimentation et câblage réseau Vous Fournisseur de services Fournisseur de services
Matériel (y compris la maintenance) Vous Dépend du fournisseur de services Fournisseur de services
Plate-forme de virtualisation Vous Vous Fournisseur de services
Ressources applicatives Vous Vous Vous (éventuellement, en exploitant des services entièrement gérés)

Dans ce document, l'environnement cible est Google Cloud.

Une fois vos environnements de départ et cible définis, vous devez déterminer quels types de charges de travail et processus opérationnels associés entreront dans le champ d'application de la migration. Ce document aborde deux types de charges de travail et d'opérations : les anciennes charges de travail et opérations, et les charges de travail et opérations optimisées pour le cloud.

Les anciennes charges de travail et opérations sont développées sans tenir compte des environnements cloud. Elles peuvent être difficiles à modifier, et leur exécution et leur maintenance peuvent s'avérer coûteuses, car elles ne sont généralement compatibles avec aucun type d'évolutivité.

Les charges de travail et opérations optimisées pour le cloud sont nativement évolutives, portables, disponibles et sécurisées. Elles peuvent vous aider à améliorer la productivité et l'agilité des développeurs en leur permettant de se concentrer sur les charges de travail réelles plutôt que sur la gestion des environnements de développement et d'exécution, ou sur des processus de déploiement manuels et fastidieux. En outre, Google Cloud offre en matière de sécurité un modèle de responsabilité partagée. Google Cloud est responsable de la sécurité physique et de la sécurité de l'infrastructure. Quant à vous, vous êtes responsable de la sécurité des charges de travail que vous déployez dans l'infrastructure.

Compte tenu de ces environnements et de ces types de charges de travail, votre situation de départ correspond à l'une des suivantes :

  • Environnement sur site ou d'hébergement privé exécutant d'anciennes charges de travail et opérations
  • Environnement sur site ou d'hébergement privé exécutant des charges de travail et des opérations optimisées pour le cloud
  • Environnement de cloud public ou d'hébergement privé exécutant d'anciennes charges de travail et opérations
  • Environnement de cloud public ou d'hébergement privé exécutant des charges de travail et des opérations optimisées pour le cloud

Le processus de migration dépend de votre point de départ.

La migration d'une charge de travail depuis un ancien environnement sur site ou d'hébergement privé vers un environnement optimisé pour le cloud, tel qu'un cloud public, peut s'avérer difficile et risquée. Les migrations réussies modifient la charge de travail de façon à transférer un minimum de données pendant les opérations de migration. La migration d'anciennes applications sur site vers le cloud nécessite souvent plusieurs étapes.

Types de migration

Ce document définit les principaux types de migrations suivants:

  • Réhébergez : migration Lift and Shift
  • Changez de plate-forme : migration Lift and Optimize
  • Refactorisez : migration Move and Improve
  • Modifiez l'architecture : poursuivez la modernisation
  • Recompilez : suppression et remplacement (parfois appelé migration Rip and Replace)
  • Rachetez

Dans les sections suivantes, chaque type de migration est défini avec des exemples d'utilisation de chaque type.

Réhébergez : migration Lift and Shift

Lors d'une migration de réhébergement, vous transférez les charges de travail d'un environnement source vers un environnement cible avec très peu ou aucune modification ou refactorisation. Les modifications que vous appliquez aux charges de travail à migrer correspondent aux modifications minimales nécessaires à leur fonctionnement dans l'environnement cible.

Une migration de réhébergement est idéale lorsqu'une charge de travail peut fonctionner en l'état dans l'environnement cible, ou lorsqu'elle ne requiert que peu de changements, voire aucun, au niveau de l'entreprise. Il s'agit du type de migration le plus rapide, car les opérations de refactorisation sont réduites au minimum.

Certains problèmes techniques peuvent également vous obliger à opter pour une migration de réhébergement. Si vous ne pouvez pas refactoriser une charge de travail pour sa migration ni la mettre hors service, vous devez utiliser une migration de réhébergement. Par exemple, il peut être difficile ou impossible de modifier le code source de la charge de travail. Ou le processus de compilation peut s'avérer compliqué, vous empêchant ainsi de produire de nouveaux artefacts après la refactorisation du code source.

Les migrations de réhébergement sont les plus faciles à réaliser, car elles permettent à votre équipe de conserver sa palette existante d'outils et de compétences. Ces migrations sont également compatibles avec les logiciels prêts à l'emploi. Comme vous migrez des charges de travail existantes avec une refactorisation minimale, les migrations de réhébergement ont tendance à être les plus rapides, par rapport aux migrations de refactorisation ou de recompilation.

Toutefois, après une migration de réhébergement, les charges de travail exécutées dans l'environnement cible ne sont pas optimisées pour le cloud. Elles ne tirent pas pleinement parti des fonctionnalités de la plate-forme cloud, telles que l'évolutivité horizontale, la tarification ultraprécise ou les services hautement gérés.

Changez de plate-forme : migration Lift and Optimize

Lors d'une migration avec changement de plate-forme, vous effectuez une migration Lift des charges de travail existantes, puis vous les optimisez pour le nouvel environnement cloud.

Une migration avec changement de plate-forme est idéale pour les entreprises qui souhaitent bénéficier de toutes les compétences de base du cloud. Ces domaines incluent le calcul élastique, la redondance, l'amélioration des performances et la sécurité.

Par exemple, vous pouvez migrer une charge de travail vers le cloud afin de profiter d'une architecture de microservices ou de conteneurs dans Google Kubernetes Engine. Ces charges de travail offrent ensuite de meilleures performances et une plus grande efficacité dans le cloud.

Cependant, les migrations avec changement de plate-forme nécessitent plus de travail que les migrations de réhébergement. La nouvelle plate-forme cloud aura une base de code sous-jacente différente, qui nécessite plusieurs séries de tests pour s'assurer que tout fonctionne à son niveau optimal.

Refactorisez : migration Move and Improve

Dans une migration de refactorisation, vous modifiez les charges de travail pour tirer parti des fonctionnalités cloud, et pas seulement des charges de travail pour les rendre opérationnelles dans le nouvel environnement. Vous pouvez optimiser les performances, les fonctionnalités, les coûts ou l'expérience utilisateur associés à chaque charge de travail.

Vous pouvez modifier les charges de travail pendant leur migration vers le cloud, ou même avant leur migration. Par exemple, si vous n'avez pas beaucoup d'expérience avec les migrations vers le cloud, vous préférerez peut-être modifier les charges de travail pendant la migration. Toutefois, si vous avez une expérience de migration vers le cloud, vous avez peut-être déjà une idée des modifications dont les charges de travail ont besoin pour tirer pleinement parti des fonctionnalités cloud.

Si l'architecture ou l'infrastructure actuelle d'une application n'est pas compatible dans l'environnement cible, vous devez exécuter certaines opérations de refactorisation pour faire face à ces limites.

L'approche de refactorisation s'avère également idéale lorsque vous devez mettre à jour une grande partie de la charge de travail en plus d'apporter les modifications nécessaires à la migration.

Les migrations de refactorisation permettent à votre application de tirer parti des fonctionnalités d'une plate-forme cloud, telles que l'évolutivité et la haute disponibilité. Vous pouvez également façonner l'amélioration de façon à améliorer la portabilité de l'application.

Toutefois, les migrations de refactorisation prennent plus de temps que les migrations de réhébergement, car les charges de travail doivent être refactorisées pour que l'application puisse migrer.

Une migration de refactorisation nécessite également l'apprentissage de nouvelles compétences.

Modifiez l'architecture : poursuivez la modernisation

Les migrations de modification d'architecture sont semblables aux migrations de refactorisation. Toutefois, au lieu de restructurer le code de la charge de travail, les migrations d'architecture modifient le fonctionnement de ce code. Ces modifications de code optimisent la charge de travail et exploitent des propriétés optimisées pour le cloud telles que l'évolutivité, la sécurité et l'agilité. Par exemple, une migration de modification d'architecture peut transformer une grande charge de travail monolithique en plusieurs microservices indépendants que vous déployez sur Google Cloud.

Une migration de modification de l'architecture est plus complexe qu'une migration de refactorisation. Elle prend donc plus de temps et d'efforts. Une migration de modification de l'architecture peut également introduire des bugs ou des problèmes de sécurité dans les nouvelles charges de travail. Ainsi, une migration de modification d'architecture nécessite plusieurs séries de tests pour garantir que tout fonctionne à son niveau optimal.

Recompiler : supprimer et remplacer

Lors d'une migration de recompilation, vous mettez hors service une application existante, puis vous la recréez et la réécrivez entièrement en tant qu'application cloud native.

Si l'application actuelle ne répond pas à vos objectifs (par exemple, si vous ne souhaitez pas la conserver, si sa migration via l'une des approches mentionnées précédemment s'avère trop coûteuse ou si elle n'est pas compatible avec Google Cloud), vous pouvez effectuer une migration de recompilation.

Les migrations de recompilation permettent à votre application de tirer pleinement parti des fonctionnalités Google Cloud, telles que l'évolutivité horizontale, les services hautement gérés et la haute disponibilité. Comme vous réécrivez entièrement l'application, vous supprimez également les contraintes techniques liées à l'ancienne version.

Toutefois, les migrations de recompilation peuvent prendre plus de temps que les migrations de réhébergement ou de refactorisation. De plus, ce type de migration ne convient pas aux applications standards, car il nécessite une réécriture de l'application. Vous devez évaluer le temps et les efforts supplémentaires nécessaires à la reconception et à la réécriture de l'application dans le cadre de son cycle de vie.

Une migration de recompilation nécessite également de nouvelles compétences. Vous devez employer de nouvelles chaînes d'outils pour provisionner et configurer le nouvel environnement, ainsi que pour déployer l'application dans cet environnement.

Rachetez

Une migration de rachat se produit lorsque vous passez d'une charge de travail sur site achetée à un équivalent SaaS (Software as a Service) hébergé dans le cloud. Par exemple, vous pouvez passer d'un logiciel de collaboration sur site et d'un stockage local à Google Workspace.

Du point de vue des ressources, une migration de rachat peut être beaucoup plus facile que de refactoriser, reconstruire ou modifier l'architecture. Cependant, une migration de rachat peut être beaucoup plus coûteuse et vous risquez de ne pas bénéficier des fonctionnalités précises de contrôle de vos propres environnements cloud.

Framework d'adoption de Google Cloud

Avant de commencer votre migration, vous devez évaluer la maturité de votre organisation concernant l'adoption des technologies cloud. Le framework d'adoption de Google Cloud sert à la fois de carte pour situer les capacités actuelles de votre entreprise en matière de technologies de l'information et de guide pour vous aider à réaliser vos objectifs.

Vous pouvez exploiter ce framework pour évaluer le degré de préparation de votre organisation à Google Cloud, découvrir comment combler les lacunes et développer de nouvelles compétences, comme illustré dans le schéma suivant.

Architecture du framework d'adoption de Google Cloud, comprenant quatre catégories et trois phases.

Le framework évalue quatre catégories :

  • Formation. La qualité et l'ampleur de vos programmes de formation.
  • Impulsion. La mesure dans laquelle vos équipes informatiques sont appuyées par la direction pour migrer vers Google Cloud.
  • Évolutivité : La proportion dans laquelle vous utilisez des services optimisés pour le cloud et le degré d'automatisation opérationnelle actuellement en place.
  • Sécurité. Votre capacité à protéger votre environnement actuel contre les accès non autorisés et inappropriés.

Pour chaque catégorie, votre profil correspond à l'une des trois phases suivantes, conformément au framework :

  • Phase tactique. Vous ne disposez pas de plan cohérent couvrant l'ensemble des charges de travail individuelles en place. Vous souhaitez principalement obtenir un retour sur investissement rapide et minimiser les interruptions au sein de votre entreprise informatique.
  • Phase stratégique. Vous avez mis en place un plan pour développer des charges de travail individuelles, en tenant compte des besoins futurs en matière d'évolutivité. Votre objectif à moyen terme est de simplifier les opérations afin de gagner en performance.
  • Phase transformationnelle. Les opérations cloud s'exécutent de manière fluide et vous exploitez les données recueillies afin d'améliorer votre entreprise informatique. Votre objectif à long terme est de faire du service informatique de votre organisation un moteur d'innovation.

Lorsque vous évaluez les quatre catégories par rapport à ces trois phases, vous obtenez l'échelle de maturité du cloud. Dans chaque catégorie, vous pouvez constater la différence entre l'adoption occasionnelle de nouvelles technologies en cas de besoin et leur utilisation stratégique dans l'ensemble de l'organisation (ce qui implique naturellement une formation plus approfondie, plus complète et plus cohérente pour vos équipes).

Chemin de migration

Il est important de se rappeler qu'une migration est un voyage. Vous vous trouvez au point A avec votre infrastructure et vos environnements existants, et souhaitez atteindre le point B. Pour vous rendre du point A au point B, vous pouvez choisir l'une des options décrites ci-dessus.

Le schéma suivant illustre le chemin de ce voyage.

Chemin de migration en quatre phases.

Votre migration se compose de quatre phases :

Obtenir de l'aide

Google Cloud vous propose différentes options et ressources pour vous aider à tirer le meilleur parti des services Google Cloud.

Ressources en libre-service

Si vous n'avez pas besoin d'une assistance dédiée, vous pouvez faire appel à ces ressources en libre-service :

  • Documentation produit. Google Cloud fournit une documentation pour chacun de ses produits et services, ainsi que pour les API.
  • Documentation du Centre d'architecture. La section sur la migration du centre d'architecture couvre de nombreux scénarios de migration. Par exemple, les ressources de migration fournissent des conseils sur votre parcours de migration vers Google Cloud.
  • grâce aux outils d'analyse ; Google Cloud fournit plusieurs produits et services pour vous aider à effectuer une migration. Exemple :
    • Le Centre de migration Google Cloud est la plate-forme unifiée qui vous aide à accélérer votre transition cloud de bout en bout, de vos environnements cloud ou sur site actuels vers Google Cloud.
    • Migrate to Virtual Machines est un produit destiné à la migration de serveurs physiques et de machines virtuelles depuis des environnements cloud et sur site vers Google Cloud. Migrate to VMs vous permet de migrer une machine virtuelle vers Google Cloud en quelques minutes. Les données sont copiées en arrière-plan, mais les machines virtuelles sont complètement opérationnelles.
    • Le service de transfert de stockage vous permet d'importer des données dans Cloud Storage à partir d'autres fournisseurs cloud, de ressources en ligne ou de données locales.
    • Database Migration Service vous aide à migrer vos bases de données vers Google Cloud.
    • Transfer Appliance est un dispositif matériel que vous pouvez utiliser pour migrer d'importantes quantités de données (de plusieurs centaines de téraoctets jusqu'à un pétaoctet) vers Google Cloud sans perturber vos activités commerciales.
    • Le service de migration BigQuery est une solution complète de migration d'entrepôts de données vers BigQuery.
  • Livres blancs. Ces documents incluent des architectures de référence, des études de cas, des bonnes pratiques à adopter ainsi que des tutoriels avancés.
  • Contenu multimédia. Vous pouvez écouter le podcast Google Cloud ou regarder les vidéos disponibles sur la chaîne YouTube de Google Cloud. Ces ressources couvrent un large éventail de sujets, de la description des produits aux stratégies de développement.
  • Cours et ateliers en ligne. Google Cloud propose plusieurs formations sur Coursera qui incluent du contenu vidéo, des supports de lecture et des ateliers. Vous pouvez également prendre part à des ateliers via Google Cloud Skills Boost ou participer en direct à des cours en ligne.

Partenaires technologiques

Google Cloud s'est associé à plusieurs entreprises pour vous permettre d'utiliser leurs produits. Certaines offres peuvent être gratuites. Adressez-vous à l'entreprise et à votre responsable de compte Google Cloud pour en savoir plus.

Intégrateurs système

Google Cloud s'est non seulement associé avec des entreprises technologiques, mais également avec des intégrateurs système pouvant fournir une assistance technique. Dans la liste des partenaires, vous trouverez la liste des intégrateurs système spécialisés dans les migrations vers le cloud.

Google Cloud Professional Services

Notre équipe de services professionnels est là pour vous aider à tirer le meilleur parti de votre investissement dans Google Cloud.

Plan et principes de base du cloud : obtenez de l'aide pour votre migration

Les services professionnels peuvent vous aider à planifier votre migration et à déployer vos charges de travail en production grâce à notre offre Plan et principes de base du cloud. Ces experts guident votre équipe à chaque étape de la migration de votre charge de travail en production, de la configuration des principes de base de Google Cloud en vue d'optimiser la plate-forme pour répondre à vos besoins spécifiques en termes de charge de travail jusqu'au déploiement de la charge de travail.

Les objectifs de l'offre "Plan et principes de base du cloud" sont les suivants :

  • Établir les principes de base de Google Cloud
  • Mettre au point une documentation de conception
  • Planifier des activités de déploiement et de migration
  • Déployer des charges de travail en production
  • Suivre les problèmes et les risques

Les services professionnels guident votre équipe avec les activités et les livrables suivants :

  1. Organisation d'ateliers techniques de lancement
  2. Mise au point d'un document de conception technique
  3. Création d'un plan de migration
  4. Création d'une charte de programme
  5. Mise à disposition d'une gestion de projet
  6. Mise à disposition d'une expertise technique

Cloud Sprint : accélérez votre migration vers Google Cloud

Cloud Sprint est un atelier intensif qui accélère la migration de votre application vers Google Cloud. Au cours de cet atelier, les services professionnels Google Cloud assistent l'une de vos équipes via des discussions interactives, des sessions avec tableau blanc et des études d'applications cibles à migrer vers Google Cloud. Durant l'atelier Cloud Sprint, les services professionnels travaillent aux côtés des membres de votre équipe pour vous permettre d'acquérir une expérience pratique des solutions cloud, et vous présentent les activités de déploiement requises afin de vous aider à comprendre vos prochaines étapes pour les futures migrations Google Cloud.

Formation : développez les compétences de votre équipe

Les services professionnels Google Cloud proposent des formation dans divers domaines en fonction des besoins de votre équipe.

Étapes suivantes