Ce document fournit des conseils sur les approches et les considérations courantes et éprouvées pour migrer votre charge de travail vers le cloud. Il complète les conseils de l'article Concevoir une stratégie d'architecture hybride et multicloud, qui présente plusieurs étapes possibles et recommandées pour concevoir une stratégie d'adoption d'une architecture hybride ou multicloud.
Approche centrée sur le cloud
Le cloud public est souvent privilégié en tant qu'approche centrée sur le cloud. Dans cette approche, vous déployez vos nouvelles charges de travail dans le cloud public, tandis que vos charges de travail existantes restent à leur place. Dans ce cas, si un déploiement cloud public n'est pas possible pour des raisons techniques ou organisationnelles, un déploiement classique dans un environnement informatique privé doit être envisagé.
Une stratégie centrée sur le cloud présente des avantages et des inconvénients. Sa nature prospective est un avantage indéniable : Vous pouvez déployer de nouvelles charges de travail de façon moderne, tout en évitant (ou en minimisant) les tracas liés à une migration des charges de travail existantes.
Bien qu'une approche cloud first puisse présenter certains avantages, elle peut potentiellement vous faire passer à côté d'opportunités d'amélioration ou d'utilisation des charges de travail existantes. Les nouvelles charges de travail peuvent représenter une fraction du paysage IT global, et leur impact sur les dépenses et les performances IT peut être limité. Attribuer du temps et des ressources à la migration d'une charge de travail existante peut potentiellement générer des avantages ou des économies de coûts plus importants que d'essayer d'intégrer une nouvelle charge de travail dans l'environnement cloud.
Par ailleurs, l'application stricte d'une approche cloud-first risque de complexifier encore plus votre environnement IT. Cette approche peut créer des redondances, réduire les performances par excès d'intercommunications ou créer un environnement informatique inadapté aux particularités des charges de travail. De plus, le respect des réglementations du secteur et des lois sur la confidentialité des données peut empêcher les entreprises de migrer certaines applications contenant des données sensibles.
Par conséquent, vous avez plutôt intérêt à réserver l'approche centre sur le cloud à certaines charges de travail sélectionnées. Une approche cloud first vous permet de vous concentrer sur les charges de travail les plus qualifiées pour un déploiement ou une migration dans le cloud. Cette approche tient également compte de la modernisation des charges de travail existantes.
Un exemple courant d'architecture hybride cloud first est lorsque les applications et services existants contenant des données critiques doivent être intégrés à de nouvelles données ou applications. Pour effectuer l'intégration, vous pouvez utiliser une architecture hybride qui modernise les anciens services à l'aide d'interfaces API, ce qui les déverrouille pour permettre aux nouveaux services et applications cloud de les utiliser. Avec une plate-forme de gestion des API cloud, comme Apigee, vous pouvez implémenter ces cas d'utilisation avec un minimum de modifications apportées aux applications, et ajouter de la sécurité, des analyses et de l'évolutivité aux anciens services.
Migration et modernisation
Le multicloud hybride et la modernisation IT sont deux concepts distincts au sein d'un même cercle vertueux. L'utilisation du cloud public peut faciliter et simplifier la modernisation des charges de travail IT. La modernisation de vos charges de travail IT peut vous aider à tirer le meilleur parti du cloud.
La modernisation des charges de travail répond aux principaux objectifs suivants :
- Bénéficier d'une plus grande agilité de façon à s'adapter à l'évolution des besoins
- Réduire les coûts de votre infrastructure et de vos opérations
- Améliorez la fiabilité et la résilience pour minimiser les risques.
Toutefois, il peut s'avérer impossible de moderniser toutes les applications du processus de migration en même temps. Comme décrit dans la section Migration vers Google Cloud, vous pouvez mettre en œuvre l'un des types de migration suivants, ou même combiner plusieurs types selon vos besoins:
- Réhéberger (migration Lift and Shift)
- Migration (Lift and Optimize)
- Refactorisation (migration Move and Improve)
- Redéfinir l'architecture (poursuivre la modernisation)
- Recompilez (suppression et remplacement, parfois appelé migration Rip and Replace)
- Rachetez
Lorsque vous prenez des décisions stratégiques concernant vos architectures hybrides et multicloud, il est important de prendre en compte la faisabilité de votre stratégie en termes de coûts et de délais. Vous pouvez envisager une approche de migration par étapes, en commençant par la migration Lift and Shift ou le replatforming, puis en passant à la refactorisation ou à la refonte. En règle générale, le lift and shift permet d'optimiser les applications du point de vue de l'infrastructure. Une fois les applications exécutées dans le cloud, il est plus facile d'utiliser et d'intégrer les services cloud pour les optimiser davantage à l'aide d'architectures et de fonctionnalités cloud first. De plus, ces applications peuvent toujours communiquer avec d'autres environnements via une connexion réseau hybride.
Par exemple, vous pouvez refactoriser ou redéfinir une application monolithique volumineuse basée sur des VM et la transformer en plusieurs microservices indépendants, basés sur une architecture de microservices dans le cloud. Dans cet exemple, l'architecture de microservices utilise des services de conteneurs gérés par Google Cloud, tels que Google Kubernetes Engine (GKE) ou Cloud Run. Toutefois, si l'architecture ou l'infrastructure d'une application n'est pas compatible dans l'environnement cloud cible, vous pouvez commencer par replatformer, refactoriser ou redéfinir votre stratégie de migration pour surmonter ces contraintes, si possible.
Lorsque vous utilisez l'une de ces approches de migration, envisagez de moderniser vos applications (le cas échéant et dans la mesure du possible). La modernisation peut nécessiter l'adoption et l'implémentation des principes SRE (Site Reliability Engineering) ou DevOps. Vous devrez peut-être également étendre la modernisation des applications à votre environnement privé dans une configuration hybride. Même si l'implémentation des principes SRE implique une ingénierie de base, il s'agit davantage d'un processus de transformation que d'un défi technique. Par conséquent, il nécessitera probablement des changements de procédure et de culture. Pour en savoir plus sur la première étape de l'implémentation de l'SRE dans une organisation, qui consiste à obtenir l'adhésion des dirigeants, consultez Avec l'SRE, ne pas planifier, c'est planifier l'échec.
Combiner plusieurs approches de migration
Chaque approche de migration décrite ici présente certains avantages et inconvénients. La stratégie hybride et multicloud a pour avantage principal de ne pas imposer un choix unique. Vous pouvez en effet décider de l'approche qui convient le mieux en fonction de chaque charge de travail ou pile d'applications, comme illustré dans le diagramme suivant.
Ce diagramme conceptuel illustre les différents chemins ou approches de migration et de modernisation qui peuvent être appliqués simultanément à différentes charges de travail, en fonction des exigences métier et techniques uniques, ainsi que des objectifs de chaque charge de travail ou application.
De plus, il n'est pas nécessaire que les mêmes composants de pile d'application suivent la même approche ou stratégie de migration. Exemple :
- La base de données sur site de backend d'une application peut être migrée de MySQL autogéré vers une base de données gérée à l'aide de Cloud SQL dans Google Cloud.
- Les machines virtuelles du frontend de l'application peuvent être refactorisées pour s'exécuter sur des conteneurs à l'aide de GKE Autopilot, dans lequel Google gère la configuration du cluster, y compris les nœuds, le scaling, la sécurité et d'autres paramètres préconfigurés.
- La solution d'équilibrage de charge matérielle sur site et les fonctionnalités de pare-feu d'application Web (WAF) peuvent être remplacées par Cloud Load Balancing et Google Cloud Armor.
Choisissez le rehosting (lift and shift) si l'une des conditions suivantes est remplie pour les charges de travail:
- Le nombre de dépendances dans leur environnement est relativement faible.
- Il ne semble pas utile de les refactoriser, ou la refactorisation avant la migration n'est pas réalisable.
- Elles sont basées sur des logiciels tiers.
Privilégiez le refactoring (déplacement et amélioration) pour les charges de travail qui répondent à ces critères:
- Il existe des dépendances qu'il faut dénouer.
- Elles reposent sur des systèmes d'exploitation, du matériel ou des systèmes de base de données qui ne peuvent pas être hébergés dans le cloud.
- Les ressources de calcul ou de stockage sont mal utilisées.
- Elles ne peuvent pas être déployées de manière automatisée sans effort.
Déterminez si la recréation (suppression et remplacement) répond à vos besoins pour ces types de charges de travail:
- Elles ne satisfont plus les exigences actuelles.
- Ils peuvent être intégrés à d'autres applications qui offrent des fonctionnalités similaires sans compromettre les exigences métier.
- Elles reposent sur une technologie tierce en fin de vie.
- Elles exigent des droits de licences tierces qui ne se justifient plus sur le plan économique.
Le programme de migration rapide montre comment Google Cloud aide les clients à utiliser les bonnes pratiques, à réduire les risques, à maîtriser les coûts et à simplifier leur transition vers le cloud.