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 de charges de travail 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 et des charges de travail à migrer.
Ce document fait partie d'une série d'articles sur la migration vers Google Cloud :
- Migrer vers Google Cloud : premiers pas
- Migrer vers Google Cloud : évaluer et découvrir vos charges de travail (ce document)
- Migrer vers Google Cloud : planifier et établir vos fondations
- Migrer vers Google Cloud : transférer vos ensembles de données volumineux
- Migrer vers Google Cloud : déployer vos charges de travail
- Migrer vers Google Cloud : migrer des déploiements manuels vers des déploiements automatisés en conteneurs
- Migrer vers Google Cloud : optimiser votre environnement
- Migrer vers Google Cloud : bonnes pratiques pour valider un plan de migration
- Migrer vers Google Cloud : réduire les coûts
Le diagramme suivant illustre le parcours de votre migration.
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.
Au cours de la phase d'évaluation, vous déterminez les exigences et les dépendances pour migrer votre environnement source vers Google Cloud.
La phase d’évaluation est cruciale pour la réussite de votre migration. Vous devez acquérir une connaissance approfondie des charges de travail 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.
La phase d'évaluation comprend les tâches suivantes :
- Dresser un inventaire complet de vos applications
- Cataloguer vos charges de travail en fonction de leurs propriétés et de leurs dépendances
- Former et préparer vos équipes sur Google Cloud
- Créer des tests et des démonstrations de faisabilité sur Google Cloud
- Calculer le coût total de possession (TCO) de l'environnement cible
- Choisissez la stratégie de migration pour vos charges de travail.
- Choisissez vos outils de migration.
- Définissez le plan de migration et le calendrier.
- Validez votre plan de migration.
Dresser un inventaire de vos charges de travail
Pour définir la portée de votre migration, vous devez d'abord comprendre le nombre d'éléments existant dans votre environnement actuel, tels que les charges de travail 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 charges de travail uniquement, mais doit au moins contenir les éléments suivants:
- Dépendances de chaque charge de travail, telles que bases de données, agents de messagerie, systèmes de stockage de configuration et autres composants.
- Services prenant en charge l'infrastructure de votre charge de travail, tels que les dépôts sources, les outils d'intégration et de déploiement continus (CI/CD) et les dépôts 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 charge de travail 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 charges de travail 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 de charges de travail. 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 vous n'avez pas confirmé le contenu de vos inventaires.
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 charges de travail, consultez la section Centre de migration: lancer une analyse de découverte d'éléments.
Exemple d'inventaire de charges de travail
Cet exemple est un inventaire d'un environnement compatible avec une application d'e-commerce. L'inventaire comprend des charges de travail, des dépendances, des services exploitant plusieurs charges de travail et des dispositifs matériels.
Charges de travail
Pour chaque charge de travail 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 |
| Charge de travail d'e-commerce | Charge de travail 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) | Charge de travail 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 charges de travail répertoriées dans l'inventaire. Ces dépendances sont nécessaires au bon fonctionnement des charges de travail.
| 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 charges de travail. 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 | N/A | 10 cœurs de processeur 8 Go de RAM |
| Outil de CI | Jenkins | N/A | 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 |
N/A | 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 |
N/A | N/A | 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 |
|---|---|---|---|---|
| Pare-feu | Fournisseur H Modèle V |
N/A | 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 |
N/A | N/A | N/A |
Évaluer vos processus de déploiement et opérationnels
Il est essentiel de bien comprendre leur fonctionnement. Ces processus 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.
Vos processus de déploiement et opérationnels peuvent créer les artefacts dont vos charges de travail ont besoin pour fonctionner. Par conséquent, vous devez collecter des informations sur chaque type d'artefact. Par exemple, un artefact peut être un package du système d'exploitation, un package de déploiement d'application, une image du système d'exploitation, une image de conteneur ou autre.
Outre le type d'artefact, réfléchissez à la façon dont vous effectuez les tâches suivantes :
- Développez vos charges de travail. Évaluez les processus mis en place par les équipes de développement pour créer vos charges de travail. Par exemple, comment vos équipes de développement conçoivent-elles, codent-elles et testent-elles vos charges de travail ?
- Générez les artefacts que vous déployez dans votre environnement source. Pour déployer vos charges de travail dans votre environnement source, vous pouvez générer des artefacts déployables, tels que des images de conteneur ou des images de système d'exploitation, ou vous pouvez personnaliser des artefacts existants, tels que des images de système d'exploitation tiers en installant et en configurant des logiciels. La collecte d'informations sur la manière dont vous générez ces artefacts vous permet de vous assurer qu'ils sont adaptés au déploiement dans Google Cloud.
Stockez les artefacts. Si vous produisez des artefacts que vous stockez dans un registre d'artefacts dans votre environnement source, vous devez les rendre disponibles dans votre environnement Google Cloud. Pour ce faire, vous pouvez utiliser des stratégies telles que les suivantes :
- Établir un canal de communication entre les environnements : rendez les artefacts de votre environnement source accessibles depuis l'environnement Google Cloud cible.
- Refactoriser le processus de compilation des artefacts : effectuez une refactorisation mineure de votre environnement source afin de pouvoir stocker des artefacts à la fois dans l'environnement source et dans l'environnement cible. Cette approche traite votre migration en créant une infrastructure telle qu'un dépôt d'artefacts avant que vous ayez à implémenter des processus de compilation d'artefacts dans l'environnement Google Cloud cible. Vous pouvez mettre en œuvre cette approche directement ou vous appuyer sur l'approche précédente qui consiste à d'abord établir un canal de communication.
Le fait de disposer d'artefacts disponibles dans les environnements source et cible vous permet de vous concentrer sur la migration sans avoir à implémenter de processus de compilation d'artefacts dans l'environnement Google Cloud cible dans le cadre de la migration.
Scanner et signer le code. Dans le cadre de vos processus de compilation d'artefacts, vous pouvez utiliser l'analyse de code pour vous protéger contre les failles courantes et l'exposition involontaire au réseau, et la signature de code pour vous assurer que seul le code approuvé s'exécute dans vos environnements.
Déployez des artefacts dans votre environnement source. Après avoir généré des artefacts déployables, vous pouvez les déployer dans votre environnement source. Nous vous recommandons d'évaluer chaque processus de déploiement. L'évaluation permet de s'assurer que vos processus de déploiement sont compatibles avec Google Cloud. Elle vous permet également de comprendre les efforts nécessaires pour refactoriser les processus à terme. Par exemple, si vos processus de déploiement ne fonctionnent qu'avec votre environnement source, vous devrez peut-être les refactoriser pour cibler votre environnement Google Cloud.
L'injection d'une configuration d'exécution. Vous pouvez injecter une configuration d'environnement d'exécution pour des clusters, des environnements d'exécution ou des déploiements de charges de travail spécifiques. La configuration peut initialiser des variables d'environnement et d'autres valeurs de configuration telles que des secrets, des identifiants et des clés. Pour vous assurer que vos processus d'injection de configuration d'environnement d'exécution fonctionnent sur Google Cloud, nous vous recommandons d'évaluer la façon dont vous configurez les charges de travail exécutées dans votre environnement source.
Journalisation, surveillance et profilage Évaluez les processus de journalisation, de surveillance et de profilage que vous avez mis en place pour surveiller l'état de votre environnement source, les métriques d'intérêt et la façon dont vous consommez les données fournies par ces processus.
Authentification Évaluez la façon dont vous vous authentifiez auprès de votre environnement source.
Provisionnez et configurez vos ressources. Pour préparer votre environnement source, vous avez peut-être conçu et implémenté des processus de provisionnement et de configuration des ressources. Par exemple, vous pouvez utiliser Terraform avec des outils de gestion de la configuration pour provisionner et configurer des ressources dans votre environnement source.
É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 :
- 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, des projets et des espaces de noms.
- 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 charges de travail
Une fois l'inventaire terminé, vous devez organiser vos charges de travail en différentes catégories. Cette catégorisation peut vous aider à hiérarchiser les charges de travail à 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 charge de travail. Par exemple, vous voudrez peut-être savoir si une charge de travail possède des dépendances ou si elle est avec ou sans é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 charge de travail, vous devez ajouter un indicateur de complexité de la migration. Cet indicateur estime l'évaluation de la difficulté à migrer chaque charge de travail. 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 charges de travail, consultez la section Centre de migration: lancer une analyse de découverte d'éléments.
Exemple de catalogue de charges de travail
Les critères d'évaluation suivants sont utilisés dans cet exemple, un pour chaque axe de la matrice :
- Importance d'une charge de travail pour l'entreprise.
- Indique si une charge de travail a des dépendances ou s'il s'agit d'une dépendance pour d'autres charges de travail.
- Temps d'arrêt maximal autorisé pour la charge de travail.
- Difficulté de migration d'une charge de travail.
| 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 | Difficile | ||
| Charge de travail d'e-commerce | Aucun temps d'arrêt | Difficile | ||
| 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 | Difficile | ||
| 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 :
Dans le tableau précédent, la plupart des charges de travail sont faciles à migrer, trois d'entre elles sont difficiles à migrer et l'une d'entre elles ne peut pas être migrée.
Former 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 :
- 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.
- 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.
- 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 de charges de travail 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 :
- 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.
- 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.
- Certifications Google Workspace : vous pouvez démontrer les compétences de collaboration en utilisant les outils Google Workspace avec une certification Google Workspace.
- 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.
- 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.
Tester les produits et concevoir des démonstrations de faisabilité
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 de charge de travail dans votre catalogue de charges de travail. 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 charges de travail, y compris les cas rares et les cas critiques.
- Toutes les conditions requises pour chaque cas d'utilisation, telles que les conditions de performance, d'évolutivité et de cohérence, 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 charges de travail 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 le temps nécessaire pour le faire. Si vous bénéficiez d'une valeur ajoutée significative, telle que la réduction du temps de mise à niveau des nouvelles charges de travail de 95 % par rapport à votre environnement actuel, ce test peut démontrer 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.
Calculer le 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 charges de travail 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 VM 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 la stratégie de migration pour vos charges de travail
Pour chaque charge de travail à migrer, évaluez et sélectionnez la stratégie de migration qui correspond le mieux à votre cas d'utilisation. Par exemple, vos charges de travail peuvent présenter les conditions suivantes:
- Ils ne tolèrent aucune interruption ni perte de données, comme les charges de travail critiques. Pour ces charges de travail, vous pouvez choisir des stratégies de migration sans temps d'arrêt ou presque.
- Ils tolèrent les temps d'arrêt, tels que les charges de travail secondaires ou de backend. Pour ces charges de travail, vous pouvez choisir des stratégies de migration qui nécessitent un temps d'arrêt.
Lorsque vous choisissez des stratégies de migration, tenez compte du fait que les stratégies de migration sans temps d'arrêt ou avec un temps d'arrêt quasi nul sont généralement plus coûteuses et complexes à concevoir et à implémenter que les stratégies de migration qui nécessitent un temps d'arrêt.
Choisissez vos outils de migration.
Après avoir choisi une stratégie de migration pour vos charges de travail, examinez les outils de migration et choisissez-en un.
De nombreux outils de migration sont disponibles, chacun étant optimisé pour certains cas d'utilisation de migration. Voici quelques cas d'utilisation:
- Stratégie de migration
- Environnements source et cible
- Taille des données et de la charge de travail
- Fréquence des modifications apportées aux données et aux charges de travail
- Possibilité d'utiliser des services gérés pour la migration
Pour assurer une migration et une transition fluides, vous pouvez utiliser des modèles de déploiement d'applications, une orchestration de l'infrastructure et des applications de migration personnalisées. Toutefois, des outils spécialisés appelés services de migration gérés peuvent faciliter le processus de transfert de données, de charges de travail ou même d'infrastructures entières d'un environnement à un autre. Grâce à ces fonctionnalités, elles encapsulent la logique complexe de la migration et offrent des fonctionnalités de surveillance de la migration.
Vous devez définir le plan de migration et le calendrier
Maintenant que vous disposez d'une vue exhaustive de votre environnement actuel, vous devez compléter votre plan de migration en:
- Regrouper les charges de travail et les données à migrer en lots (également appelés sprints dans certains contextes).
- Choisissez l'ordre dans lequel vous souhaitez migrer les lots.
- Choisir l'ordre dans lequel vous souhaitez migrer les charges de travail dans chaque lot
Dans le cadre de votre plan de migration, nous vous recommandons également de créer les documents suivants:
- Document de conception technique
- Matrice RACI
- Calendrier (par exemple, un plan "T-Minus")
À mesure que vous acquérez de l'expérience avec Google Cloud, de l'élan dans la migration et une meilleure compréhension de votre environnement, vous pouvez procéder comme suit:
- affiner le regroupement des charges de travail et des données à migrer ;
- Augmentez la taille des lots de migration.
- modifier l'ordre dans lequel vous migrez les lots et les charges de travail dans les lots ;
- Mettez à jour la composition des lots.
Pour regrouper les charges de travail et les données à migrer par lots, et pour définir l'ordre de migration, vous évaluez vos charges de travail en fonction de plusieurs critères, par exemple:
- Valeur commerciale de la charge de travail.
- La charge de travail 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 la charge de travail.
- Nombre, type et étendue des dépendances de la charge de travail.
- Effort de refactorisation pour que la charge de travail fonctionne dans le nouvel environnement.
- Conformité et conditions de licence de la charge de travail.
- Exigences de disponibilité et de fiabilité de la charge de travail.
Les charges de travail 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.
Valeur commerciale
Le choix d'une charge de travail 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 charge de travail d'e-commerce 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 charges de travail constitue un meilleur choix, ou mieux encore, la base de données de transfert.
Vous devez éviter les charges de travail rarement utilisées. Par exemple, si vous choisissez une charge de travail utilisée peu de fois par an par un faible nombre d'utilisateurs, même si la migration comporte peu de risques, cela n'améliore pas la dynamique de votre migration et il peut être difficile de détecter les problèmes et d'y réagir.
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 charges de travail à 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 appliquer ce que vous avez appris avec ces premiers éléments migrés lors de la migration ultérieure de charges de travail.
Par exemple, si la plupart de vos charges de travail sont conçues selon une méthodologie de développement piloté par les tests et développées à l'aide du langage de programmation Python, choisir une charge de travail avec une faible couverture de test et développée à l'aide du langage de programmation Java ne vous permet pas de découvrir de modèle que vous pouvez appliquer lors de la migration des charges de travail Python.
Équipes
Lorsque vous choisissez vos premiers éléments à migrer, faites attention aux équipes responsables de chaque charge de travail. 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 charge de travail, ils peuvent être un excellent candidat.
Dépendances
En outre, vous devez vous concentrer sur les charges de travail qui ont le moins de dépendances, qu'elles proviennent d'autres charges de travail ou de services. La migration d'une charge de travail sans dépendance est plus facile lorsque vous avez une expérience limitée de Google Cloud.
Si vous devez choisir des charges de travail qui ont des dépendances sur d'autres composants, choisissez celles qui sont faiblement couplées à leurs dépendances. Si une charge de travail est déjà conçue pour l'indisponibilité éventuelle de ses dépendances, cela peut réduire les frictions lors de sa migration vers l'environnement cible. Par exemple, les candidats faiblement couplés sont des charges de travail qui communiquent à l'aide d'un agent de messagerie, 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 charges de travail avec état, une charge de travail sans état nécessite rarement une migration de données. La migration d'une charge de travail 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 charges de travail. La refactorisation doit se concentrer sur les modifications nécessaires permettant à vos charges de travail de s'exécuter dans l'environnement cible, plutôt que sur la modernisation et l'optimisation de vos charges de travail, sujet qui est traité lors des phases de migration ultérieures.
Par exemple, une charge de travail qui ne nécessite que des modifications de configuration est un bon candidat, car vous n'avez pas à implémenter de modification dans le 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 charges de travail peuvent être concédées sous licence selon des conditions qui affectent votre migration. Par exemple, certaines licences interdisent explicitement l'exécution de charges de travail 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 charges de travail. c'est pour cela que vous devez choisir les charges de travail 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 charge de travail ayant des exigences strictes en matière de disponibilité, vous devez mettre en œuvre une stratégie de migration de données sans interruption, telle que Y (écriture et lecture) ou en développant 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 la charge de travail client de votre site d'e-commerce, où vos utilisateurs finalisent leurs transactions.
Valider votre plan de migration
Avant de commencer à mettre en œuvre votre plan de migration, nous vous recommandons de valider sa faisabilité. Pour en savoir plus, consultez les bonnes pratiques pour valider un plan de migration.
Étape suivante
- Découvrez comment planifier votre migration et établir vos fondations sur Google Cloud.
- Découvrez à quel moment obtenir de l'aide pour vos migrations.
- Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.
Contributeurs
Auteur: Marco Ferrari | Architecte de solutions cloud