Avant d'envisager une migration cloud, vous devez trancher quelques décisions clés — et les plus importantes tiennent à la valeur métier visée. Voici tout ce qu'il faut savoir.
Évaluer la pertinence de chaque workload avant de le basculer vers le cloud ou une autre plateforme cloud
Passer au cloud public n'est pas une fin en soi, mais la première étape d'un processus continu. Si vous avez déjà maîtrisé les étapes clés d'une migration cloud pour certains de vos workloads, vous serez sans doute amené à en migrer d'autres par la suite. Vous pourriez aussi basculer vers un autre cloud pour réduire les coûts, gagner en fonctionnalités ou en sécurité. Mais avant de bouger quoi que ce soit, certaines questions clés s'imposent.
1. Avez-vous l'adhésion de la direction ?
Si la réponse à cette question n'est pas un oui franc, votre migration cloud échouera. Si la plupart des entreprises visent à confier 80 % de leur hébergement IT au cloud d'ici 2024, peu de dirigeants au sein du comex sont pleinement convaincus que les initiatives de migration cloud de leur entreprise tiendront leurs promesses. D'où l'importance de voir le cloud comme bien plus qu'un simple programme IT. Vous devez obtenir l'adhésion du comité de direction en le présentant comme un levier d'efficacité, d'innovation et de croissance, garant du succès futur de l'entreprise.
Cette adhésion repose sur la force de conviction de votre plan de migration, qui doit refléter une approche réfléchie, systématique et stratégique : que migrer, où le migrer et — surtout — quel enjeu métier cela permet de résoudre. Appuyez-vous sur la croissance, la taille et les points de friction actuels de votre entreprise pour bâtir un argumentaire convaincant sur la valeur métier réellement créée par la migration.
2. Que cherche à accomplir l'entreprise avec cette migration ?
Gartner prévoit que la part des nouveaux workloads numériques déployés sur des plateformes cloud-native passera de 30 % en 2021 à plus de 95 % en 2025. Avant de déplacer des workloads d'un cloud à un autre ou de migrer ceux qui restent on-premises, les entreprises doivent comprendre les raisons qui motivent leur migration.
Parmi les facteurs déterminants : la réduction des coûts, l'allègement de la charge d'infrastructure, la scalabilité, la disponibilité et l'amélioration de l'expérience utilisateur. La croissance pousse peut-être les systèmes et infrastructures on-premises dans leurs derniers retranchements, imposant la mise en place de nouveaux systèmes capables d'évoluer au même rythme. L'objectif peut aussi être de simplifier les procédures et processus pour les développeurs et utilisateurs, de gagner en efficacité IT pour répondre plus vite aux exigences clients ou d'accroître l'agilité face aux évolutions du marché mondial.
La migration cloud aide à libérer l'innovation à grande échelle et à un rythme soutenu, permettant d'atteindre des jalons clés qui prendraient autrement des années. Quel que soit l'objectif, les dirigeants doivent avoir une vision claire de la finalité de la migration pour pouvoir suivre et mesurer la progression.
3. Ce workload est-il un bon candidat pour le cloud ?
Il est judicieux de déployer de nombreuses applications frontend dans le cloud public : leur tendance à évoluer fréquemment tire pleinement parti de la flexibilité qu'il offre. Les workloads les mieux adaptés au cloud ont généralement des cycles de vie courts, connaissent des pics d'utilisation fréquents et exigent un déploiement rapide d'infrastructure.
Mais tous les workloads ne s'y prêtent pas. Les applications nécessitant une latence inférieure à la milliseconde ont généralement intérêt à rester on-premises. Si vous exploitez un système de trading financier, par exemple, le cloud ne sera pas la solution optimale pour cette brique. L'industrie manufacturière est un autre secteur extrêmement sensible aux temps de latence, ce qui explique pourquoi certains constructeurs automobiles de premier plan utilisent un système comme AWS Outposts pour développer et exécuter leurs applications sur site, sans introduire la latence relativement élevée d'un déploiement cloud par rapport à l'on-premises.
Autre cas où conserver des workloads on-premises peut s'avérer préférable — au moins à court ou moyen terme — : si vous avez investi un Capex (dépenses d'investissement) substantiel dans votre infrastructure on-premises et devez en tirer le maximum avant de basculer vers le modèle financier Opex (dépenses opérationnelles) du cloud.
En revanche, contrairement à une idée reçue, la conformité ne figure généralement pas parmi les raisons de garder un workload on-premises. La visibilité accrue et les contrôles plus fins font même du cloud un emplacement sans doute supérieur pour ce type de workloads. Prenez le RGPD (Règlement général sur la protection des données) de l'UE : avec une attention rigoureuse à la réglementation et une bonne maîtrise du cloud, il est possible d'obtenir un meilleur retour sur investissement avec un déploiement cloud qu'en data center.
Il est utile de consulter un partenaire cloud pour réaliser une analyse approfondie des workloads et déterminer le modèle de déploiement optimal. Vous obtiendrez ainsi une vision claire du paysage technique, des défis et des dépendances de vos workloads actuels, du rapport entre la valeur de la migration et l'effort à fournir, ainsi que de la séquence optimale de migration.
4. Pourquoi ce cloud ?
Si la plupart des organisations utilisent plusieurs clouds, elles ne le font pas toujours de manière efficace ou stratégique. Cela tient en partie au fait que de nombreuses initiatives cloud public résultent du shadow IT : des logiciels, équipements et services achetés à l'insu de la DSI ou hors de son contrôle.
Les workloads sont aussi répartis entre clouds par opportunité plutôt que par analyse. Sans données précises sur la performance de l'infrastructure pour chaque workload, choisir le bon cloud relève davantage de la chance que d'une décision éclairée.
Interrogez-vous sur les raisons qui vous poussent à déplacer vos workloads vers un cloud précis. Les grands fournisseurs cloud ont chacun des forces susceptibles de coller à votre cas d'usage métier. Beaucoup de clients migrent vers Amazon Web Services (AWS) pour l'étendue et la profondeur de ses services, les clients Microsoft existants choisissent souvent Azure pour innover avec des services qu'ils utilisent déjà, tandis que Google Cloud se distingue par ses capacités d'analyse de données.
En théorie, vous pouvez exécuter le même workload sur plusieurs clouds, mais vous vous limiterez alors au plus petit dénominateur commun. Chaque fournisseur cloud propose des services natifs sans équivalent chez ses concurrents : il n'est donc pas réaliste d'attendre que vos workloads s'exécutent de façon transparente d'un fournisseur à l'autre. Tirer parti du cloud public pour l'innovation qu'il permet, c'est jouer la carte des points forts du cloud retenu au moment de choisir où déployer ses workloads.
5. Quelle approche allez-vous adopter pour la migration ?
Selon votre expérience préalable des migrations cloud et l'accès de votre entreprise à l'expertise adéquate, votre approche relèvera de l'une (ou d'une combinaison) de ces cinq catégories : rehost (lift and shift), refactor, replatform, rebuild, replace ou retire :
- Le rehosting est l'approche la plus directe : il s'agit simplement de redéployer données et applications existantes sur des ressources de stockage et de calcul cloud, sans modification. Il demande peu d'expertise cloud, mais ne tire pas parti des capacités de la plateforme et ne convient pas à tous les workloads.
- Le refactoring est plus complexe car il implique de réarchitecturer les applications avant leur passage dans le cloud. Il offre toutefois un retour sur investissement élevé en exploitant les fonctionnalités cloud-native ainsi que leur flexibilité et leur élasticité inhérentes.
- Le replatforming représente un juste milieu entre rehosting et refactoring : il implique certaines modifications du workload pour profiter des avantages du cloud comme l'automatisation et une scalabilité améliorée.
- Le rebuilding consiste à recréer le workload de zéro pour exploiter pleinement les fonctionnalités de l'environnement cloud. Cela exige un haut niveau de compétence et d'engagement.
- Remplacer un workload par une application cloud-native revient à retirer une application existante et à ne migrer que les données nécessaires à son fonctionnement. Cela peut être judicieux s'il est plus simple d'utiliser un service fourni par le fournisseur cloud que de redéployer les mêmes outils que ceux utilisés on-premises.
- Mettre hors service les workloads qui ont fait leur temps est essentiel pour éviter de gaspiller temps et ressources pendant la migration. Mais avant tout retrait, identifiez bien les éventuelles dépendances en amont.
L'approche de migration retenue influera sur tout, des coûts cloud aux décisions d'architecture.
6. Quel en sera le coût ?
Le budget d'une migration cloud doit couvrir toutes les étapes du processus, de la planification pré-migration à l'exploitation des workloads dans le cloud après bascule. Même si la direction est unie sur la nécessité d'une migration, elle doit avoir conscience des coûts impliqués pour décider comment procéder et à quel rythme.
Le coût total de possession (TCO) cloud est une méthode permettant de calculer les divers coûts liés à l'exploitation des workloads dans le cloud sur leur durée de vie. Chaque déploiement cloud est différent, mais il est essentiel de comparer le coût d'exécution d'une même application on-premises et dans le cloud. La fonctionnalité de l'application doit être considérée dans son intégralité, en particulier les exigences de sécurité, les autres dépendances applicatives et tout élément susceptible de peser lourdement sur les coûts. Le coût lié à la résorption des écarts de compétences pour faire monter les équipes en puissance sur les différentes plateformes cloud associées à la migration constitue un autre élément clé du TCO cloud.
7. Quelles sont les implications de la migration en matière de sécurité et de conformité ?
Les contrôles et pratiques de sécurité conçus pour vos environnements on-premises ne fonctionneront pas dans le cloud. L'une des principales différences à intégrer est le modèle de responsabilité partagée : le fournisseur cloud assume l'essentiel de la responsabilité de la sécurité de l'infrastructure, tandis que le client cloud reste responsable des configurations et paramètres sous son contrôle direct — données et applications, notamment. On parle aussi de sécurité du cloud par opposition à la sécurité dans le cloud : le fournisseur répond de la sécurité du cloud lui-même, et le client de la sécurisation de ce qui s'y trouve.
Autre caractéristique de la sécurité cloud : la nature logicielle du cloud crée des exigences spécifiques en matière de contrôles et de processus, qu'il vous faudra peut-être traiter avec de nouvelles technologies. Vous devrez aussi sans doute restructurer vos workflows et alignements de gouvernance pour les rendre plus agiles et continus. Préparez-vous à mobiliser des représentants issus d'un large éventail de parties prenantes et de disciplines techniques.
8. Disposez-vous des ressources nécessaires à la migration ?
La pénurie de professionnels IT qualifiés ralentit l'adoption des technologies liées au cloud. Dans son Emerging Technology Roadmap 2021-2023, Gartner révèle que les dirigeants IT considèrent la pénurie de talents comme le principal frein au déploiement des technologies émergentes — bases de données, machine learning, stockage avancé et analytique — qui reposent toutes sur le cloud.
Une fois les compétences en place, votre équipe doit fonctionner comme un tout cohérent : le processus s'effondre si vos data engineers travaillent en vase clos par rapport à vos experts réseau, par exemple, et que chacun considère sa mission terminée dès que sa propre brique est livrée. Encouragez la participation active de tous et installez l'idée que personne n'a fini tant que tout le monde n'a pas fini. C'est l'une des principales raisons d'embarquer les sponsors de haut niveau dans le processus, afin d'éliminer tout blocage à la constitution d'équipes globales chargées de mener à bien le parcours cloud. Sans cela, le projet de migration s'enlisera à mesure que les obstacles s'accumuleront.
Si vous manquez de compétences en interne pour mener votre migration cloud, vous pouvez envisager de former et de faire monter en compétences votre équipe pour assumer cette mission. Gardez à l'esprit que ce processus prendra du temps et mobilisera des collaborateurs au détriment du travail à valeur ajoutée qu'ils accomplissent déjà. Faire appel à un partenaire cloud doté de l'expertise et de l'expérience nécessaires pour vous guider dans la migration peut être une décision avisée, susceptible d'accélérer votre parcours grâce aux conseils éclairés d'architectes chevronnés.
9. Et maintenant ?
Après toutes ces questions, vous vous demandez peut-être si vous disposez des compétences et ressources nécessaires pour mener à bien une migration cloud. Il existe pourtant une alternative : en vous appuyant sur un partenaire cloud comme DoiT, vous accédez à des experts de la migration capables de vous accompagner sur l'ensemble du processus, sans coût supplémentaire.
Premier partenaire d'AWS et de Google Cloud, nous proposons une expertise multicloud appuyée par de précieuses technologies d'optimisation, d'analytique et de gouvernance. Bénéficiez d'un accompagnement pour recueillir les besoins et fixer les objectifs métier, bâtir l'architecture cloud appropriée et faire évoluer votre infrastructure. Avec un tel soutien, votre prochaine question devrait être : par où commencer ?