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 développe les conseils de 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. Cette approche consiste à déployer vos nouvelles charges de travail dans le cloud public, tandis que vos charges de travail existantes restent en place. Dans ce cas, si un déploiement de 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 centrée sur le cloud puisse offrir certains avantages, elle peut potentiellement entraîner des opportunités manquées pour améliorer ou utiliser les charges de travail existantes. En effet, les nouvelles charges de travail ne représentent souvent qu'une fraction du paysage informatique global. Leur impact sur les dépenses et les performances informatiques peut donc être limité. Allouer du temps et des ressources à la migration d'une charge de travail existante peut potentiellement générer des avantages ou des économies plus importants que d'essayer d'adapter 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 informatique. 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 axée sur le cloud vous permet de vous concentrer sur les charges de travail qui peuvent le plus bénéficier d'un déploiement ou d'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 celui où des applications et services anciens contenant des données critiques doivent être intégrés à de nouvelles données ou applications. Pour finaliser 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 de tels cas d'utilisation en apportant un minimum de modifications aux applications et en ajoutant de la sécurité, des analyses et de l'évolutivité aux anciens services.
Migration et modernisation
Le multicloud hybride et la modernisation informatique 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 informatiques. La modernisation de vos charges de travail informatiques peut vous aider à tirer le meilleur parti du cloud.
La modernisation des charges de travail répond aux principaux objectifs suivants :
- Obtenir une plus grande agilité de façon à s'adapter à l'évolution des besoins
- Réduisez les coûts de votre infrastructure et de vos opérations.
- Augmenter la fiabilité et la résilience pour minimiser les risques
Toutefois, il n'est peut-être pas possible de moderniser toutes les applications en même temps lors du processus de migration. Comme décrit dans Migrer vers Google Cloud, vous pouvez implémenter l'un des types de migration suivants, ou même combiner plusieurs types selon vos besoins :
- Réhéberger (migration Lift and Shift)
- Changer de plate-forme (migration Lift and Optimize)
- Refactoriser (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 tenir compte de la faisabilité de votre stratégie en termes de coûts et de temps. Vous pouvez envisager une approche de migration par phases, en commençant par le lift and shift ou le replatforming, puis en refactorisant ou en redéfinissant l'architecture comme prochaine étape. En général, 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 des 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 l'architecture d'une grande application monolithique basée sur des VM et la transformer en plusieurs microservices indépendants, en fonction d'une architecture de microservices basée sur le cloud. Dans cet exemple, l'architecture de microservices utilise des services de conteneurs gérés par Google Cloud , comme Google Kubernetes Engine (GKE) ou Cloud Run. Toutefois, si l'architecture ou l'infrastructure d'une application n'est pas acceptée telle quelle dans l'environnement cloud cible, vous pouvez envisager de commencer par une stratégie de replatforming, de refactoring ou de réarchitecture pour surmonter ces contraintes, dans la mesure du possible.
Lorsque vous utilisez l'une de ces approches de migration, envisagez de moderniser vos applications (le cas échéant et si possible). La modernisation peut nécessiter l'adoption et l'implémentation des principes de l'ingénierie de la fiabilité des sites (SRE) ou de DevOps. Vous devrez peut-être également étendre la modernisation des applications à votre environnement privé dans une configuration hybride. Bien que l'implémentation des principes SRE implique avant tout de l'ingénierie, il s'agit davantage d'un processus de transformation que d'un défi technique. Par conséquent, il nécessitera probablement des changements procéduraux et culturels. Pour en savoir plus sur la première étape de l'implémentation de la SRE dans une organisation, qui consiste à obtenir l'adhésion de la direction, consultez Avec la SRE, ne pas planifier, c'est planifier l'échec.
Combiner plusieurs approches de migration
Chacune des approches de migration présentées ici a ses points forts et ses points faibles. 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 et des objectifs commerciaux et techniques uniques de chaque charge de travail ou application.
De plus, il n'est pas nécessaire que les mêmes composants de la pile d'applications suivent la même approche ou stratégie de migration. Exemple :
- La base de données de backend sur site d'une application peut être replatformée de MySQL auto-hébergé 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, où 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 réhébergement ("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 possible.
- Elles sont basées sur des logiciels tiers.
Privilégiez l'approche "refactoriser (déplacer et améliorer)" 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 un certain effort.
Déterminez si la reconstruction (suppression et remplacement) répond à vos besoins pour les types de charges de travail suivants :
- Elles ne satisfont plus les exigences actuelles.
- Elles peuvent être intégrées à d'autres applications offrant 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.