Migrer vers Google Cloud : évaluer et découvrir vos charges de travail

Last reviewed 2023-06-07 UTC

Ce document peut vous aider à planifier, concevoir et mettre en œuvre la phase d'évaluation de votre migration vers Google Cloud. La découverte de votre inventaire d'applications et de services et la cartographie de leurs dépendances peuvent vous aider à identifier ce que vous devez migrer et dans quel ordre. Lors de la planification et de la conception d'une migration vers Google Cloud, vous devez d'abord acquérir une connaissance approfondie de votre environnement actuel ainsi que des applications et des charges de travail à migrer.

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

Le diagramme suivant illustre le parcours de votre migration.

Chemin de migration en quatre phases

La phase d'évaluation est la première phase de votre migration vers Google Cloud au cours de laquelle vous déterminez les exigences et les dépendances pour migrer vos applications 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 phase d'évaluation pourrait ressembler.

La phase d’évaluation est cruciale pour la réussite de votre migration. Vous devez acquérir une connaissance approfondie des applications que vous souhaitez migrer, de leurs exigences, de leurs dépendances et de votre environnement actuel. Vous devez comprendre votre point de départ pour planifier et exécuter avec succès une migration Google Cloud.

Au cours de cette phase, vous suivrez les étapes suivantes :

  1. Dresser un inventaire complet de vos applications.
  2. Cataloguer vos applications en fonction de leurs propriétés et de leurs dépendances.
  3. Former et préparer vos équipes sur Google Cloud.
  4. Élaborer un test et une démonstration de faisabilité sur Google Cloud.
  5. Calculer le coût total de possession (TCO) de l'environnement cible.
  6. Choisir les charges de travail que vous souhaitez migrer en premier.

Dresser un inventaire de vos applications

Pour couvrir votre migration, vous devez d'abord comprendre le nombre d'éléments existant dans votre environnement actuel, tels que les applications et les dispositifs matériels, ainsi que leurs dépendances. L'élaboration de l'inventaire est une tâche non triviale qui nécessite un effort considérable, en particulier lorsque vous ne disposez pas de système de catalogage automatique. Pour disposer d'un inventaire complet, vous devez utiliser l'expertise des équipes chargées de la conception, du déploiement et de l'exploitation de chaque charge de travail de votre environnement actuel, ainsi que de l'environnement lui-même.

L'inventaire ne doit pas être limité aux applications, mais doit au moins contenir les éléments suivants :

  • Dépendances de chaque application, telles que bases de données, agents de messagerie, systèmes de stockage de configuration et autres composants.
  • Services prenant en charge votre infrastructure d'application, tels que les référentiels sources, les outils d'intégration continue (CI) et les référentiels d'artefacts.
  • Serveurs, virtuels ou physiques, et environnements d'exécution.
  • Les appareils physiques, tels que les périphériques réseau, les pare-feu et autres matériels dédiés.

Lors de la compilation de cette liste, vous devez également collecter des informations sur chaque élément, par exemple :

  • Emplacement du code source et possibilité de modifier ce code source.
  • Méthode de déploiement de la charge de travail dans un environnement d'exécution, par exemple, si vous utilisez un pipeline de déploiement automatisé ou manuel.
  • Restrictions du réseau ou exigences de sécurité.
  • Exigences relatives à l'adresse IP.
  • Façon dont vous exposez la charge de travail aux clients.
  • Conditions de licence pour tout logiciel ou matériel.
  • Comment la charge de travail s'authentifie auprès de votre système de gestion de l'authentification et des accès.

Par exemple, pour chaque dispositif matériel, vous devez connaître ses spécifications détaillées, telles que son nom, son fournisseur, ses technologies et ses dépendances par rapport à d'autres éléments de votre inventaire. Exemple :

  • Nom : dispositif NAS
  • Fournisseur et modèle : fournisseur Y, modèle Z
  • Technologies : NFS, iSCSI
  • Dépendances : connectivité réseau avec des trames Jumbo vers un matériel de calcul VM.

Cette liste doit également inclure des informations non techniques, par exemple, en vertu des conditions de licence pour lesquelles vous êtes autorisé à utiliser chaque élément et toute autre exigence de conformité. Alors que certaines licences vous permettent de déployer une application dans un environnement cloud, d'autres l'interdisent explicitement. Certaines licences sont attribuées en fonction du nombre de processeurs ou de sockets utilisés et ces concepts peuvent ne pas être applicables lors de l'exécution sur une technologie cloud. Certaines de vos données peuvent comporter des restrictions concernant la région géographique dans laquelle elles sont stockées. Enfin, certaines charges de travail sensibles peuvent nécessiter la location unique.

Parallèlement à l'inventaire, il est utile de fournir des aides pour une interprétation visuelle des données que vous avez collectées. Par exemple, vous pouvez fournir un graphique de dépendance et des tableaux de bord pour mettre en évidence des aspects intéressants, tels que la manière dont vos applications sont distribuées dans un processus de déploiement automatisé ou manuel.

Comment dresser votre inventaire

Il existe différentes manières de créer un inventaire d'applications. Le moyen le plus rapide de commencer consiste à procéder manuellement, mais cette approche peut s'avérer difficile pour un grand environnement de production. Les informations contenues dans les inventaires créés manuellement peuvent rapidement devenir obsolètes et la migration qui en résulte peut échouer car elle était basée sur de fausses hypothèses.

La préparation de l'inventaire n'est pas un exercice ponctuel. Si votre environnement actuel est très dynamique, vous devez également vous efforcer d'automatiser la création et la maintenance de l'inventaire afin de disposer d'un affichage cohérent de tous les éléments de votre environnement à un moment donné. Pour en savoir plus sur la création d'un inventaire de vos applications, consultez la section Centre de migration : lancer une analyse de découverte d'éléments.

Google collabore avec plusieurs entreprises pour vous aider dans votre migration. Pour en savoir plus, consultez l'aide.

Exemple d'inventaire d'applications

Cet exemple est un inventaire d'un environnement compatible avec une application d'e-commerce. L'inventaire comprend des applications, des dépendances, des services exploitant plusieurs applications et des dispositifs matériels.

Applications

Pour chaque application de l'environnement, le tableau suivant présente les technologies les plus importantes, sa procédure de déploiement et d'autres exigences.

Nom Emplacement du code source Technologies Procédure de déploiement Autres conditions requises Dépendances Besoins en ressources système
Site de marketing Référentiel d'entreprise Interface angulaire Automatisé Le service juridique doit valider le contenu Service de mise en cache 5 cœurs de processeur
8 Go de RAM
Back-office Référentiel d'entreprise Java backend, interface angulaire Automatisé ND SQL Database 4 cœurs de processeur
4 Go de RAM
Application d'e-commerce Application propriétaire Fournisseur X
Modèle Y
Version 1.2.0		 Manuel Les données client doivent résider à l'intérieur de l'Union Européenne SQL Database 10 cœurs de processeur
32 Go de RAM
Progiciels de gestion intégrés (ERP) Application propriétaire Fournisseur Z, modèle C, version 7.0 Manuel ND SQL Database 10 cœurs de processeur
32 Go de RAM
Microservices sans état Référentiel d'entreprise Java Automatisé ND Service de mise en cache 4 cœurs de processeur
8 Go de RAM

Dépendances

Le tableau suivant est un exemple des dépendances des applications répertoriées dans l'inventaire. Ces dépendances sont nécessaires au bon fonctionnement des applications.

Nom Technologies Autres conditions requises Dépendances Besoins en ressources système
SQL Database PostgreSQL Les données client doivent résider à l'intérieur de l'Union Européenne Système de sauvegarde et d'archivage 30 cœurs de processeur
512 Go de RAM

Services d'assistance :

Dans votre environnement, vous pouvez avoir des services prenant en charge plusieurs applications. Dans cet exemple de commerce électronique, les services suivants sont présents :

Nom Technologies Autres conditions requises Dépendances Besoins en ressources système
Dépôts de code source Git ND Système de sauvegarde et d'archivage 2 cœurs de processeur
4 Go de RAM
Système de sauvegarde et d'archivage Fournisseur G, modèle H, version 2.3.0 Le stockage à long terme de certains éléments est légalement obligatoire ND 10 cœurs de processeur
8 Go de RAM
Outil de CI Jenkins ND Dépôts de code source
Dépôt d'artefacts
Système de sauvegarde et d'archivage		 32 cœurs de processeur
128 Go de RAM
Dépôt d'artefacts Fournisseur A
Modèle N
Version 5.0.0		 ND Système de sauvegarde et d'archivage 4 cœurs de processeur
8 Go de RAM
Service de traitement par lots Travaux Cron s'exécutant dans l'outil CI ND Outil de CI 4 cœurs de processeur
8 Go de RAM
Service de mise en cache Memcached
Redis		 ND ND 12 cœurs de processeur
50 Go de RAM

Matériel

L'exemple d'environnement comprend les dispositifs matériels suivants :

Nom Technologies Autres conditions requises Dépendances Besoins en ressources système
Firewall Fournisseur H
Modèle V		 ND N/A ND
Instances du serveur j Fournisseur K
Modèle B		 Doit être mis hors service car il n'est plus pris en charge ND ND
Dispositif NAS Fournisseur Y
Modèle Z
NFS
iSCSI		 ND N/A Non disponible

Évaluer vos processus de déploiement et opérationnels

Après avoir créé les inventaires de vos charges de travail, nous vous recommandons d'évaluer vos processus de déploiement et d'exploitation. Vos processus de déploiement et d'exploitation font partie intégrante des pratiques qui préparent et gèrent votre environnement de production et les charges de travail qui y sont exécutées.

Ces processus peuvent provisionner l'infrastructure nécessaire et créer les artefacts dont vos charges de travail ont besoin, tels que les packages de système d'exploitation, les packages de déploiement de charge de travail, les images de système d'exploitation et les images de conteneur. Pour chaque charge de travail, rassemblez des informations sur le nombre d'artefacts nécessaires, le type de chaque artefact, la manière dont vous créez ces artefacts, mais aussi l'emplacement et le mode de stockage de ces derniers. Déterminez également comment vous injecterez une configuration d'exécution pour que ces artefacts soient réutilisables dans tous les environnements

Après avoir évalué vos processus de déploiement et opérationnels, nous vous recommandons également d'évaluer comment ces processus peuvent faciliter votre migration vers Google Cloud et comment ils vous aident à réduire le champ d'application et les risques liés à la migration. Par exemple, vous pouvez refactoriser vos processus de compilation d'artefacts pour stocker des artefacts dans votre environnement source et dans Google Cloud pendant la migration. Le fait de disposer d'artefacts dans les deux environnements vous permet de vous concentrer sur la migration de vos charges de travail et de vos données de l'environnement source vers Google Cloud sans avoir à mettre en œuvre des processus de compilation d'artefacts dans l'environnement Google Cloud cible dès le début du processus de migration.

Évaluer votre infrastructure

Après avoir évalué vos processus de déploiement et d'exploitation, nous vous recommandons d'évaluer l'infrastructure qui prend actuellement en charge vos charges de travail dans l'environnement source.

Pour évaluer cette infrastructure, tenez compte des éléments suivants :

  • Les processus que vous avez adoptés pour provisionner les ressources dont la charge de travail a besoin (Infrastructure as Code, par exemple).
  • La manière dont vous avez organisé les ressources dans votre environnement source. Par exemple, certains environnements acceptent la séparation logique entre les ressources à l'aide de constructions qui isolent des groupes de ressources les uns des autres, tels que des organisations et des projets.
  • La manière dont vous avez connecté votre environnement à d'autres environnements, tels que les environnements sur site et d'autres fournisseurs cloud.

Catégoriser vos applications

Une fois l’inventaire terminé, vous devez organiser les applications en différentes catégories. Cette catégorisation peut vous aider à hiérarchiser les applications à migrer en fonction de leur complexité et des risques liés à la migration vers le cloud.

La matrice du catalogue doit avoir une dimension pour chaque critère d'évaluation que vous envisagez dans votre environnement. Choisissez un ensemble de critères qui couvrent toutes les exigences de votre environnement, y compris les ressources système nécessaires à chaque application. Par exemple, vous voudrez peut-être savoir si une application a des dépendances ou si elle est sans état ou avec état. Lorsque vous concevez la matrice de catalogue, prenez en compte le fait que pour chaque critère ajouté, vous ajoutez une autre dimension à représenter. La matrice résultante pourrait être difficile à visualiser. Une solution possible à ce problème pourrait consister à utiliser plusieurs matrices plus petites au lieu d’une seule matrice complexe.

En outre, en regard de chaque application, vous devez ajouter un indicateur de complexité de la migration. Cet indicateur estime la difficulté à migrer chaque application. La granularité de cet indicateur dépend de votre environnement. Pour un exemple de base, vous pouvez avoir trois catégories : facile à migrer, difficile à migrer ou impossible à migrer. Pour mener à bien cette activité, vous avez besoin d’experts pour chaque élément de l’inventaire afin d’estimer sa complexité de migration. Les facteurs de cette complexité de la migration sont spécifiques de chaque entreprise.

Une fois le catalogue terminé, vous pouvez également créer des éléments visuels et graphiques pour vous aider, ainsi que votre équipe, à évaluer rapidement les métriques d'intérêt. Par exemple, tracez un graphique indiquant le nombre de composants ayant des dépendances ou soulignez la difficulté de migration de chaque composant.

Pour en savoir plus sur la création d'un inventaire de vos applications, consultez la section Centre de migration : lancer une analyse de découverte d'éléments.

Exemple de catalogue d'applications

Les critères d'évaluation suivants sont utilisés dans cet exemple, un pour chaque axe de la matrice :

  1. Importance d'une application pour l'entreprise.
  2. Si une application a des dépendances ou s'il s'agit d'une dépendance pour d'autres applications.
  3. Temps d'arrêt maximal autorisé pour l'application.
  4. Difficulté de migration d'une application.
Importance pour l'entreprise Ne possède pas de dépendances Possède des dépendances Temps d'arrêt maximal autorisé Difficulté
Application critique Microservices sans état 2 minutes Simplicité
ERP 24 heures Complexe
Application d'e-commerce Aucun temps d'arrêt Complexe
Pare-feu matériel Aucun temps d'arrêt Impossible
Base de données SQL 10 minutes Simplicité
Dépôts de code source 12 heures Simplicité
Application non critique Site de marketing 2 heures Simplicité
Sauvegarde et archivage 24 heures Simplicité
Service de traitement par lots 48 heures Simplicité
Service de mise en cache 30 minutes Simplicité
Back-office 48 heures Complexe
Outil de CI 24 heures Simplicité
Dépôt d'artefacts 30 minutes Simplicité

Pour vous aider à visualiser les résultats dans le catalogue, vous pouvez créer des visuels et des graphiques. Le graphique suivant met en évidence la difficulté de la migration :

Graphique illustrant la difficulté associée à la migration d'applications vers Google Cloud.

Dans le tableau ci-dessus, la plupart des applications sont faciles à déplacer, alors que trois d’entre elles sont difficiles à déplacer et l’une d’elles ne peut pas être déplacée.

Préparer votre organisation à Google Cloud

Pour tirer pleinement parti des avantages de Google Cloud, votre entreprise doit commencer à se familiariser avec les services, produits et technologies disponibles dans Google Cloud. Votre personnel peut commencer avec des comptes d'essai gratuits Google Cloud contenant des crédits pour les aider à expérimenter et à apprendre. La création d'un environnement gratuit pour les tests et l'apprentissage est essentielle à l'expérience d'apprentissage de votre personnel.

Plusieurs options de formation sont disponibles :

  1. Ressources publiques et ouvertes : vous pouvez commencer l'apprentissage de Google Cloud avec des ressources gratuites telles que des ateliers pratiques, des séries de vidéos, des webinaires Cloud OnAir et des événements de formation Cloud OnBoard.
  2. Cours approfondis : si vous souhaitez mieux comprendre le fonctionnement de Google Cloud, vous pouvez participer à des cours à la demande de Google Cloud Skills Boost ou à Google Cloud Training Specializations de Coursera, que vous pouvez suivre en ligne à votre rythme ou dans une salle de classe avec l'un de nos partenaires de formation autorisés à l'international. Ces cours durent généralement de un à plusieurs jours.
  3. Parcours d'apprentissage basés sur les rôles : vous pouvez former vos ingénieurs en fonction de leur rôle dans votre organisation. Par exemple, vous pouvez former vos développeurs d'applications ou vos opérateurs d'infrastructure à une meilleure utilisation des services Google Cloud.

Vous pouvez également certifier les connaissances de vos ingénieurs pour Google Cloud avec diverses certifications, à différents niveaux :

  1. Certifications associées : un point de départ pour les nouveaux utilisateurs de Google Cloud pouvant ouvrir la porte à des certifications professionnelles, telles que la certification Associate Cloud Engineer.
  2. Certifications professionnelles : si vous souhaitez évaluer des compétences de conception et de mise en œuvre avancées pour Google Cloud à partir d'années d'expérience, vous pouvez obtenir des certifications comme Professional Cloud Architect ou Professional Data Engineer.
  3. Certifications d'espace de travail Google : vous pouvez démontrer les compétences de collaboration en utilisant les outils d'espace de travail Google avec une certification d'espace de travail Google.
  4. Certifications Apigee : avec la certification d'ingénieur API certifié Apigee, vous pouvez démontrer votre capacité à concevoir et à développer des API robustes, sécurisées et évolutives.
  5. Certifications de développeurs Google : vous pouvez démontrer vos compétences en développement avec les certifications Associate Android Developer (cette certification est en cours de mise à jour) et Mobile Web Specialist.

En plus de la formation et de la certification, l'un des meilleurs moyens d'acquérir de l'expérience avec Google Cloud consiste à commencer à utiliser le produit pour créer des démonstrations de faisabilité d'entreprise.

Expérimenter et concevoir des preuves de concept

Pour montrer la valeur et l'efficacité de Google Cloud, envisagez de concevoir et de développer une ou plusieurs démonstrations de faisabilité (PoC) pour chaque catégorie d'applications dans votre catalogue d'applications. L'expérimentation et les tests vous permettent de valider des hypothèses et de démontrer la valeur du cloud aux chefs d'entreprise.

Au minimum, votre PoC devrait inclure les éléments suivants :

  • Une liste complète des cas d'utilisation pris en charge par vos applications, y compris les cas rares et les cas critiques.
  • Toutes les conditions requises pour chaque cas d'utilisation, telles que les conditions de performance et d'évolutivité, les garanties de cohérence attendues, les mécanismes de basculement et les exigences du réseau.
  • Une liste potentielle de technologies et de produits que vous souhaitez étudier et tester.

Vous devez concevoir des PoC et des expériences pour valider tous les cas d'utilisation de la liste. Chaque expérience doit avoir un contexte de validité précis, une portée, des résultats attendus et un impact commercial mesurable.

Par exemple, si l'une de vos applications liées au processeur doit évoluer rapidement pour répondre aux pics de demande, vous pouvez exécuter un test pour vérifier qu'une zone peut créer plusieurs cœurs de processeur virtuels et connaître le temps nécessaire à cette opération. Si vous bénéficiez d'une valeur ajoutée significative, telle que la réduction du temps de scaling des nouvelles applications de 95 % par rapport à votre environnement actuel, vous constaterez une valeur commerciale instantanée.

Si vous souhaitez évaluer les performances de vos bases de données locales par rapport à Cloud SQL, Spanner, Firestore ou Bigtable, vous pouvez mettre en œuvre une démonstration de faisabilité dans laquelle la même logique métier utilise différentes bases de données. Cette PoC vous offre la possibilité, à faible risque, d’identifier la solution de base de données gérée adaptée à votre charge de travail, sur plusieurs tests de performance et coûts d’exploitation.

Si vous souhaitez évaluer les performances du processus de provisionnement de VM dans Google Cloud, vous pouvez utiliser un outil tiers, tel que PerfKit Benchmarker, et comparer Google Cloud à d'autres fournisseurs de cloud. Vous pouvez mesurer le temps de bout en bout pour provisionner des ressources dans le cloud, en plus de générer des rapports sur les métriques standard des performances maximales, notamment la latence, le débit et la durée d'exécution. Par exemple, vous pourriez être intéressé par le temps et les efforts nécessaires pour approvisionner plusieurs clusters Kubernetes. PerfKit Benchmarker est un effort de la communauté open source impliquant plus de 500 participants, tels que des chercheurs, des institutions académiques et des entreprises, dont Google.

Calcul du coût total de possession

Lorsque vous avez une vue claire des ressources dont vous avez besoin dans le nouvel environnement, vous pouvez créer un modèle de coût total de possession vous permettant de comparer vos coûts sur Google Cloud avec les coûts de votre environnement actuel.

Lors de la construction de ce modèle de coûts, vous devez prendre en compte non seulement les coûts matériels et logiciels, mais également tous les coûts opérationnels liés à l'exploitation de votre propre centre de données, tels que les services d'alimentation, de refroidissement, de maintenance et autres. Grâce à l'évolutivité élastique des ressources Google Cloud, sachez qu'il est généralement plus facile de réduire les coûts par rapport à un centre de données sur site plus rigide.

L'utilisation d'un réseau dans le cloud est un coût généralement négligé lors de la migration vers le cloud. Dans un centre de données, l'achat d'une infrastructure réseau, telle que des routeurs et des commutateurs, puis la mise en place du câblage réseau approprié constituent des coûts uniques qui vous permettent d'utiliser la totalité de la capacité du réseau. Dans un environnement cloud, vous pouvez être facturé pour l'utilisation du réseau. Pour les applications gourmandes en données, ou celles générant un trafic réseau important, vous devrez peut-être envisager de nouvelles architectures et des flux de réseau afin de réduire les coûts de mise en réseau dans le cloud.

Google Cloud fournit également une large gamme d'options pour un scaling intelligent des ressources et des coûts. Par exemple, dans Compute Engine, vous pouvez redimensionner pendant la migration avec Migrate for Compute Engine ou une fois les ordinateurs virtuels déjà en cours d'exécution ou lors de la création de groupes d'instances évoluant automatiquement. Ces options peuvent avoir un impact important sur les coûts d'exploitation des services et doivent être explorées pour calculer le coût total de possession (TCO).

Pour calculer le coût total des ressources Google Cloud, vous pouvez utiliser le simulateur de coût.

Choisir les applications à migrer en premier

Maintenant que vous avez une vue exhaustive de votre environnement actuel, vous devez compléter votre plan de migration en choisissant la commande initiale dans laquelle vous souhaitez migrer vos applications. Vous pouvez préciser cet ordre lors de la migration, à mesure que vous acquérez de l'expérience avec Google Cloud et comprenez votre environnement et vos applications.

Les applications que vous migrez en premier sont celles qui permettent à vos équipes de développer leurs connaissances et leur expérience sur Google Cloud. Une plus grande exposition au cloud et l'expérience de votre équipe peuvent réduire le risque de complications pendant la phase de migration, en plus de faciliter et d'accélérer les migrations suivantes. Choisir les bons éléments à migrer en premier est donc crucial pour une migration réussie. Vous pouvez choisir une seule application ou mettre plusieurs applications de votre matrice d'applications dans votre liste de celles qui vont migrer en premier.

L'identification des premiers éléments à migrer est complexe, mais voici quelques critères pour vous guider :

  • Valeur commerciale de l'application.
  • L'application est-elle déployée ou exécutée de manière unique par rapport au reste de votre infrastructure ?
  • Équipes responsables du développement, du déploiement et des opérations de l'application.
  • Nombre, type et étendue des dépendances de l'application.
  • Refactorisation pour que l'application fonctionne dans le nouvel environnement.
  • Conformité et conditions de licence de l'application.
  • Exigences de disponibilité et de fiabilité de l'application.

Valeur pour l'entreprise

Le choix d'une application qui n'est pas essentielle à l'entreprise protège votre secteur d'activité principal et réduit l'impact de risques et d'erreurs non découverts pendant que votre équipe apprend les technologies cloud. Par exemple, si vous choisissez le composant dans lequel la logique des transactions financières principales de votre application de commerce électronique est mise en œuvre, toute erreur lors de la migration pourrait avoir un impact sur votre secteur d'activité principal. La base de données SQL prenant en charge vos applications constitue un meilleur choix, ou mieux encore, la base de données de transfert.

Vous devriez éviter les applications rarement utilisées. Par exemple, si vous choisissez une application utilisée peu de fois par an par un faible nombre d'utilisateurs, alors que c'est une migration à faible risque, cela n'augmente pas le rythme de votre migration et il peut être difficile de détecter et de réagir aux problèmes.

Cas extrêmes

Vous devez également éviter les cas extrêmes afin de pouvoir découvrir des modèles que vous pouvez appliquer à d'autres applications à migrer. Lors de la sélection du premier élément à migrer, l'objectif principal est d'acquérir de l'expérience avec les modèles courants de votre organisation afin de pouvoir constituer une base de connaissances. Vous pouvez réappliquer ce que vous avez appris avec ces premiers éléments migrés lors de la migration ultérieure d'applications futures.

Par exemple, si la plupart de vos applications sont conçues selon une méthodologie de développement pilotée par des tests et sont développées à l'aide du langage de programmation Python, le choix d'une application avec une faible couverture de test et développée à l'aide du langage de programmation Java ne vous permet pas de découvrir un modèle vous pouvez appliquer lors de la migration des applications Python.

Équipes

Lorsque vous choisissez vos premiers éléments à migrer, faites attention aux équipes responsables de chaque application. L'équipe responsable d'une première migration doit être très motivée et désireuse d'essayer Google Cloud et ses services. En outre, les dirigeants de l’entreprise doivent définir des objectifs clairs pour les équipes de la première migration et s’employer activement à les accompagner et à les soutenir tout au long du processus.

Par exemple, une équipe hautement performante installée dans le bureau principal et bénéficiant d'une expérience éprouvée dans la mise en œuvre de pratiques de développement modernes telles que DevOps et de disciplines telles que l'ingénierie en fiabilité des sites peut être un bon candidat. S'ils ont également des sponsors top-down et des objectifs clairs concernant la migration de chaque application, ils peuvent être un excellent candidat.

Dépendances

En outre, vous devez vous concentrer sur les applications qui ont le moins de dépendances, soit d’autres applications, soit de services. La migration d'une application sans dépendance est plus facile lorsque vous avez une expérience limitée de Google Cloud.

Si vous devez choisir des applications qui ont des dépendances sur d'autres composants, choisissez celles qui sont faiblement couplées à leurs dépendances. Si une application est déjà conçue pour l'indisponibilité éventuelle de ses dépendances, elle peut réduire les frictions lors de la migration de l'application vers l'environnement cible. Par exemple, les candidats faiblement couplés sont des applications qui communiquent à l'aide d'un agent de messagerie, ou qui travaillent hors connexion, ou qui sont conçues pour tolérer l'indisponibilité du reste de l'infrastructure.

Bien qu'il existe des stratégies pour migrer les données des applications avec état, une application sans état nécessite rarement une migration de données. La migration d'une application sans état peut être plus simple, car vous n'avez pas à vous soucier d'une phase transitoire dans laquelle les données se trouvent partiellement dans votre environnement actuel et partiellement dans votre environnement cible. Par exemple, les microservices sans état sont de bons candidats, car ils ne s'appuient sur aucune donnée locale.

Durée de refactorisation

Une première migration devrait nécessiter un minimum de refactorisation afin que vous puissiez vous concentrer sur la migration elle-même et sur Google Cloud, au lieu de consacrer beaucoup d'efforts à la modification du code et à la configuration de vos applications. La refactorisation doit se concentrer sur les modifications nécessaires permettant à vos applications de s'exécuter dans l'environnement cible au lieu de se concentrer sur la modernisation et l'optimisation de vos applications, sujet qui est traité dans les phases de migration ultérieures.

Par exemple, une application qui nécessite uniquement des modifications de configuration est un bon candidat, car vous n'avez pas à implémenter de modification dans Codebase et vous pouvez utiliser les artefacts existants.

Licence et conformité

Les licences jouent également un rôle dans le choix des premiers éléments à migrer, car certaines de vos applications peuvent être concédées sous licence selon des termes qui affectent votre migration. Par exemple, certaines licences interdisent explicitement l'exécution d'applications dans un environnement cloud.

Lorsque vous examinez les conditions de licence, n'oubliez pas les exigences de conformité, car vous pourriez avoir des exigences de location unique pour certaines de vos applications. c'est pour cela que vous devez choisir les applications qui génèrent le moins de restrictions en matière de licence et de conformité.

Par exemple, vos clients peuvent avoir le droit de choisir légalement la région dans laquelle vous stockez leurs données, ou les données de vos clients peuvent être restreintes à une région particulière.

Disponibilité et fiabilité

Les bons candidats pour une première migration sont les éléments qui peuvent se permettre un temps d'arrêt causé par une fenêtre ouverte. Si vous choisissez une application ayant des exigences strictes de disponibilité, vous devez mettre en œuvre une stratégie de migration de données sans interruption, telle que Y (écriture et lecture) ou développer un microservice d'accès aux données. Bien que cette approche soit possible, elle empêche vos équipes d'acquérir l'expérience nécessaire avec Google Cloud, car elles doivent passer du temps à mettre en œuvre ces stratégies.

Par exemple, les exigences de disponibilité d'un moteur de traitement par lots peuvent tolérer un temps d'indisponibilité plus long que l'application client de votre site de commerce électronique où vos utilisateurs finalisent leurs transactions.

Étapes suivantes